XSF Discussion - 2024-06-03

Concerning occupant IDs I got the impression that these seem to "mitigate" the anonymity of MUCs which is actually be design. This I find akward because it feels like "first we design MUC such that anonymity is at the core of its design; then we build something on top of it to benefit of non-anonymous semantics". I feel that whatever problem(s) occupant IDs are supposed to help solve, it would have been nicer to solve this in accordance with the MUCs anonymous principles, i.e. every operation which requires notion of global identifiability (JIDs) or local identifiability (occupant IDs) should be the responsibility of the MUC. For the few examples which I can think of (e.g. message edits), this seems perfectly consistent with the notion that a MUC is merely a "proxy user who impersonates its occupants towards eachother". Long story short: I wonder, is my understanding of the MUC semantics wrong, or are there scenarios which I didn't think of, or am I right and occupants ID were merely a practical, but semantically incorrect concept? ✏

Concerning occupant IDs I got the impression that these seem to "mitigate" the anonymity of MUCs which is actually be design. This I find akward because it feels like "first we design MUC such that anonymity is at the core of its design; then we build something on top of it to benefit from non-anonymous semantics". I feel that whatever problem(s) occupant IDs are supposed to help solve, it would have been nicer to solve this in accordance with the MUCs anonymous principles, i.e. every operation which requires notion of global identifiability (JIDs) or local identifiability (occupant IDs) should be the responsibility of the MUC. For the few examples which I can think of (e.g. message edits), this seems perfectly consistent with the notion that a MUC is merely a "proxy user who impersonates its occupants towards eachother". Long story short: I wonder, is my understanding of the MUC semantics wrong, or are there scenarios which I didn't think of, or am I right and occupants ID were merely a practical, but semantically incorrect concept? ✏

Occupants id's make a room pseudonymus, not longer anonymous. I like that. For me the main reason it is semi-anon is so the jids can't be harvested easily and spam is less. On the other hand, what's the benefit for you to it beeing anonymous to everyone but moderators?

manday: I think you misunderstand it, occupant id does not change your anonymity

lovetox no I'm aware of that, that's why I call them "local identifiability", i.e. they allow others to uniquely identify you as a single account within a room.

Yeah and how does that make you not anonym anymore

I think manday means that you can’t leave and join with another nickname?

Well you can, but others will know that it’s the same account, but that’s the point the occupant ID XEP :)

A lack of anonymity is not my concern. It's rather that I think this might conflate concepts -- or add concepts where none are needed, at the cost of making the protocol more complex. It seems like an arbitrary choice to thereby make users "locally", but not "globally" identifiable (i.e. you can trace them within a room, but not across rooms), but this is inherently unrelated from spam protection. And we do all this by adding complexity / new semantics to the protocol where the existing semantics of MUC would be perfectly well suited.

manday: I believe what you propose make server implementation much more heavy

The server would need to have archiving with no expiration and inspect every stanza?

It would make it the burden of the server (i.e. the MUC), yes. Whether it's "heavy" I couldnt tell, but semanically it seems the correct choice. And I'm not sure the cost of implementig occupants IDs and the new semantics that come with it in the clients is less than just make the MUC properly ("as intended by design") handle message edits, leaves and joins etc.

> The server would need to have archiving with no expiration and inspect every stanza? I wouldn't say archive without expiration, necessarily, but yes, every stanza must be considered, such is the job of the MUC by design. ↺

