The 'autojoin' flag name is a bit misleading in the time of always-on
clients. Maybe we should change the text to indicate that a client is
supposed to join and stay joined(!) if this flag is set, and maybe also
to automatically leave when the flag is unset.
I’d argue that clients should always
Am 22. März 2018 08:28:21 MEZ schrieb Matthew Wild :
>On 21 March 2018 at 17:27, Maxime Buquet wrote:
>> On 2018/03/21, Sam Whited wrote:
>>> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
>>> > I’d argue (and did at the Summit) that the opposite is true and
>that if
>>> > we want (especiall
On 2018/03/22, Matthew Wild wrote:
> We're discussing the protocol, but there is nothing stopping clients
> having their own overrides (i.e. local autojoin rooms). This could be
> as simple as, when you join a room for the first time "Do you want to
> join this room on all devices?" -> if the user
On 22 March 2018 at 07:51, Jonas Wielicki wrote:
> On Donnerstag, 22. März 2018 08:36:10 CET Matthew Wild wrote:
>> As per the logic described in my previous email, you can either set
>> autojoin and explicitly leave the room on your mobile when it
>> autojoins - the client should remember that yo
On Donnerstag, 22. März 2018 08:36:10 CET Matthew Wild wrote:
> On 21 March 2018 at 18:37, Jonas Wielicki wrote:
> > On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote:
> >> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> >> > I’d argue (and did at the Summit) that the opposite is true
On 21 March 2018 at 18:37, Jonas Wielicki wrote:
> On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote:
>> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
>> > I’d argue (and did at the Summit) that the opposite is true and that if
>> > we want (especially impromptu) MUC to start working n
On 21 March 2018 at 17:27, Maxime Buquet wrote:
> On 2018/03/21, Sam Whited wrote:
>> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
>> > I’d argue (and did at the Summit) that the opposite is true and that if
>> > we want (especially impromptu) MUC to start working nicely across
>> > multiple
On 21 Mar 2018 23:09, "W. Martin Borgert" wrote:
Sometimes yes, sometimes no.
I would like to have some rooms autojoined when I'm at home, but not
when at work. And vice versa.
Logical next step is to ask for separate sets of contacts at home and at
work.
_
On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote:
> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> > I’d argue (and did at the Summit) that the opposite is true and that if
> > we want (especially impromptu) MUC to start working nicely across
> > multiple accounts we need clients to r
Quoting Matthew Wild :
The whole point of the autojoin logic was to keep clients
synchronised. Either we want clients in sync or we don't. And I think
we do.
Sometimes yes, sometimes no.
I would like to have some rooms autojoined when I'm at home, but not
when at work. And vice versa.
(I'm us
On 2018/03/21, Maxime Buquet wrote:
> On 2018/03/21, Sam Whited wrote:
> > I agree with this; when I do something on one client, I almost always want
> > it synced to my other clients. Room joining and parting is the same.
> > Similarly, just because my connection dropped and came back up a momen
On 2018/03/21, Sam Whited wrote:
> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> > I’d argue (and did at the Summit) that the opposite is true and that if
> > we want (especially impromptu) MUC to start working nicely across
> > multiple accounts we need clients to react to the user leavin
On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> I’d argue (and did at the Summit) that the opposite is true and that if
> we want (especially impromptu) MUC to start working nicely across
> multiple accounts we need clients to react to the user leaving rooms
> manually by disabling the auto
On 21 March 2018 at 17:01, Kevin Smith wrote:
>
>
>> On 20 Mar 2018, at 18:21, Jonas Wielicki wrote:
>>
>> On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Bookmarks 2 (This Time it's Serious)
>>>
>>> A n
> On 20 Mar 2018, at 18:21, Jonas Wielicki wrote:
>
> On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> Title: Bookmarks 2 (This Time it's Serious)
>>
>> A number of issues I have with the current Bookmarks XEPs
On 2018/03/20, Jonas Wielicki wrote:
> On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote:
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > > Title: Bookmarks 2 (This Time it's Serious)
> >
> > A number of issues I have with the current Bookmarks XEPs, and that I'
On Tue, Mar 20, 2018 at 05:27:05PM +0100, Daniel Gultsch wrote:
> The security section needs a bit about the correct use of
> publish-options or developers will get that wrong.
I updated the security section of the XEP in a branch a few days ago already,
but the change is still in a PR.
https://g
Hi,
Based on the discussion we had on this ML a couple of weeks ago ([Standards]
What is the size limit of node and item ids in XEP-0060:
Publish-Subscribe?
https://mail.jabber.org/pipermail/standards/2018-March/034410.html).
I see that this XEP define the item ids of the Pubsub nodes this way:
On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> > Title: Bookmarks 2 (This Time it's Serious)
>
> A number of issues I have with the current Bookmarks XEPs, and that I'd
> like to see addressed in the mid-term futur
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Bookmarks 2 (This Time it's Serious)
A number of issues I have with the current Bookmarks XEPs, and that I'd
like to see addressed in the mid-term future (ideally by adding them to
Bookmarks2):
1) Auto-Join
The 'autojoi
The security section needs a bit about the correct use of
publish-options or developers will get that wrong.
2018-03-18 14:34 GMT+01:00 Jonas Wielicki :
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Bookmarks 2 (This Time it's Serious)
> Abstract:
> This specificat
Hi,
Would it be possible to extend this to also allow the storage of Pubsub
subscriptions (reusing the urn:xmpp:pubsub:subscription namespace defined
in XEP-0330 https://xmpp.org/extensions/xep-0330.html)?
This would allow 'social clients' like Movim or Salut à Toi to store their
favorite Pub
On 18 March 2018 at 21:59, Sebastian Riese wrote:
> On 18.03.2018 21:30, Guus der Kinderen wrote:
>> On 18 March 2018 at 18:56, Jonas Wielicki wrote:
>>
>>> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote:
Having implemented 0048 via 0223 earlier this week, I can only applaud
Hi to all,
On 18.03.2018 21:30, Guus der Kinderen wrote:
> On 18 March 2018 at 18:56, Jonas Wielicki wrote:
>
>> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote:
>>> Having implemented 0048 via 0223 earlier this week, I can only applaud an
>>> effort of making the documentation ea
On 18 March 2018 at 18:56, Jonas Wielicki wrote:
> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote:
> > Having implemented 0048 via 0223 earlier this week, I can only applaud an
> > effort of making the documentation easier to digest. Thanks for this!
> >
> > I am, however not sold
Sun, 18 Mar 2018 21:17:16 +0100
Philipp Hörist wrote:
> If you want to work on MUC, there are a hundred threads about the
> upcoming MIX standard.
I hope this will never become an adopted standard.
___
Standards mailing list
Info: https://mail.jabber.o
2018-03-18 19:47 GMT+01:00 Ненахов Андрей :
> If the only reason to have bookmarks is to store there information about
> conference rooms, can we instead concentrate on better MUC standard that
> does not rely on various crutches like bookmarks to work properly across
> connected clients?
>
Bookma
If the only reason to have bookmarks is to store there information about
conference rooms, can we instead concentrate on better MUC standard that
does not rely on various crutches like bookmarks to work properly across
connected clients?
On 18 Mar 2018 18:36, "Jonas Wielicki" wrote:
> The XMPP
Sun, 18 Mar 2018 18:56:48 +0100
Jonas Wielicki wrote:
> Two or more clients updating different bookmarks at the same time (or
> maybe at different times, but one had a network outage inbetween and
> can only actually perform the update at a later time). Currently, it
> requires a nasty loop [1] u
On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote:
> Having implemented 0048 via 0223 earlier this week, I can only applaud an
> effort of making the documentation easier to digest. Thanks for this!
>
> I am, however not sold on the idea of having a bookmark-per-item: what
> problem i
Having implemented 0048 via 0223 earlier this week, I can only applaud an
effort of making the documentation easier to digest. Thanks for this!
I am, however not sold on the idea of having a bookmark-per-item: what
problem is that solving, or what benefit does this give us? I appreciate
how it fit
Looks great, thanks Dave and JC!
The only feedback I'd like to give is that the password field should be
removed. If use of the password field is not recommended, why have it? It seems
perfectly fine to say that you can't autojoin password protected MUCs without a
prompt or that individual clie
On 18 March 2018 at 14:07, Daniel Gultsch wrote:
> Hi
>
> I would like to see a disco feature for the compat mode (4.2).
> This way I as a client developer know when it is safe to store
> bookmarks using this method and this method only without loosing
> legacy clients.
>
Sounds like a smart ide
Hi
I would like to see a disco feature for the compat mode (4.2).
This way I as a client developer know when it is safe to store
bookmarks using this method and this method only without loosing
legacy clients.
Furthermore we'd have something the Compliance Tester can pick up on.
While I see that
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Bookmarks 2 (This Time it's Serious)
Abstract:
This specification defines a syntax and storage profile for keeping a
list of chatroom bookmarks on the server.
URL: https://xmpp.org/extensions/inbox/bookmarks2.html
The Counc
35 matches
Mail list logo