mastodon - Link to source

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.

#Jabber #Conversations_im

#xmpp #Jabber #conversations_im
This entry was edited (3 weeks ago)
in reply to مسعود

mastodon - Link to source

Daniel Gultsch

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

@masoud

@مسعود

Daniel Gultsch reshared this.

in reply to Zash

mastodon - Link to source

Marvin W

@zash 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?

@Zash
This entry was edited (3 weeks ago)
in reply to Marvin W

mastodon - Link to source

Daniel Gultsch

@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.
@Marvin W @Zash
in reply to Daniel Gultsch

mastodon - Link to source

Marvin W

@zash In fact, we'd probably want to use something like trust messages to have the new client be trusted by an existing client. And the existing client would then notify all contacts about both, the new client existing and the old client trusting it. If we encrypt the roster/avatar/vCard, we need some means for the new client to retrieve the encryption key from the old client anyway - at least in the regular case where you still have such a client.
@Zash
in reply to Daniel Gultsch

mastodon - Link to source

gdt

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.
in reply to Daniel Gultsch

mastodon - Link to source

Gonzalo Nemmi

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.

#XMPP #Jabber

#xmpp #Jabber
⇧