Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Philipp Hörist wrote: > Hi, > > let me try with XEP-0402 > > > > > > name='The Plays the Thing' > autojoin='true'> > JC > > > > > > > > > > > > - Clients offer a option to set one or more profiles for the device > - Clients can ask the user on joining a bookmark which profiles should be > added (one or multiple) > - Default is no profile > - If a Client has no profile set, it honors the autojoin attr > - If a Client has a profile set, he autojoins all bookmarks that have the > corresponding profile, effectively ignoring the autojoin attr > - If a client leaves a muc he removes the profile from the bookmark Might seem obvious for some, but I would add regarding in general: - If there is an extension that you didn't add yourself, don't automatically remove the entry (that is, without explicit user input). > Still sounds complex to me, not easy to make that user friendly in my > opinion -- 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] Bookmarks and autojoin issues
Hi, let me try with XEP-0402 JC - Clients offer a option to set one or more profiles for the device - Clients can ask the user on joining a bookmark which profiles should be added (one or multiple) - Default is no profile - If a Client has no profile set, it honors the autojoin attr - If a Client has a profile set, he autojoins all bookmarks that have the corresponding profile, effectively ignoring the autojoin attr - If a client leaves a muc he removes the profile from the bookmark Still sounds complex to me, not easy to make that user friendly in my opinion Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Stefan wrote: > Am Sonntag, den 24.05.2020 um 00:41:53 +0200 schrieb mathi...@mathieui.net: > > The use cases I have in mind are a bit extreme (e.g. people with > 100 > > MUCs in their autojoined bookmarks), which are unusable on mobile, for > > example, where screen space is limited and you probably want to limit > > yourself to the "important" ones. Or when joining big IRC channels with > > more than 1000 users, you also do not want that on mobile as that much > > activity is never good for battery life, however optimized the client > > might be. Even for smaller cases, such as 20-30 rooms, this can be a > > limiting factor. > > I think this is a valid use case and not only for a big set of MUCs. > An idea I had in mind is to use the client-submitted resourcepart of > the full jid [1] to disable the autojoin feature. > > Let's imagine the bookmark looks like this. > > > autojoin='true' > jid='coun...@conference.underhill.org'> > Puck > > > > The user has 3 clients. Those clients supports the client-submitted > resourcepart and the user (or the client) defines the names: > > * profanity.7abc > * Laptop > * Conversations.ABC > > If the User decides in the client "Disable autojoin on this device", > the client will set something like this in the : > > Conversations.ABC > > The result will look like this: > > > autojoin='true' > jid='coun...@conference.underhill.org'> > Puck > Conversations.ABC > > > > The client can check if his resource is defined as disable-autojoin. > If this is the case, the client will skip the autojoin. I think we're on the same track with profiles, just that this approach seems a bit clumsy to me. First this example uses 0048, for which clients may not accept extensions and overwrite anything they don't know when publishing again. This is I guess the reason why 0402 has this new tag. Then relying on potentially unstable resource names is risky, even if the trend seems to be to use somewhat stable names (again?). Do we leave inexisting resources lingering indefinitely? Do we GC at some point, based on what? This would also not prevent clients from removing an entry altogether when they leave a room as some seem to do (instead of toggling the autojoin flag off), losing completion/suggestion features and also some information when they're potentially readded later etc. -- 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] Bookmarks and autojoin issues
Am Sonntag, den 24.05.2020 um 00:41:53 +0200 schrieb mathi...@mathieui.net: > The use cases I have in mind are a bit extreme (e.g. people with > 100 > MUCs in their autojoined bookmarks), which are unusable on mobile, for > example, where screen space is limited and you probably want to limit > yourself to the "important" ones. Or when joining big IRC channels with > more than 1000 users, you also do not want that on mobile as that much > activity is never good for battery life, however optimized the client > might be. Even for smaller cases, such as 20-30 rooms, this can be a > limiting factor. I think this is a valid use case and not only for a big set of MUCs. An idea I had in mind is to use the client-submitted resourcepart of the full jid [1] to disable the autojoin feature. Let's imagine the bookmark looks like this. Puck The user has 3 clients. Those clients supports the client-submitted resourcepart and the user (or the client) defines the names: * profanity.7abc * Laptop * Conversations.ABC If the User decides in the client "Disable autojoin on this device", the client will set something like this in the : Conversations.ABC The result will look like this: Puck Conversations.ABC The client can check if his resource is defined as disable-autojoin. If this is the case, the client will skip the autojoin. [1] rfc6120 - 7. Resource Binding ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Philipp Hörist wrote: > What first comes to mind is, that 402 now can hold extended payloads in > each bookmark item. > So we just add the profile there? Not against the idea, even though I'm not entirely sure how it would work. 0402 is not a bookmark XEP, just like the multiple versions of 0048 are not bookmark XEPs either, they're some loose client state syncing mechanism for chatrooms only. Which is fine but has never been made explicit. So expecting 0402 to behave as a dumb bookmark list when adding this profile extension (that other clients may not support) is changing the semantics of the XEP entirely. -- 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] Bookmarks and autojoin issues
Hi, So whats your ideas how we can implement that? What first comes to mind is, that 402 now can hold extended payloads in each bookmark item. So we just add the profile there? and UI wise i ask the user when he joins a room to what profile he wants to add that. regards Philipp Am So., 24. Mai 2020 um 11:13 Uhr schrieb Mathieu Pasquet < mathi...@mathieui.net>: > On 24.05.2020 06:50, Philipp Hörist wrote: > >Hi, > > > >The problem is there are no rules what goes into which profile. > > > >If i add a bookmark as a desktop client, i don't know if it should go > into the > >mobile profile or not. > >And btw we try to abstract bookmarks away from the user, so managing > profiles > >of bookmarks for different devices is exactly not the direction i want to > go. > > > >So either this can be determined automatically without user input (i > doubt it) > >or a simple local autojoin list where the user simply has to manually join > >bookmarks is better in my opinion. > > > >Regards > >Philipp > > > > > > Well, one easy to implement and to understand rule would be to, by > default, create a single "default" profile and use that to effectively keep > the current behavior of "everything is synced everywhere", unless the user > configured it otherwise. I see this as an advanced feature and not > something that most users would want to fiddle with (as I said, the > issues mostly grow with the number of MUCs). The state would then be > synced across clients referring to the same profile name. > > There is also a niche for client developers who could then use a > test client with a distinct bookmarks profile without the need for a > separate account. > > I have had local autojoin lists for a decade in poezio and frankly it > is not a very good solution when not many clients support it, other > clients abstract the bookmark management away from the user, and nothing > is standard. You have the choice between having an unpredictable mix of > remote bookmarks and local autojoins, or entirely disable remote bookmarks > for the sake of sanity, which is not good either. > > Cheers, > Mathieu > ___ > 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] Bookmarks and autojoin issues
On 24.05.2020 06:50, Philipp Hörist wrote: Hi, The problem is there are no rules what goes into which profile. If i add a bookmark as a desktop client, i don't know if it should go into the mobile profile or not. And btw we try to abstract bookmarks away from the user, so managing profiles of bookmarks for different devices is exactly not the direction i want to go. So either this can be determined automatically without user input (i doubt it) or a simple local autojoin list where the user simply has to manually join bookmarks is better in my opinion. Regards Philipp Well, one easy to implement and to understand rule would be to, by default, create a single "default" profile and use that to effectively keep the current behavior of "everything is synced everywhere", unless the user configured it otherwise. I see this as an advanced feature and not something that most users would want to fiddle with (as I said, the issues mostly grow with the number of MUCs). The state would then be synced across clients referring to the same profile name. There is also a niche for client developers who could then use a test client with a distinct bookmarks profile without the need for a separate account. I have had local autojoin lists for a decade in poezio and frankly it is not a very good solution when not many clients support it, other clients abstract the bookmark management away from the user, and nothing is standard. You have the choice between having an unpredictable mix of remote bookmarks and local autojoins, or entirely disable remote bookmarks for the sake of sanity, which is not good either. Cheers, Mathieu signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
Hi, The problem is there are no rules what goes into which profile. If i add a bookmark as a desktop client, i don't know if it should go into the mobile profile or not. And btw we try to abstract bookmarks away from the user, so managing profiles of bookmarks for different devices is exactly not the direction i want to go. So either this can be determined automatically without user input (i doubt it) or a simple local autojoin list where the user simply has to manually join bookmarks is better in my opinion. Regards Philipp Am So., 24. Mai 2020 um 01:17 Uhr schrieb Maxime Buquet : > On 2020/05/24, Mathieu Pasquet wrote: > > Greetings, > > > > I want to raise an issue that appears with bookmarks in their current > > form in the multi-client scenario. It appears as long as we have more > > than one client, and gets worse for every added client and MUC bookmark. > > > > XEP-0048 and XEP-0402 both re-use the element, which has > > an autojoin flag. In a single-client scenario this is fine because that > > represents what the user wants in terms of joined rooms. In a > > multi-client scenario however, that quickly changes as you probably do > > not want the same view everywhere. > > I agree. > > > The use cases I have in mind are a bit extreme (e.g. people with > 100 > > MUCs in their autojoined bookmarks), which are unusable on mobile, for > > example, where screen space is limited and you probably want to limit > > yourself to the "important" ones. Or when joining big IRC channels with > > more than 1000 users, you also do not want that on mobile as that much > > activity is never good for battery life, however optimized the client > > might be. Even for smaller cases, such as 20-30 rooms, this can be a > > limiting factor. > > > > Bookmarks in themselves only represent MUCs we want to keep in memory, > > and that is fine. However tying the "autojoin" attribute in there means > > we are now syncing client state, and that is not often desirable, for > > the reasons stated above (different constraints, different platforms, > > different attention spans). > > > > The following is probably over-engineered for a nerdy edge case, but one > > viable solution would be the ability to manage sets of client "profiles" > > which would hold client state independently from bookmarks. This could > > be stored in PEP as well, and could be a list of pubsub URIs to the > > stored bookmarks. Removing a bookmark would automatically remove the > > autojoin in all profiles that link to it. > > I'm thinking that even if some clients don't want to implement support > for multiple profiles, they could "just" implement support for a > single/default profile, still allowing advanced clients to use different > ones. > > This would allow for the bookmark list would to be a bookmark list and > not a syncing mechanism. > > That list could be used in various cases where completion/suggestions > are helpful. > > -- > Maxime “pep” Buquet > ___ > 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] Bookmarks and autojoin issues
On 2020/05/24, Mathieu Pasquet wrote: > Greetings, > > I want to raise an issue that appears with bookmarks in their current > form in the multi-client scenario. It appears as long as we have more > than one client, and gets worse for every added client and MUC bookmark. > > XEP-0048 and XEP-0402 both re-use the element, which has > an autojoin flag. In a single-client scenario this is fine because that > represents what the user wants in terms of joined rooms. In a > multi-client scenario however, that quickly changes as you probably do > not want the same view everywhere. I agree. > The use cases I have in mind are a bit extreme (e.g. people with > 100 > MUCs in their autojoined bookmarks), which are unusable on mobile, for > example, where screen space is limited and you probably want to limit > yourself to the "important" ones. Or when joining big IRC channels with > more than 1000 users, you also do not want that on mobile as that much > activity is never good for battery life, however optimized the client > might be. Even for smaller cases, such as 20-30 rooms, this can be a > limiting factor. > > Bookmarks in themselves only represent MUCs we want to keep in memory, > and that is fine. However tying the "autojoin" attribute in there means > we are now syncing client state, and that is not often desirable, for > the reasons stated above (different constraints, different platforms, > different attention spans). > > The following is probably over-engineered for a nerdy edge case, but one > viable solution would be the ability to manage sets of client "profiles" > which would hold client state independently from bookmarks. This could > be stored in PEP as well, and could be a list of pubsub URIs to the > stored bookmarks. Removing a bookmark would automatically remove the > autojoin in all profiles that link to it. I'm thinking that even if some clients don't want to implement support for multiple profiles, they could "just" implement support for a single/default profile, still allowing advanced clients to use different ones. This would allow for the bookmark list would to be a bookmark list and not a syncing mechanism. That list could be used in various cases where completion/suggestions are helpful. -- 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] Bookmarks and autojoin issues
Another perspective for profiles is work/life balance. Work/life MUCs or anything else fitting this concept. Particularly in Psi I've already added some options allowing to ignore some autojoining mucs for example at work or local-only (not stored on a server) bookmarks. Best Regards, Sergey вс, 24 мая 2020 г. в 01:56, Sam Whited : > On Sat, May 23, 2020, at 18:41, Mathieu Pasquet wrote: > > In a multi-client scenario however, that quickly changes as you > > probably do not want the same view everywhere. > > I disagree, I always want exactly the same view everywhere. Otherwise I > inevitably leave my desk and then try to look up something on my phone > that someone mentioned earlier and can't find it because I'm not > actually joined to that room. I do not know if my view on this is more > prevalent than people who want their phone joined to different rooms or > not, but I definitely want to dispute the "probably do not want the same > view" in the previous message. > > —Sam > > -- > Sam Whited > ___ > 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] Bookmarks and autojoin issues
On Sat, May 23, 2020, at 18:41, Mathieu Pasquet wrote: > In a multi-client scenario however, that quickly changes as you > probably do not want the same view everywhere. I disagree, I always want exactly the same view everywhere. Otherwise I inevitably leave my desk and then try to look up something on my phone that someone mentioned earlier and can't find it because I'm not actually joined to that room. I do not know if my view on this is more prevalent than people who want their phone joined to different rooms or not, but I definitely want to dispute the "probably do not want the same view" in the previous message. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Bookmarks and autojoin issues
Greetings, I want to raise an issue that appears with bookmarks in their current form in the multi-client scenario. It appears as long as we have more than one client, and gets worse for every added client and MUC bookmark. XEP-0048 and XEP-0402 both re-use the element, which has an autojoin flag. In a single-client scenario this is fine because that represents what the user wants in terms of joined rooms. In a multi-client scenario however, that quickly changes as you probably do not want the same view everywhere. The use cases I have in mind are a bit extreme (e.g. people with > 100 MUCs in their autojoined bookmarks), which are unusable on mobile, for example, where screen space is limited and you probably want to limit yourself to the "important" ones. Or when joining big IRC channels with more than 1000 users, you also do not want that on mobile as that much activity is never good for battery life, however optimized the client might be. Even for smaller cases, such as 20-30 rooms, this can be a limiting factor. Bookmarks in themselves only represent MUCs we want to keep in memory, and that is fine. However tying the "autojoin" attribute in there means we are now syncing client state, and that is not often desirable, for the reasons stated above (different constraints, different platforms, different attention spans). The following is probably over-engineered for a nerdy edge case, but one viable solution would be the ability to manage sets of client "profiles" which would hold client state independently from bookmarks. This could be stored in PEP as well, and could be a list of pubsub URIs to the stored bookmarks. Removing a bookmark would automatically remove the autojoin in all profiles that link to it. Mathieu signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