(as it's impersonating users towards eachother, it has to do some effort for that)

With expiration, how does the server make sure a ‘retraction stanza’ is valid? ✏

It can only up to the expiration time, yes.

Just like the clients need to keep that history, too. But with MAM is that really that much of extra workload?

Don't know what you are talking about, the client needs to know that a user is not impersonating another. For that reason a unique Id needs to be assigned

No server gymnastics can help you

lovetox can you specify "impersonating" a bit more? Because the ability to "impersonate" to some extent is itrinsic to anonymity, no?

No it's not, and I don't accept your notion that MUC was build for anonymity, if it were it would be a sad try

lovetox: the server could filter out impersonations?

> No it's not, and I don't accept your notion that MUC was build for anonymity, if it were it would be a sad try I just need you to be more precise what you mean by impersonating, so that I can respond with an argument. ↺

I’m not saying it would be good, but I don’t why such gymnastics would be impossible?

It may not have been build *for* anonymity, but it was build such that it was anonymous by design.

Anyway manday, nothing prevents current MUC implementations to do what you propose I think. mod_muc_filter_impersonations.lua is just waiting to be written 😉

Just to be clear I'm neither complaining nor expecting, I just want to learn whether my perspective is consistent.

I may be wrong (I’m not involved in the occupant ID XEP), but I think the rationale is to let, as much as possible, the server be a ‘light message passing service’ instead of requiring it to query its archive for every stanza that passes through.

manday, the problem is that nicknames can change

even while you are sending a request

nevermind

I was confused

manday: With occupant ID, the server does not have to ‘know’ a lot about the semantics and potential abusability of things that pass through. Without it, any extension with abuse potential requires server-side update to avoid abuse. ✏

nicoco I completely understand and agree to both, that it's a good principle to design the protocol by to let the server be a lightweight forwarding entity, and that occupant IDs work towards that goal. Just then MUC has been the wrong design in the first place, because by MUC being realized by the server acting as a "proxy" user, that *does* imply that the server needs to do work.

If the server wants to have as little work as possible *and* the communications should be authenticable, then sooner or later it will have to start acting transparently and thus anonymity is not a viable foundation.

Which brings me back to the point that the demarcation of "occupant IDs" vs "JID" seems arbitrary; at this point we can aswell be entirely transparent and work with JIDs directly.

manday, note before occupant id the avatar essentially served the same purpose

ie, identifying the same JID across nicks even worse it still identifies the same JID across different rooms on different servers :D

manday: anonymity in MUC context means just that your JID is not available to a subset of occupants.

> but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

That's the full extent of the definition of anonymous

It's not at all touched by occupant-id and hence does not undermine any design considerations

(it's why it's called "semianonymous" actually)

lovetox yes I'm aware

No it doesn't undermine them (and as you said anonymity probably was never a design goal in the first place), but it needlessly adds a concept where we already have one. OIDs are per-room JIDs, which I think is needless because we already have JIDs.

Other approaches are most likely not backwards compatible

Once you start using OIDs you are no longer *entirely* anonymous. You are traceable within a limited realm.

Tell us your idea I'm sure it was considered

But if you even start to fuck around with the occupant JID, I can tell you right now it's not backwards compatible

Under the assumption that we want to keep the MUC/server maximally light, I would just use JIDs directly. It doesn't matter whether a user loses anonymity in a limited realm/scope (the room; by OIDs) or entirely.

I don't get it

> But if you even start to fuck around with the occupant JID, I can tell you right now it's not backwards compatible All right, I see ↺

occupant ID does lose you anonymity, but it downgrades to local pseudonymity. ✏

which is ... a lot better than real JIDs everywhere.

> which is ... a lot better than real JIDs everywhere. You are thinking of spam protection, I assume? ↺

no, I'm not

I'm thinking of general abuse, not just spam.

Ah ok, then what's the problem with JIDs everywhere?

(see above)

What's an example of general abuse that's not spam please?

harrassment for instance

had it via MUC PMs, don't need more of that directly to my main JID.

Oh okay I get it, like someone trying to gain access, too. Yeah, I get it

> had it via MUC PMs, don't need more of that directly to my main JID. All right but as far as those are concerned you actually give the example yourself that being addressable in a MUC is no better than being addressable by your main JID - in both cases you receive spam and you're only able to protect yourself through compromise (leaving the MUC). ↺

leaving the MUC is a much better solution than burning my main JID though.

burning my main jid is a couple orders of magnitude worse ✏

(and the game goes both ways: with occupant-id, a MUC admin has more leverage against such abuse within the MUC)

well

not a MUC admin

(sorry I'm not fully aware yet)

a MUC admin doesn't benefit from occupant-id

It's still an unjust solution. My point about using JIDs is moot (not backwards compatible, exposes attack surface, ...), but in principle one could argue that you can realize the same compartmentalization of realms of identifiabilty which you achieve with OIDs by using multiple JIDs

but a client or user serevr can block abuse based on occpuant-id instead of just the nickname

manday, on the receiving side that's true, but occupant-id enforces identifiability on the sender side, which is useful for ^

For servers, yeah I didn't think of that.

But wait if we're talking about JIDs the sender would also be identified...

The only purpose to dislike occupant Id is that you can't rejoin with different jids and make people believe you're someone else. Or is there another?

For me that's a good thing

Well you can just use another account Menel ;)

Yes

You said "can't rejoin with different jids" though? 🤔

What's the benifit if not having them?

> What's the benifit if not having them? My original point was only for conceptual simplicity. OIDs are, however, yet another XEP ↺

I see. But it's already there now and implemented. And anything achieving something like it needs implementing. So seems it's the easiest now

If you're interested in the design, You should join the xsf and watch the mailing lists/inbox so you can improve the xeps before they are implemented manday 🙂

I guess there is always need for critical eyes

i tend to be a lot of talk little code and i don't think that's very appreciated but i get your point

also as you can see in this case I'm a lot for concepts and little practicability, i think the xsf has a much better balance without people like me. surely not a lack of highly qualified guys ;)

They explicitly say coding and tech is not needed (telling that I'm also only watching)

> If you're interested in the design, You should join the xsf and watch the mailing lists/inbox so you can improve the xeps before they are implemented manday 🙂 No need to be a xsf member to discuss specs, and this room is a fine venue to do so too! Mailing lists are easier to browse and organise discussions though. ↺

manday: tradeoffs, tradeoffs! If you don't care about pseudo-anonymity, just use non-anonymous rooms?

When you are an XSF member and have not voted yet on our Q2-2024 applicants then please take some time and talk to memberbot to cast your votes. Thanks.

because of changed travel schedule I need to move our member meeting from June 6th to *June 5th*. Its updated in the XSF event calendar. The new meeting particulars are: Date: June 5th, 2024 Time: 19:00 UTC Location: xmpp:xsf@muc.xmpp.org

Thanks Alex

thank you, Alex, voted now :)

manday: if you're interested in anonymity the 👌 is burner jids. There just isn't a lot of tooling for this built yet. I agree that semi-anon is awkward and there's a reason no other protocol does this. Transparent jids with optional burners jids would be better for most cases. But that doesn't mean we need to stop everything we do now and switch entirely to that world, since what we do now already works and is compatible with anyone who wants to move to that world

great answer, thanks!

Getting back to "are PEP native bookmarks only for groupchats?"… Crazy idea: why not use <conference> elements for groupchats, but also allow <chat> (or <direct-chat>, or <whatever>) elements that can also be 1:1 chats? I'm trying to think of how we can get "pinned" and "notification filtering" synchronized across clients without introducing new PEP nodes, I'm not trying to revive the "are direct chats chat rooms or not?" debate. 😉️ ✏

Sure. We could change the xep to say <conference is MUC and other kinds of chats have different elements. Though since the elements will have some similar data needs (autojoin etc) it might be a bit redundant that way

nicoco just for the info I wrote some times ago a XEP about Bookmark pinning using the <extensions/> in the PEP Native bookmarks XEP https://xmpp.org/extensions/xep-0469.html :)

edhelas: I know this one! and I'm wondering how we could use it for 1:1 chats too.

Yes that xep was what convinced me we are in danger of having dozens of pep nodes that are all lists of your chats + one bit of info

Because people didn't want to allow it for 1:1

You all know my vote on solution 😅

singpolyma: I don't have a dog in the "are direct chat conferences too" fight and I've read arguments from both sides, I'm trying to find a middle ground. I wonder if <conference> for groups (not only MUCs!) and <direct-chat> for erm, well, direct chats could be a valid solution.

Having an element for all kinds of groups not just mucs would be bad IMO, because then we still need some way to check what kind of group it is

Well in any case clients have to handle invalid data in there, don't they?

> <direct-chat> for erm, well, direct chats could be a valid solution Maybe we need a nonza like xep for defining what is a direct chat 😅 then we could have a disco for it too, which I kinda want

I'm thinking about this because I very much would like my "gajim workspaces" synced across multiple gajim instances <https://dev.gajim.org/gajim/gajim/-/issues/11847>. My initial idea was a custom PEP node, but bookmarks <extensions> would fit nicely if we could stuff direct chats in there too.

For that specific case I would use roster <group/>

That's what it is for, after all

I see two issues with roster groups: (a) a roster entry can be in 0 to any number of groups and (b) this does not cover pinning and notification settings

Being in multiple groups/workspaces seems useful, no? And yes, this is specific to that case not related to pinning etc

FWIW, my groups are used to classify my contacts by transport (ie bridge/gateway/new funky way to name this thing), and gajim workspaces by a "non-technical" logic. I'm not saying it's how roster groups should be used, but it's an example of having two orthogonal uses for the groups and workspaces concepts.

Even more reason it's good we allow one chat to be in multiple groups :)

nicoco, I think you are talking about one of the workspace features that were discussed already. I remember that when we talk about workspaces, there was the motivation to have two kinds: user private workspaces (that is what Gajim has, but synchronized across clients) and shared workspaces (discord, slack, etc). To the client they are largely the same, except that you are always "admin" of your user private workspaces and all rooms in it are "guest rooms" (rooms that don't sync permissions from the workspace)

I actually think "user workspaces" and "server workspaces" (discord, slack, whatsapp communities, etc.) are two very different things. Also, I think that pinning and notification setting exist in most clients but workspaces never will in some, so I don't believe it would be a good idea to tightly couple the workspace to these concepts. ✏

I don't think notification settings has anything in common with workspaces

And I wouldn't know why we don't want those two workspace categories to use the same or very aligned specification

To a client, the two workspace categories largely look the same, in fact as I mentioned, a user workspace can totally be resembled using a server workspace which is owned by that user and only has external rooms.

You want external rooms in server workspaces anyway, you want to have admins in server workspaces as well.

External rooms, as in, room from another server? ✏

yes

I think one of the purposes of server-side workspace is to facilitate administration and moderation

well not strictly "other server" but not managed through the workspace ✏

Yes, there is also non-external rooms in server workspaces

I see. Well, OK.

But in case I was to create a Dino developers workspace (that is server side and shared with all dino developers), I likely want to have the XSF discussion room as an external room in there ✏

Fair.

That's why user workspaces are very much a strict subset of server workspaces

Someone™ just has to finish writing that ultimate spaces XEP that covers all use cases then 😉️

That's another problem 🙂

Notification setings are a whole other topic with other interesting aspects

I think perfect is the enemy of the good, and we can reach that "ultimate spaces XEP" incrementally, and gajim having non-standardized, purely local workspaces is already a step in this direction. Anyway, start of the discussion was how acceptable it would be to allow <direct-chats> elements in the bookmarks node, and let pinning and notification settings be both bookmarks extensions.

I did start the spaces doc, but I really don't have cycles I'm afraid to make much progress.

https://wondersheep.uk/scratch/spaces.md.txt

oh you write it in markdown, there is a script (pandoc extension maybe?) to turn that to XML, right?

nicoco, https://github.com/xsf/xeps/blob/master/tools/2xep.lua

I was trying it in markdown because it was claimed to me that this was the way forward. My success with the scripts was then limited.

Yeah they're only guaranteed to work if you're me :P

Oh I know that story Zash, in my field we call that "data science" and/or "academic code"