Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 stay joined in MUCs the user hasn’t explicitly left. So autojoin is just saying "join the MUC on startup" (and thus, by extension, stay joined). Exactly. This is what it means in my IRC client (irssi) and what I've always assumed / treated it as meaning in XMPP. If I join a MUC I want to stay in until I explicitly leave or close my client. If I leave I want to stay left until I explicitly join or close my client. After closing and re-opening my client I want to be in exactly the MUCs in my autojoin list. If I just wanted to persist what my client had last time it was open, I wouldn't need bookmarks. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 (especially impromptu) MUC to start working nicely across >>> > multiple accounts we need clients to react to the user leaving >rooms >>> > manually by disabling the autojoin and then having other clients >leave >>> > as well. They only joined because the autoflag was set, so isn’t >it >>> > logical for them to leave when it’s no longer set? >>> >>> 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 moment later doesn't mean I should suddenly not be joined to rooms >anymore. If I'm in a room, I should autojoin it from all my clients on >startup, if I close the room, it should close immediately in my other >clients and no longer be autojoined on startup. >> >> When I do join or part on one client, I almost never want it synced >to my >> other clients. I have pretty different use between clients. > >That's fine. To be honest, I'm the same. I have a couple of >low-traffic rooms that I join on my mobile, and yet I am in dozens of >rooms on my desktop client. I'd guess many people, especially "power >users" are not very different. > >It doesn't change my opinion about the protocol though. The whole >purpose of bookmarks is for sharing between clients. If you join a >room on one client and it's only for that client, then it shouldn't be >set to 'autojoin' in a data store that is shared across all your >devices. > >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 answers positively, >then a bookmark with 'autojoin' is set. If not, a bookmark may still >be set, but the autojoin flag is only remembered locally. > >And while we're here, I think "autojoin" is a silly concept. A client >should just remember what rooms it has open, and keep them open. If I >close my client and re-open it (or it crashed, or my computer crashed, >etc.), I'd expect to still be in the same rooms, unless I explicitly >asked it to leave them. With a pure JavaScript browser client, where people can use public computers or a friend's computer, I don't store all this data for longer than the session (which ends when you close the tab), so every time someone logs in, it's as if they're logging in for the very first time. In this use case I find autojoin very useful as there is no other memory. JC >> If my connection dropped and came back a moment later, I would want >my >> client to rejoin MUCs I was in. I use bookmarks mostly as a way to >> remember MUC JIDs, not to know which state my clients should be in. > >That's fine, and I see that as a completely valid use of the protocol. >Just don't set autojoin on any of your bookmarks, and use clients that >remember which rooms they are joined to. > >Regards, >Matthew >___ >Standards mailing list >Info: https://mail.jabber.org/mailman/listinfo/standards >Unsubscribe: standards-unsubscr...@xmpp.org >___ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 answers positively, > then a bookmark with 'autojoin' is set. If not, a bookmark may still > be set, but the autojoin flag is only remembered locally. I agree with the local overrides, mostly what I am (should be) doing at the moment. > And while we're here, I think "autojoin" is a silly concept. A client > should just remember what rooms it has open, and keep them open. If I > close my client and re-open it (or it crashed, or my computer crashed, > etc.), I'd expect to still be in the same rooms, unless I explicitly > asked it to leave them. Indeed. > > If my connection dropped and came back a moment later, I would want my > > client to rejoin MUCs I was in. I use bookmarks mostly as a way to > > remember MUC JIDs, not to know which state my clients should be in. > > That's fine, and I see that as a completely valid use of the protocol. > Just don't set autojoin on any of your bookmarks, and use clients that > remember which rooms they are joined to. One of your comments in another branch of this thread suggests this would not be possible anymore, also similar to what SamWhited said above: > My argument is slightly different, I'm arguing that removing autojoin > should cause clients that joined automatically to leave automatically. It's not exactly said like this, but I would read this as "if autojoin is false, leave the room and/or don't join it.". You suggest that this would only be the case when first joined automatically though, which is different from what SamWhited said above, and probably fixes the issue I have. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 you left, and this should >> override the bookmark - why would e.g. the mobile OS killing the app >> in the background and auto-restarting it cause you to rejoin rooms >> that you left? > > Didn’t we argue before that leaving autojoined rooms should remove the > autojoin flag, for synchronization? My argument is slightly different, I'm arguing that removing autojoin should cause clients that joined automatically to leave automatically. One client leaving does not *necessarily* have to unset the autojoin flag. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 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 autojoin and then having other clients leave > >> > as well. They only joined because the autoflag was set, so isn’t it > >> > logical for them to leave when it’s no longer set? > >> > >> 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 moment > >> later doesn't mean I should suddenly not be joined to rooms anymore. > > > > This is what I meant primarily, sorry. I was unclear. > > > >> If I'm > >> in a room, I should autojoin it from all my clients on startup, > > > > Now, I disagree here. I have several rooms which I don’t want on my mobile > > device for battery reasons (my go-to example is #openstack on > > irc.freenode.net). But I have multiple desktop-like devices which I would > > like to join and leave those rooms synchronously. > > > > But as it was said elsewhere, I guess this can very well be solved with > > per- device-class (notification) settings plus CSI. > > I really don't think we should go down the road of trying to define > "device classes". This will only end up with a complex protocol and > complex UIs in clients. > > 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 you left, and this should > override the bookmark - why would e.g. the mobile OS killing the app > in the background and auto-restarting it cause you to rejoin rooms > that you left? Didn’t we argue before that leaving autojoined rooms should remove the autojoin flag, for synchronization? > Alternatively for your case you can join on one of your desktop > clients, choose not to have all your clients join (i.e. don't set > autojoin), and then manually join it from your other desktop clients - > in the room join dialog, they should let you select from your > bookmarks. So with the "leave synchronizes to all devices" part, this is the only way to achieve this. I guess this is fine. This is a power-user use-case anyways. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 nicely across >> > multiple accounts we need clients to react to the user leaving rooms >> > manually by disabling the autojoin and then having other clients leave >> > as well. They only joined because the autoflag was set, so isn’t it >> > logical for them to leave when it’s no longer set? >> >> 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 moment >> later doesn't mean I should suddenly not be joined to rooms anymore. > > This is what I meant primarily, sorry. I was unclear. > >> If I'm >> in a room, I should autojoin it from all my clients on startup, > > Now, I disagree here. I have several rooms which I don’t want on my mobile > device for battery reasons (my go-to example is #openstack on > irc.freenode.net). But I have multiple desktop-like devices which I would like > to join and leave those rooms synchronously. > But as it was said elsewhere, I guess this can very well be solved with per- > device-class (notification) settings plus CSI. I really don't think we should go down the road of trying to define "device classes". This will only end up with a complex protocol and complex UIs in clients. 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 you left, and this should override the bookmark - why would e.g. the mobile OS killing the app in the background and auto-restarting it cause you to rejoin rooms that you left? As I mentioned, I think "autojoin" is the wrong name or the wrong concept for what we ought to be discussing. Alternatively for your case you can join on one of your desktop clients, choose not to have all your clients join (i.e. don't set autojoin), and then manually join it from your other desktop clients - in the room join dialog, they should let you select from your bookmarks. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 accounts we need clients to react to the user leaving rooms >> > manually by disabling the autojoin and then having other clients leave >> > as well. They only joined because the autoflag was set, so isn’t it >> > logical for them to leave when it’s no longer set? >> >> 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 moment >> later doesn't mean I should suddenly not be joined to rooms anymore. If I'm >> in a room, I should autojoin it from all my clients on startup, if I close >> the room, it should close immediately in my other clients and no longer be >> autojoined on startup. > > When I do join or part on one client, I almost never want it synced to my > other clients. I have pretty different use between clients. That's fine. To be honest, I'm the same. I have a couple of low-traffic rooms that I join on my mobile, and yet I am in dozens of rooms on my desktop client. I'd guess many people, especially "power users" are not very different. It doesn't change my opinion about the protocol though. The whole purpose of bookmarks is for sharing between clients. If you join a room on one client and it's only for that client, then it shouldn't be set to 'autojoin' in a data store that is shared across all your devices. 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 answers positively, then a bookmark with 'autojoin' is set. If not, a bookmark may still be set, but the autojoin flag is only remembered locally. And while we're here, I think "autojoin" is a silly concept. A client should just remember what rooms it has open, and keep them open. If I close my client and re-open it (or it crashed, or my computer crashed, etc.), I'd expect to still be in the same rooms, unless I explicitly asked it to leave them. > If my connection dropped and came back a moment later, I would want my > client to rejoin MUCs I was in. I use bookmarks mostly as a way to > remember MUC JIDs, not to know which state my clients should be in. That's fine, and I see that as a completely valid use of the protocol. Just don't set autojoin on any of your bookmarks, and use clients that remember which rooms they are joined to. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 react to the user leaving rooms > > manually by disabling the autojoin and then having other clients leave > > as well. They only joined because the autoflag was set, so isn’t it > > logical for them to leave when it’s no longer set? > > 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 moment > later doesn't mean I should suddenly not be joined to rooms anymore. This is what I meant primarily, sorry. I was unclear. > If I'm > in a room, I should autojoin it from all my clients on startup, Now, I disagree here. I have several rooms which I don’t want on my mobile device for battery reasons (my go-to example is #openstack on irc.freenode.net). But I have multiple desktop-like devices which I would like to join and leave those rooms synchronously. But as it was said elsewhere, I guess this can very well be solved with per- device-class (notification) settings plus CSI. If we are going for that. In that case, I don’t care if my mobile has joined #openstack; it would not be woken up unnecessarily because of that, and it would not generate notifications from that; but if I wanted to take a peek, I could, which is arguably nicer than having to join it manually on that device. > if I close > the room, it should close immediately in my other clients and no longer be > autojoined on startup. For closing I agree. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 using different accounts for work and private stuff, but maybe not everyone uses multiple accounts.) Still, between the options "always synced" and "never synced", I prefer the former. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 moment > > later doesn't mean I should suddenly not be joined to rooms anymore. If I'm > > in a room, I should autojoin it from all my clients on startup, if I close > > the room, it should close immediately in my other clients and no longer be > > autojoined on startup. > > When I do join or part on one client, I almost never want it synced to my > other clients. I have pretty different use between clients. > > If my connection dropped and came back a moment later, I would want my > client to rejoin MUCs I was in. I use bookmarks mostly as a way to > remember MUC JIDs, not to know which state my clients should be in. To complete the above, to summarize and see if I understand what you want exactly: if a bookmark is set to autojoin=false, then all my clients should part or not join this MUC. This seriously disrupt my workflow, and I don't think there is any other equivalent at the moment, is there? Can I propose to dissociate the bookmarking from the syncing bit? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 leaving rooms > > manually by disabling the autojoin and then having other clients leave > > as well. They only joined because the autoflag was set, so isn’t it > > logical for them to leave when it’s no longer set? > > 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 moment later doesn't > mean I should suddenly not be joined to rooms anymore. If I'm in a room, I > should autojoin it from all my clients on startup, if I close the room, it > should close immediately in my other clients and no longer be autojoined on > startup. When I do join or part on one client, I almost never want it synced to my other clients. I have pretty different use between clients. If my connection dropped and came back a moment later, I would want my client to rejoin MUCs I was in. I use bookmarks mostly as a way to remember MUC JIDs, not to know which state my clients should be in. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 autojoin and then having other clients leave > as well. They only joined because the autoflag was set, so isn’t it > logical for them to leave when it’s no longer set? 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 moment later doesn't mean I should suddenly not be joined to rooms anymore. If I'm in a room, I should autojoin it from all my clients on startup, if I close the room, it should close immediately in my other clients and no longer be autojoined on startup. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 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 '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 stay joined in MUCs the user hasn’t >> explicitly left. So autojoin is just saying "join the MUC on startup" (and >> thus, by extension, stay joined). > > 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 autojoin and then having other clients leave as well. They only > joined because the autoflag was set, so isn’t it logical for them to leave > when it’s no longer set? I agree with this. For an example UI, leaving a room could prompt to leave the room on the current client, or all clients (i.e. unset autojoin). 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. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
> 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, and that I'd >> like to see addressed in the mid-term future (ideally by adding them to >> Bookmarks2): >> >> 1) Auto-Join >> >> 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 stay joined in MUCs the user hasn’t > explicitly left. So autojoin is just saying "join the MUC on startup" (and > thus, by extension, stay joined). 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 autojoin and then having other clients leave as well. They only joined because the autoflag was set, so isn’t it logical for them to leave when it’s no longer set? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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'd > > like to see addressed in the mid-term future (ideally by adding them to > > Bookmarks2): > > > > 1) Auto-Join > > > > 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 stay joined in MUCs the user hasn’t > explicitly left. So autojoin is just saying "join the MUC on startup" (and > thus, by extension, stay joined). Agreed with Jonas. A user should explicitely leave the MUC. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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://github.com/xsf/xeps/pull/611 > 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 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 Council will decide in the next two weeks whether to accept this > > proposal as an official XEP. > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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: "Each item SHALL have, as item id, the Room JID of the chatroom". Are we sure that the format accepted by item ids follow the same rules as the ones in JIDs (size wise, character encoding wise…)? This question is also about having other XEPs in the future that can handle items the same way (for example if we define a Pubsub Nodes Bookmarks XEP). In a previous XEP that was doing something very similar I simply used a hash to ensure that https://xmpp.org/extensions/xep-0330.html. Regards, Timothée Jaussoin Le dimanche 18 mars 2018 à 13:34 +, Jonas Wielicki a écrit : > 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 Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 future (ideally by adding them to > Bookmarks2): > > 1) Auto-Join > > 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 stay joined in MUCs the user hasn’t explicitly left. So autojoin is just saying "join the MUC on startup" (and thus, by extension, stay joined). > 2) Per-Client Join Lists > > Sometimes it is desirable to have different clients joined into > different chatrooms (i.e. to remove high traffic public MUCs from a > mobile client). I'm not sure if we can place that here or if this > should better be a part of the Post-XMPP2 centralized per-JID > notification settings. Good point. I’m not sure on the structure of that information though. We don’t have client IDs, nor do we have client categories (aside from XEP-0030 identiteis). Maybe XEP-0030 identities actually could work here? (I.e.: What would be the "key" in the key-value store which maps clients to autojoin values?) > 3) Roster Groups > > MIX allows us to put MIXes into the roster, and by extension into roster > groups. It would be great to have roster group support for MUCs as well, > so that we can put the family MUC into the family roster group. All that > is needed is to allow a set of named tags per bookmarks, no need to > actually change our roster XML. Yes please. > 4) Nicknames > > With MSN widely in use, we lack a mechanism to synchronize our per-MUC > nickname between our clients. This leads to a situation where a > widely-used Android client will leak our username to pseudonymous MUCs > by auto-joining them with nickname=localpart when invited. > > I think we should either mandate that the attribute SHOULD be > used, or at least specify XEP-0172 §4.3 as a fallback if it's not. @nick should be moved to an attribute while we’re at it. Setting it as SHOULD also makes sense. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
> 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 '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. 2) Per-Client Join Lists Sometimes it is desirable to have different clients joined into different chatrooms (i.e. to remove high traffic public MUCs from a mobile client). I'm not sure if we can place that here or if this should better be a part of the Post-XMPP2 centralized per-JID notification settings. 3) Roster Groups MIX allows us to put MIXes into the roster, and by extension into roster groups. It would be great to have roster group support for MUCs as well, so that we can put the family MUC into the family roster group. All that is needed is to allow a set of named tags per bookmarks, no need to actually change our roster XML. 4) Nicknames With MSN widely in use, we lack a mechanism to synchronize our per-MUC nickname between our clients. This leads to a situation where a widely-used Android client will leak our username to pseudonymous MUCs by auto-joining them with nickname=localpart when invited. I think we should either mandate that the attribute SHOULD be used, or at least specify XEP-0172 §4.3 as a fallback if it's not. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 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 Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 Pubsub nodes in the Bookmarks as well. Regarding the fact the each of them is store atomically this shouldn't be an issue to store client specific bookmarks namespaces on this node (we could imagine new way in the future to store browser bookmarks, maps location bookmarks…). Regards, Timothée Jaussoin Le dimanche 18 mars 2018 à 13:34 +, Jonas Wielicki a écrit : > 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 Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 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? >>> >>> 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] >>> until convergence to make that work. >>> >>> >> I didn't think of that. It does, however, seem like a very unlikely problem >> to have occur. On top of that, I don't think that the new XEP fixes the >> address when both clients are updating the same bookmark. > > While the problem may occur seldom in practice, it should be fixed if it > can be fixed. (And with flaky network connections or clients that do not > check the bookmark list before making changes it may not be that seldom). > > As for the "the same bookmark" problem: there is no solution in that > case other than making atomic changes (since we have no way to decide > which change is "right"), and making atomic changes to a single bookmark > *is* possible with the PEP method: We simple need to publish our new > item, and if there's a concurrent change by another client, our change > will be overwritten (or that change will be overwritten). But that's not > a problem (as long as the state is always consistent and we do not lose > items unrelated to the change). Agreed. We have a number of operations like this in XMPP. In fact, just about all of them. Roster modifications for example. We get away with it because as you say, conflicts are seldom in practice, and the effects are just overwriting a single item with whichever came last. Which if you are thinking about conflict resolution, isn't a terrible strategy in this case, especially when for most situations the change was triggered by a human. > Further problems solved by the one-bookmark-per-item approach: A good list. I was previously on the fence about per-item bookmarks (that is, I didn't much care about which solution was adopted). However after you list all these points out, I'm pretty convinced that per-item is indeed the way to go. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 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? >> >> 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] >> until convergence to make that work. >> >> > I didn't think of that. It does, however, seem like a very unlikely problem > to have occur. On top of that, I don't think that the new XEP fixes the > address when both clients are updating the same bookmark. While the problem may occur seldom in practice, it should be fixed if it can be fixed. (And with flaky network connections or clients that do not check the bookmark list before making changes it may not be that seldom). As for the "the same bookmark" problem: there is no solution in that case other than making atomic changes (since we have no way to decide which change is "right"), and making atomic changes to a single bookmark *is* possible with the PEP method: We simple need to publish our new item, and if there's a concurrent change by another client, our change will be overwritten (or that change will be overwritten). But that's not a problem (as long as the state is always consistent and we do not lose items unrelated to the change). Further problems solved by the one-bookmark-per-item approach: * We get the notifications that have single bookmark granularity and we do not have to diff the entire bookmark lists against our current bookmark list to notify the application of bookmark changes. * We have no trouble preserving non-standard elements in bookmarks we do not touch. * The change allows O(1) book-keeping for clients tracking the current bookmark list, instead of O(n) book-keeping necessary if all bookmarks have to be retrieved at once. This is especially beneficial from a bandwidth perspective. * no more questions on how to treat duplicate bookmarks for the same jid. > For what it's worth, I did get that from the text. My point was that it'd > be helpful to have the pubsub details in an example. I agree, that would indeed be helpful (and coherent with other XEPs, where there are usually examples of full stanzas for the use-cases). While first skimming the document I actually thought the jid attribute of the bookmarks was missing. Kind regards, Sebastian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 on the idea of having a bookmark-per-item: what > > problem is that solving, or what benefit does this give us? > > 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] > until convergence to make that work. > > I didn't think of that. It does, however, seem like a very unlikely problem to have occur. On top of that, I don't think that the new XEP fixes the address when both clients are updating the same bookmark. > > I appreciate > > how it fits in nicely with the way how pubsub is designed - but in > > practice, I suspect that one would easily work with entire sets of > > bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a > > new namespace, and we can re-use the existing 0048/0049 data structure. > > That will improve interoperability, and make adoption easier. > > We’ve been advocating this (split into items) move for quite a while and > we’re > happy to see that it’s happening now. > > > Unrelated: I'd like the XEP to have a "complete" example of a bookmark, > one > > that includes the room JID. Although the text is clear, having an example > > like that will be a useful illustration. > > The text doesn’t seem to be that clear then; the idea is that the JID is in > the pubsub item ID (§ 4.1) -- which also has the nice sideeffect of > resolving > the ambiguities which arise when multiple bookmarks for the same room with > different nicknames exist. > > For what it's worth, I did get that from the text. My point was that it'd be helpful to have the pubsub details in an example. > kind regards, > Jonas > >[1]: https://github.com/horazont/aioxmpp/blob/devel/aioxmpp/bookmarks/ > service.py#L416 > > > > > On 18 March 2018 at 16:25, Sam Whited wrote: > > > 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 clients must store the password (so > > > you'd have to log in once on each client the first time it fetches the > > > bookmarks and joins the room). > > > > > > —Sam > > > > > > On Sun, Mar 18, 2018, at 08:34, Jonas Wielicki wrote: > > > > 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 Council will decide in the next two weeks whether to accept this > > > > proposal as an official XEP. > > > > ___ > > > > Standards mailing list > > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > > Unsubscribe: standards-unsubscr...@xmpp.org > > > > ___ > > > > > > -- > > > Sam Whited > > > s...@samwhited.com > > > ___ > > > Standards mailing list > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > Unsubscribe: standards-unsubscr...@xmpp.org > > > ___ > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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? > Bookmarks are not some workaround because of a bad MUC standard. If you want to work on MUC, there are a hundred threads about the upcoming MIX standard. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 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 Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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] until convergence to make that work. You need this loop too if you want to modify the same item (i.e. the bookmark of the same conference). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 is that solving, or what benefit does this give us? 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] until convergence to make that work. > I appreciate > how it fits in nicely with the way how pubsub is designed - but in > practice, I suspect that one would easily work with entire sets of > bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a > new namespace, and we can re-use the existing 0048/0049 data structure. > That will improve interoperability, and make adoption easier. We’ve been advocating this (split into items) move for quite a while and we’re happy to see that it’s happening now. > Unrelated: I'd like the XEP to have a "complete" example of a bookmark, one > that includes the room JID. Although the text is clear, having an example > like that will be a useful illustration. The text doesn’t seem to be that clear then; the idea is that the JID is in the pubsub item ID (§ 4.1) -- which also has the nice sideeffect of resolving the ambiguities which arise when multiple bookmarks for the same room with different nicknames exist. kind regards, Jonas [1]: https://github.com/horazont/aioxmpp/blob/devel/aioxmpp/bookmarks/ service.py#L416 > > On 18 March 2018 at 16:25, Sam Whited wrote: > > 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 clients must store the password (so > > you'd have to log in once on each client the first time it fetches the > > bookmarks and joins the room). > > > > —Sam > > > > On Sun, Mar 18, 2018, at 08:34, Jonas Wielicki wrote: > > > 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 Council will decide in the next two weeks whether to accept this > > > proposal as an official XEP. > > > ___ > > > Standards mailing list > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > Unsubscribe: standards-unsubscr...@xmpp.org > > > ___ > > > > -- > > Sam Whited > > s...@samwhited.com > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 fits in nicely with the way how pubsub is designed - but in practice, I suspect that one would easily work with entire sets of bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a new namespace, and we can re-use the existing 0048/0049 data structure. That will improve interoperability, and make adoption easier. Unrelated: I'd like the XEP to have a "complete" example of a bookmark, one that includes the room JID. Although the text is clear, having an example like that will be a useful illustration. - Guus On 18 March 2018 at 16:25, Sam Whited wrote: > 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 clients must store the password (so > you'd have to log in once on each client the first time it fetches the > bookmarks and joins the room). > > —Sam > > On Sun, Mar 18, 2018, at 08:34, Jonas Wielicki wrote: > > 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 Council will decide in the next two weeks whether to accept this > > proposal as an official XEP. > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > > -- > Sam Whited > s...@samwhited.com > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 clients must store the password (so you'd have to log in once on each client the first time it fetches the bookmarks and joins the room). —Sam On Sun, Mar 18, 2018, at 08:34, Jonas Wielicki wrote: > 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 Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Sam Whited s...@samwhited.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 idea. > Furthermore we'd have something the Compliance Tester can pick up on. > I'd argue that compliance testers should actually test compliance, but sure. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
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 we don’t want the compat mode to be a MUST I do think it will be vitally important for the foreseeable feature if we don’t want to break the ecosystem. (The vcard<->PEP conversion XEP has a disco feature for similar purposes) cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
