btw the Gajim default blocking option should work in 0.16.7 perfectly
together with blocking command, just for info.
On Topic i think nobody uses Privacy Lists .. like with different lists and
setting active this and that and creating cool special rules. At least not
in Gajim.
Its also very
On Thu, Mar 23, 2017 at 8:09 AM, Dave Cridland wrote:
> I'm in favour of deprecation (but not elimination).
I forgot there was a difference, but I used the word I meant purely by accident.
To make sure it's absolutely clear: I am advocating that we move
XEP-0016 to the
On 23.03.2017 14:18, Dave Cridland wrote:
On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote:
On 22.03.2017 20:37, Sam Whited wrote:
On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger
wrote:
One nice feature we also don't have with blocking command is
Version 0.0.1 of XEP-0390 (Entity Capabilities 2.0) has been released.
Abstract: This document overhauls the XMPP protocol extension Entity
Capabilities (XEP-0115). It defines an XMPP protocol extension for broadcasting
and dynamically discovering client, device, or generic entity capabilities.
Hi all,
On 03/22/2017 04:08 PM, Ruslan N. Marchenko wrote:
> List allows you creating overriding allow entry which will unblock
> single person while keeping the group blocked (order matters).
So does keeping the UI option to block a whole group, and then just
using the blocking command to
* Florian Schmaus [2017-03-23 14:25]:
> It is the same feature request for PubSub/PEP. For example when using
> OMEMO you always want to subscribe-and-maybe-create the devicelist node.
I can see how an UPSERT operation is useful on a resource that is
exclusively owned by you,
On 23.03.2017 14:25, Florian Schmaus wrote:
> It is the same feature request for PubSub/PEP. For example when using
> OMEMO you always want to subscribe-and-maybe-create the devicelist node.
> Some goes for the XEP-0080 geoloc node. It would be nice if PubSub would
> provide that as primitive.
On 23.03.2017 11:05, Georg Lukas wrote:
> * Florian Schmaus [2017-03-23 10:11]:
>> That does work if the name of the channel can be random (nameless). But
>> I believe that there will be use cases where the name of the channel
>> needs to be fixed.
>
> Yes, there are use cases
On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote:
>
> On 22.03.2017 20:37, Sam Whited wrote:
>>
>> On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger
>> wrote:
>>>
>>> One nice feature we also don't have with blocking command is blocking a
>>> while group.
On 22 March 2017 at 19:08, Sam Whited wrote:
> I'd love your thoughts before I bring this before the council for a vote.
I'm in favour of deprecation (but not elimination).
* Privacy lists are mammothly complicated, and therefore error-prone.
* While it's possible to
On Mittwoch, 22. März 2017 18:48:06 CET edhe...@movim.eu wrote:
> * var='Participation Addition by Invitation from Participant'
>
> * I think that it would be better to set this field var to
> 'participation_addition_by_invitation_from_participant' and use the
> label tag for all the
* Florian Schmaus [2017-03-23 10:11]:
> That does work if the name of the channel can be random (nameless). But
> I believe that there will be use cases where the name of the channel
> needs to be fixed.
Yes, there are use cases where a fixed channel name is needed. But do
you
On 23 March 2017 at 08:38, Georg Lukas wrote:
> * Florian Schmaus [2017-03-23 08:22]:
>> Consider an chess-game service build on top of MIX. Tim and Tom want to
>> play a game and agree on the "TimAndTomsGame" as name. Now both clients
>> want to
* Florian Schmaus [2017-03-23 08:22]:
> Consider an chess-game service build on top of MIX. Tim and Tom want to
> play a game and agree on the "TimAndTomsGame" as name. Now both clients
> want to join-and-maybe-create the TimAndTomsGame MIX channel.
I think this is exactly
Flo,
I'm not convinced by this example.
MIX is primarily oriented for end users, not as a building block like
PubSub. I don't see this example as a target application and the issue
seems quite pathological to me
Steve
> > Couldn't this be a create followed by a join?
> > If the channel
On 23.03.2017 04:14, Daurnimator wrote:
> On 23 March 2017 at 01:40, Florian Schmaus wrote:
>> On 22.03.2017 12:53, Steve Kille wrote:
>>> I think that keeping Create and Join separate is the right thing.
>>
>> They can and should be separate, but I think there needs to be a
> -Original Message-
> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of
> Daurnimator
> Sent: 23 March 2017 03:15
> To: XMPP Standards
> Subject: Re: [Standards] Join and Create
>
> On 23 March 2017 at 01:40, Florian Schmaus wrote:
> > On 22.03.2017
17 matches
Mail list logo