XSF Discussion - 2024-05-29

moparisthebest can you check my member status on #conversations please?

> I think we (Gajim) will change that in the future > > to allow corrects for older messages 🙏🙏

There's always new stuff to be found in XEP-0045, today was https://xmpp.org/extensions/xep-0045.html#register for me. It's not covered expliciely in the XEP, but does that imply that sending an in-band registration <remove /> IQ to a room should remove all affiliations of the sending account? Any server and/or client support for this? ✏

There's always new stuff to be found in XEP-0045, today was https://xmpp.org/extensions/xep-0045.html#register for me. It's not covered explicitly in the XEP, but does that imply that sending an in-band registration <remove /> IQ to a room should remove all affiliations of the sending account? Any server and/or client support for this? ✏

nicoco, Prosody does :)

Oh cool, I haven't seen any client support for this, but I guess it would be nice when closing a members-only room to be prompted whether you just want to "leave temporarily" or actually be "removed from the members of this room". This probably needs better wording though. Maybe just "Leave for now" and "Leave definitely. Warning: you won't be able to join the room unless someone make you a member again" (maybe just "invite you")

nicoco: yes, I'm planning to add that. I added auto-register when joining (if allowed) a few releases back. Need a prompt when leaving now, as you say

I also want to do a manual registration UI for channels that require more than a nickname on the form, but no server supports that yet so I haven't done it at the moment

singpolyma, I opened <https://dev.gajim.org/gajim/gajim/-/issues/11849> in the tracker of the only client I am skilled enough to contribute code to :)

nicoco: note it's not just for members only but any mucs where you have affiliation

"leave for real" could maybe also decide if eg bookmark is deleted and such

Also don't sell yourself short on skill 😉

Right, it means "unaffiliate me from this room". And indeed it makes sense for clients to combine this action with something bookmarks-related. Maybe not remove from bookmarks without prompting the user, but setting autojoin to false sounds reasonable.

For sure, what to do and how will depend on UX of the client. but yes

nicoco: it's been long enough to say but the trigger for singpolyma to implement that was an *awesome* ejabberd bug in a popular channel where when a message was moderated it kicked everyone from the room, spammer figured this out, would post obscene images, and join immediately with moderator nick+avatar and start spamming the shit out of it while preventing the real mod from joining

I do appreciate creative abusers pushing the ecosystem forward... If only there was a better way 🥲

ejabberd actually supports (non standard?) Registering of nickname across a whole MUC server

"non standard" in that it isn't in a standard anywhere. Not non standard in that it violates any standard or would benefit from being in one

"Non standard" but not "anti standard" then, maybe…?

Yeah, it's tricky words I guess. Usually I say "non standard" to mean "not useful to anyone who only implements the standards" but in fact clients can use the ejabberd thing without being aware of it, because it's entirely built on standards (ad hoc command for the ux iirc)

singpolyma, the bookmark XEP is for groupchats, because there is no mechanism in XMPP that tells a client which groupchats it is joined, hence we bookmark them, we remember where we were joined, hence the attributes password / nick / autojoin. just because someone added an <extensions> element to turn it now into a "store whatever about whatever" type thing, is ridiculous in my opinion. Whats next? Does the XEP say the item id must be an existing JID? no? so this means its just a key/value store where the key has the form of a jid? maybe i put the whole Gajim client configuration then in there, will sync nicely across all my devices.

"stealing" nicks sounds like a protocol breaking flaw. so if it was done for that it makes sense. ✏

If we rule that it's a violation of the XEP to store a non-MUC JID in it then we will need to throw out the XEP and make a new bookmark3 that explicitly allows it. Seems silly, IMO

> "non standard" in that it isn't in a standard anywhere. Not non standard in that it violates any standard or would benefit from being in one singpolyma: I just meant it's not written down in any standard, which would be nice because then prosody and others could implement it ↺

I guess I'd use "violates standards" for the other thing, why are we using such an imprecise language as English? 😁

moparisthebest: but since it's build using only standard tech, it doesn't need to be written down to replicate something equivalient. Like there's no benefit to using exactly the same form as ejabberd does or whatever

Discoverability is another reason to write it down, right now you have to know which stack overflow post to search for

heck, https://xmpp.org/extensions/xep-0048.html allowed bookmarking arbitrary webpages. I'm not arguing we go back to *quite* that generic of a bookmark system 😅

moparisthebest: you just need to have the feature idea occur to you right now

https://stackoverflow.com/a/34491233 btw

Right. So it's actually literally standardized already. It's just IBR

> If we rule that it's a violation of the XEP to store a non-MUC JID in it then we will need to throw out the XEP and make a new bookmark3 that explicitly allows it. Seems silly, IMO whats silly is, to side step the requirements defining stage, and discuss with the community proper solutions, instead simply adding stuff to an extension element because it syncs. ↺

> maybe i put the whole Gajim client configuration then in there, will sync nicely across all my devices. Hmm why not though

Did you just invent XEP-0049?

