[Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
jonas at wielicki.name
Tue Mar 20 18:21:14 UTC 2018
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
> 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
> 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 <nick/> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards