I think #XMPP has a relatively clear and achievable path to drastically reduce the amount of metadata, but I’m increasingly worried that it is not going to move the needle in terms of adoption.
For 99.99% of people, the only relevant feature for an instant messenger is simply 'Are my friends using it?' The other 0.01% are equally divided between people who already use XMPP and don’t mind the metadata, and people who won’t use it anyway.
@daniel I think you are 100% correct on your assumption: it won't move the needle at all
But, personally, I fail to see how that's a good reason enough not to follow that path and drastically reduce the amount of metadata as any step on that direction can only bring beneficial results for the whole ecosystem regardless of the impact on the adoption rate.
As a matter of fact, at least 3 of the points you described on your technical details should probably be already implemented.
@daniel As someone who tries to get others to use safe chat (vs gmail, FB, etc.), I understand your 99.9% comment. But, I ask people to install Signal or DeltaChat, because XMPP in practice lacks guaranteed e2e encryption (OMEMO fine, but it's not forced on), and I find including photos baffling and/or not secure (alternate upload server, not in-band). These are my two pain points, and that's for someone who has been using XMPP and running a server for 25(?) years.
@daniel
Very interesting! May I ask, what this "relatively clear and achievable path" is? Does it already have a XEP? Is it implemented by any project? Is there any plan?
To anyone curious about the technical details:
• Go roster-less. I seriously considered that for Quicksy. You basically just do it.
• Per device offline queue. With SASL2 the server knows what devices a users has. Discard messages once you know every device has received them.
• Sealed sender. With SASL anonymous and PEP we have some good building blocks for that. Basically just have to come up with semantics of which key pairs go where.
• Stanza Content Encryption with MLS or OMEMO
@daniel Won't this just move rosters into PEP subscriptions while kicking out the legs of our current anti-spam efforts and breaking all our nice access controls?
( And where's my server dev fun if servers are reduced to dumb pubsub routers? 😢 )
@zash @daniel I don't think we'd use PEP subscriptions, but rather encrypted, client-initiated notifications. So whenever I change my encrypted avatar PEP node, I would also send a notification to all the people in my encrypted roster replacement PEP node so they can fetch the updated avatar.
Wouldn't we still have sender JIDs and access controls / spam protection based on this?
@larma @zash And once there is enough passive, encrypted communication (for example receipts and displayed markers) a sender also has more ways to passively learn about new devices of the recipient. OMEMO 0.4+ basically includes a device list which one can then verify through a pull from PEP. Traffic wise that might even be more efficient than a generic +notify.
