[Standards] Bookmarks and autojoin issues

Maxime Buquet pep at bouah.net
Sun May 24 14:29:21 UTC 2020


On 2020/05/24, Stefan wrote:
> Am Sonntag, den 24.05.2020 um 00:41:53 +0200 schrieb mathieui at 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.
> 
>     <storage xmlns='storage:bookmarks'>
>       <conference name='Council of Oberon'
>                   autojoin='true'
>                   jid='council at conference.underhill.org'>
>         <nick>Puck</nick>
>       </conference>
>     </storage>
> 
> 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 <storage>:
> 
> <disable-autojoin>Conversations.ABC</disable-autojoin>
> 
> The result will look like this:
> 
>     <storage xmlns='storage:bookmarks'>
>       <conference name='Council of Oberon'
>                   autojoin='true'
>                   jid='council at conference.underhill.org'>
>         <nick>Puck</nick>
>         <disable-autojoin>Conversations.ABC</disable-autojoin>
>       </conference>
>     </storage>
> 
> 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 <extensions/> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200524/87d8f2d7/attachment.sig>


More information about the Standards mailing list