Modern XMPP project discussion - 2024-12-26

> How can you defend XMPP against claims that it leaks too much metadata compared to something like SimpleX? it is better for now as you say yeah. and the problem is it has multiple layers and it will take a lot of effort to close all the issues. some of them are: - MLS encryption that leaks less metadata and opens the door to authenticated member list in group chats. - ERIS https://eris.codeberg.page/ that would make it possible to remove "from" and "to" and have some kind of "sealed sender" thing (like signal) in XMPP. - Adoption of random identifiers like SimpleX where leaking them does not matter because them nothing. That would require moving off of DNS tho and to something like GNS (Gnu Name System) but that would be a pretty big architectural departure from how XMPP currently works and incompatible with everything else. ↺

>> How can you defend XMPP against claims that it leaks too much metadata compared to something like SimpleX? > it is better for now as you say yeah. and the problem is it has multiple layers and it will take a lot of effort to close all the issues. some of them are: > - MLS encryption that leaks less metadata and opens the door to authenticated member list in group chats. > - ERIS https://eris.codeberg.page/ that would make it possible to remove "from" and "to" and have some kind of "sealed sender" thing (like signal) in XMPP. > - Adoption of random identifiers like SimpleX where leaking them does not matter because them nothing. That would require moving off of DNS tho and to something like GNS (Gnu Name System) > > but that would be a pretty big architectural departure from how XMPP currently works and incompatible with everything else. ❤️ ↺

> enshittification etc. ❤️ ↺

MSavoritias (fae,ve), a lot of people seem to mention Signal’s sealed sender stuff, but a lot of the privacy as well as anti-spam management in XMPP is based on knowing who the sender is, so you can give them appropriate answers, or drop their messages before they reach the user.

Have you given any thought about that issue?

i agree it would be horrible to just remove from or to and be done with it. XMPP as in RFC 6120 depends on it atm

it would need a rethink of the architecture. same way you can't just "drop DNS" and move on

what i mentioned is a small part of a more "radical" rethink

that was relevant to the question at hand that is ✏

river client by freenet has some interesting proposals for how to manage rooms differently https://github.com/freenet/river?tab=readme-ov-file#invitation-tree

> Have you given any thought about that issue? to be more precise yes, that is what i have been thinking and reading for a few months :) i have been reading specs, writings specifications (XEPS and RFCs) and have started a project based on that. the river link above is part of the idea how to manage room spam. if it manages to get through anyway. with an ocapn architecture spam is a lot more costly than the current architecture ↺

Sealed sender in Signal is privacy theatre

We could theoretically do better in XMPP, since it is decentralised, but there are other ways to do it too

is there any research or XEPs being done on it to read?

it could help with my own research to it or collaborate on it

MSavoritias (fae,ve): not that I'm aware of, though I know larma is keen on this