@dragospirvu75 @matrix @delta @lazarus The way to achieve interoperability is to stop reinventing the wheel and agree on one standard. Implementing three protocols is completely unfeasible and unnecessary. This worked 20 years ago with MSN, ICQ and AIM when IM protocols had a lot less features and no E2EE. Doesn’t work today.

@daniel Someone have to solve https://soatok.blog/2024/08/04/against-xmppomemo/ issues first

@tris two things: I already said in my follow up post that if someone wants to build their own clients on top of XMPP and prefers MLS over OMEMO, the XMPP community is very open to that. A protocol is much more than just the encryption. They would still benefit from all the other things XMPP has solved.

A lot of what's in that blog post is ill-informed and bordering on disinformation and fear mongering.

@daniel Ah, fair, their work for E2EE Fedi looks interesting: https://github.com/fedi-e2ee/public-key-directory-specification

@tris there are three actively developed protocols for federated instant messaging (XMPP, Matrix, Deltachat). At least one of them is very open to new developers and new ideas and has a structure in place to collaboratively work on those ideas and bring various stake holders together. With no disrespect to that individual I don't see why there needs to be a forth protocol loosely based on ActivityPub.

@tris Soatak is an expert in cryptography. I’m not. I’m more than happy to stand on the shoulder of giants when it comes to E2EE. That’s why we used the Signal Protocol 10+ years ago for #OMEMO and are now looking towards #MLS. However, good, interoperable protocol design is so much more than just E2EE. And maybe I've learned a thing or two about protocol design in my career that they don’t necessarily know.

@daniel @tris I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.

I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?

@pixelschubsi @tris Yes, agreed. Tremendous value in reusing identities and login credentials. Big skepticism with regards to using AP as a protocol. One can probably kinda make it work… But why? What’s the benefit?

@daniel @pixelschubsi @tris The benefit is in having a single account for all types of online communication.

To preface — I'm in agreement that ActivityPub probably isn't the best protocol to use for instant messaging. There's a lot of FUD still being spread about XMPP and I am outside of most of those discussions. NodeBB only supports AP at current.

That said, there's interest in pursuing AP as a delivery protocol for instant messaging because integrating a separate protocol is a heavy lift for everybody involved. It's a heavy lift if you already support AP, and it's a heavy lift when you support no federating protocols at all. Imagine a site looking to federate... now they have to use AP+XMPP? AP+Delta? etc...

Setting aside all the existing reasons why AP isn't ideal, I will say this... It clears the baseline expectations:

1. Messages can get sent via AP
2. Messages can be privately addressed via existing AP addressing mechanisms

That's it. The rest is icing. Really important icing, but for 99% of conversations, icing.

@daniel@gultsch.social @pixelschubsi@troet.cafe

@silverpill @pixelschubsi @tris you can have a single account (or as I phrased it 'identity and login credentials') across different protocols.
For example your Google account works across multiple protocols. And even in the federated world we have several cases where email address == xmpp address.
So to repeat myself: using the same identity is good. Doesn't mean you are locked into ActivityPub if you want to build instant messaging.

@julian @daniel I'm looking at it from a different perspective. IMO the Mastodon server (as an example) doesn't need to implement XMPP itself (it could, but it doesn't need to). Just like it doesn't implement HTTP itself.

It could instead rely on existing implementations. Take an existing XMPP server, reverse proxy its websocket endpoint, use the existing Mastodon auth to sign in, and embed an existing XMPP web client in the web frontend.

@julian @daniel so in practice it would probably be the other way round: that heavy lifting you're rightfully afraid of has already been done and even the large tail of the remaining 20% (that in reality need 80% of the effort) are largely done.

If we were to agree to go the XMPP route, we could have fully-featuered deployment-ready implementations of instant messaging on top of AP identities in weeks to months. If it's something entirely new on top of AP, it's going to take years.

@julian @pixelschubsi I understand the instinct of wanting to reuse the parts you already have. Protocol parsing, identities, profiles etc. However those will very quickly become extremely minor building blocks in the complexity of instant messaging.
It's very easy to underestimate the scope and feature creep of IM. I've seen this happening in other places where people initially think that IM is just passing some messages around. And then users demand more features and then you reinvent XMPP.

@daniel@gultsch.social absolutely, the same naive expectations happen often when people think forums are easy to build

@pixelschubsi@troet.cafe is definitely on to something about re-using an existing XMPP server in order to avoid the heavy lift. The less the maintenance burden for me, the better as far as I'm concerned.

@daniel I was just checking out the Wikipedia page, thanks for the pointer. … does it work well peer to peer? Identifies seem to be tied to a domain?

XMPP - Wikipedia

(en.wikipedia.org)

@benjohn it's not a peer to peer protocol. It's federated - meaning you can pick a provider - like email or the Fediverse.