[Standards] Bookmarks and autojoin issues

Maxime Buquet pep at bouah.net
Sat May 23 23:16:58 UTC 2020

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 <conference/> 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

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
-------------- 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/f6850a2f/attachment.sig>

More information about the Standards mailing list