lovetox: if you're saying we need to throw out bookmarks2 and do bookmarks3 I guess we can. I just don't see the advantage to anyone of going that route here. We're not talking about "just because it syncs" we're talking about using the XEP for its intended purpose, which is to record metadata about known chats. But then saying we can't use it for anything that isn't using MUC protocol, so we need a new XEP with the words "might not be a MUC" even though current XEP already has those words

Maybe we should finally integrate bookmarks with the roster?

sure, it's just a second roster after all

A roster that doesn't track the "contact" subscription state

right, but does track other things

which is why we have two of them right now

(or three if you count the one in vcard4 xep)

singpolyma, im saying for a decade all metadata we wanted to record about JIDs, was 3 attributes related to groupchats. This solved a very real problem. No it was never the intention of the XEP to record general metadata about all JIDs there are. It never could, because there was never an extension element that would you allow to store more than the 3 attributes defined. Nobody changed or questioned this for a decade. Dont act now like it was always intendend and you are starting with it today. Thats the first thing that bugs me. Instead start a discussion with the problem you have, the metadata you want to record, and under what condition they need to sync, how many there are, does it encompass only JIDs? or other stuff etc. Lets brainstorm what we want to sync about contacts, maybe we need some kind of framework, where we have a base XEP that defines a pubsub node, and other XEPs that define extensions, etc As all of these attributes are new things that no client will have support for, i dont see any benefit to hook onto a decade old use case and retroactively make it work for whatever we want to do.

First of all, I didn't bring this up, the discussion on list was already about a metadata that was wanted to be stored and with all the things you request. I just pointed out that bookmarks2 was a sane place to store it. Secondly, I speak only about bookmarks2, which has always had the <extensions/> element (though of course it doesn't really need it since it should always be possible to extend by adding new namespace children to any element... but clearly there was concern here so it was added when the XEP was written, which is fine and I'm not arguing with). Thirdly, if you're talking about historical bookmarks "3 attributes related to groupchats" seems not quite true for a XEP which also specifies for example bookmarking arbitrary webpages (which I'm also not suggesting we add to bookmarks2. I'm not suggesting we add anything at all)

The extension element is the pillar of any such XEP, because it not just defines a place where to add data, it defines that all clients need to *preserve* them, independent of the fact if they support it or not. Without that rule in the XEP, no extension that you add would work, because client not supporting the new elements would always overwrite them.

singpolyma, I don't understand why everything we store on the server needs to be in a single thing. We have roster for contacts, it stores information relevant to contacts (user bare jid, nickname, subscription state). We have bookmarks for MUCs, it stores information relevant to MUCs (room jid, title, autojoin, our nick). Now we added displayed state as a new pep storage (xep-0490) which works for both MUCs and direct chats (even non contacts).

