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 <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. 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: [email protected] _______________________________________________