Now to store notification settings (which is what was the reason for the discussion) we can of course store them with the bookmarks for MUCs and differently for non-MUCs, or we store them in a new PEP node for both. I personally would suggest to treat direct chat and MUC differently: notification on mention is a meaningful option in MUCs, but not in direct chats. Also in MUCs notify on keywords (and synchronizing which keywords) is interesting. For direct chats, really there is only a muted flag and even that is probably not super important (if you don't want to read someone's messages at all, mute seems to be the wrong tool, if you just don't want to be notified on some devices, e.g. because it's a work contact, synchronizing the mute flag really wouldn't be helpful either) ✏

Now to store notification settings (which is what was the reason for the discussion) we can of course store them with the bookmarks for MUCs and differently for non-MUCs, or we store them in a new PEP node for both. I personally would suggest to treat direct chat and MUC differently: notification on mention is a meaningful option in MUCs, but not in direct chats. Also in MUCs notify on keywords (and synchronizing which keywords) is interesting. For direct chats, really there is only a muted flag and even that is probably not super important (if you don't want to read someone's messages at all, mute seems to be the wrong tool, if you just don't want to be notified on some devices, e.g. because it's a work contact you want to keep off your private matters, synchronizing the mute flag really wouldn't be helpful either) ✏

I would prefer to have all „conversation” related settings in a single pubsub node. That would allow me to have a single source of truth and not to check many places just to find out if I should send a notification or not.

Andrzej, I was about to write this as a reason to have a dedicated pep node for notification settings, which would then be used by push notification systems as well.

single node is definitely what i would go also for, also a XEP like this would need some kind of registry, where we could more easily update and define new metdata/settings about a contact

Additionally, I’m not sure if rooms/groupchats I join shouldn’t be aware of those settings as well, ie. to trigger push notifications only when needed as I’m not sure that any MUC sends messages to offline users out of the box that could trigger push. And even is some does, it requires registration in the MUC and enabling push notifications.

I was just wondering how meaningful and reasonable a mute flag for direct chats is at all. I totally get people want to mute MUCs for messages that are not relevant to them (without mention or that are not a reply or similar criteria), but I don't really get the purpose for direct chats.

i think it would be useful to not limit this XEP too much in the sense of "just notification settings" there are simple other settings and informations i want to store like is the chat pinned, muted, do i send chat state notifciations to this contact, do i send read markers, maybe even what encryption i use with this contact

larma, you have a brother you spams you because he sends you one word per message

but i currently have no time to deal with it

for pinned, do you mean like xep-0469?

lovetox, I ban that brother 😀

I use „mute” for 1-1 conversations, ie. when I still want to talk to someone, but I do not want notifications form them as they are constantly reminding me to do something

yes, but obviously this is the wrong xep for it extending bookmarks

i think the author realised this a short time after publishing the xep

I get the feeling we are drifting into the "solving social problems with tech" realm

not really, larma, if you want to bikeshed any setting that any client has, then we will not get forward

if its not useful to dino, ignore the setting ..

as for „we need registry” I think we need a „base” XEP that defines storage and we need to build on that with additional XEPs

Mute is a common functionality on many messengers also for single chat

lovetox, my point is rather that many people might want to configure their clients differently

e.g. I want notifications on one client but not the other

sound like a job for the busy state?

We can of course make yet another new pep node for this, but it feels like an anti pattern to keep doing this every time just because of an interpretation issue with bookmarks2. At summit it was discussed to store chat meta in bookmarks2 and it seemed we got to consensus but I guess not. Anyway, I don't have much skin in the notification settings game specifically, it wasn't my idea, I'm just pretty worried to see pep node proliferation for this. ✏

I think that having many nodes for many things will just generate a lot of overhead just to fetch all settings

I already have this issue with my two clients. I turned off bookmark sync on Conversations because I didn't want to join every room on my phone that I join on my desktop. Now next issue is, that if I accept an invitation on my phone, there is no way to chat in the room from my desktop later, because the bookmark from the phone is not synced there.

Andrzej, generally agree, but I would want to make a differentiation for things that are processed server-side and things that are not.

I think the issue is that bookmark sync assumes that it should autojoin on other clients, correct?

^ singpolyma see, Conversations implements a setting to not sync bookmarks, because it *expects* that only MUCs are in there, otherwise this setting make no sense, because the user cannot even know what metadata are in the bookmarks

larma, that could be tricky think to do

retroactively modifing a XEP that has a specific purpose for a decade, is only pain

That setting doesn't actually turn off bookmark sync, it turns off a particular way if using the sync in the UI. Also that setting is gone now

"for a decade" I don't understand. almost no one implements this xep yet

We just got it working in elabbird in the fall

this XEP is just an iteration of the bookmarking use case like it was always used

the xeps says zero about storing metadata for all kind of contacts

> lovetox, my point is rather that many people might want to configure their clients differently A way to synchronize mutes across clients doesn't preclude a seperate per-client mute ↺

moparisthebest, agreed, but I guess the proper solution is probably a more sophisticated mute setting

on device type basis (mobile vs desktop)

I see this in other popular chat systems as well

My client doesn't yet have a way to "mute texts but still ring on calls" that phones commonly have, and I need that for example

can still be synchronized across devices, if you get a new phone you don't have to do the work all again

> "for a decade" I don't understand. almost no one implements this xep yet xmpp.org/extensions says 15 implementations of 0402 and 34 of 0048 (which is relevant because of conversion) ↺

Can someone explain to me in a simple, quick way in which sense the semantics of pubsub (and thus PEP) aren't just a subset/special case of MUC? ✏

manday: because they are totally different in every way

Semantically, how? What is missing from a MUC with one admin (pub) and members who can't write to the MUC (sub) to effectively give it pubsub semantics?

well you said you wanted a simple quick explanation :)

If anything it's the other way. Group chat being a subset of pubsub. That's how we got MIX ✏

If you think about it all of XMPP, or in fact, messaging in general, is just a subset of pubsub

You subscribe to get messages for your jid and rooms you are interested in, others publish to them, the end

Indeed

That's how simplex works isn't it? or nostr? of of those is just dumb pubsub with everything in the client

Muc isn't anything like pubsub at all, that's kind of the problem with it, from each client you join a room, but can never know if you are still in the room without constantly asking 💀

> That's how simplex works isn't it? or nostr? of of those is just dumb pubsub with everything in the client nostr at least is more of a broadcast I think, but modeled on pubsub, it'd be everyone subscribes and publishes to the same nodes, and your client filters out messages you don't want to see ↺

When you are a XSF member and have not voted yet in the current voting period then please take some time to cast your votes. Thanks

Done 🫡 and thank you for the reminder!

voted thank you for reminding us ! ✏

> Muc isn't anything like pubsub at all, that's kind of the problem with it, from each client you join a room, but can never know if you are still in the room without constantly asking 💀 does MIX solve this?

Solves that, but brings other problems, we can also just solve that with muc

oh yeah MUC2 sound pretty cool

I think MattJ is calling it MUX, I guess MIC was too racist sounding? :)

I like it call it XEP 0045 :P

=]]]]]]