There is a significant difference between developing and promoting a protocol (such as XMPP) and a product (such as Signal). Both approaches have their advantages and disadvantages. This post details how and why Snikket aims to strike a balance between the two.
I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP
I don’t quite understand what this means, could you elaborate?
if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol
That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).
The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.
Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.
I think it’s at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.
I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP
I don’t quite understand what this means, could you elaborate?
For me, what is interesting about XMPP is that – if federated – it permits for the kind of open environment that email has traditionally has. An open market, where one can choose a provider, and there aren’t walled gardens.
It’s not that I’ve sat down and reviewed the different messaging protocols and decided that there are fundamental, unfixable issues in other messaging protocols. That is, it’s not specifically XMPP that’s valuable, but the fact that XMPP (can be) deployed in a federated matter, like email.
You could hypothetically even add federation to other protocols, or gateway among them. Gatewaying is doable if various providers are willing. I’ve run bitlbee on my Linux system before; that’s a server that locally acts like an IRC server, permitting the use of IRC clients, but gateways messages to a number of other protocols and services; gatewaying writ small. From my standpoint, that’d also solve the problem, if all the messaging providers were willing to gateway to other systems. Early-on, when the walled email gardens opened up to Internet email – Compuserve, AOL, etc – they did gateway to the Internet.
And you can layer protocols on top of that, like OTR, to provide communication security.
I think that the problem isn’t “XMPP as a protocol” is interesting, because if there was one big messaging provider and it internally used non-federated XMPP, we wouldn’t really notice a difference.
And it doesn’t even, honestly, require use of a single, explicitliy-federated protocol. That’s useful for things like addressing handling routing – it creates a single convention, that username@xmpp-host is a way to reach a user. If you used gateways, you might have user@xmpp-host.external@traditionally-nonfederated-messaging-system. We had stuff like UUCP that did that some decades back, and you could build some sort of system for looking up a route to a user. Hell, I’m not even convinced that XMPP has that necessarily right – maybe it’d be better to be user@pubkey-signature, to permit for cross-host account portability. We could have ICQ and Matrix and Signal and SMS all co-existing with gateways, and that’d work okay from my standpoint.
Federated XMPP is designed to work like email, to have global interoperability, but even a shift to XMPP doesn’t guarantee that that happens – or that, over the long term, that’s where we wind up, even if we start there.
I don’t think that the issue is really one of protocol, but of interoperability. Moving to XMPP won’t (necessarily) solve it, though I wouldn’t be sad to see things move in that direction. And it’s a problem that can be solved without moving to XMPP; we could even do it with multiple messaging protocols.
I think that the issue is one of business incentives. If you have a good chance to be a walled garden, you don’t want a competitive market, because competition kills your ability to make money. If you are big enough, you can leverage network effect to gain an advantage – your users provide value to the network, and you control access the outside world can have to your users – and lock-in. You are disincentivized from decoupling from other services in that you want your users to have access to those other users, but as one provider becomes a relatively-larger share of the network, their incentive to leverage access to their userbase grows and the disincentive of cutting off the outside world decreases; they tend more towards trying to be the new walled garden.
That is, I think that the core problem is one of incentives surrounding interoperability among providers. As a user, I would like to have a competitive market. As a provider – at least one with a chance to be The One Walled Garden – I don’t want a competitive market. Interoperability makes for a competitive market; it tends to commoditize a provider’s service insofar as they can’t leverage access to their users any more.
That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).
I’m not really trying to beat up on Snikket here in particular. They may be just fine (or are today). I’m just trying to provide a broader take on the problem that the author is talking about – the walled garden versus open system problem.
I don’t quite understand what this means, could you elaborate?
That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).
The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.
Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.
I think it’s at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.
For me, what is interesting about XMPP is that – if federated – it permits for the kind of open environment that email has traditionally has. An open market, where one can choose a provider, and there aren’t walled gardens.
It’s not that I’ve sat down and reviewed the different messaging protocols and decided that there are fundamental, unfixable issues in other messaging protocols. That is, it’s not specifically XMPP that’s valuable, but the fact that XMPP (can be) deployed in a federated matter, like email.
You could hypothetically even add federation to other protocols, or gateway among them. Gatewaying is doable if various providers are willing. I’ve run bitlbee on my Linux system before; that’s a server that locally acts like an IRC server, permitting the use of IRC clients, but gateways messages to a number of other protocols and services; gatewaying writ small. From my standpoint, that’d also solve the problem, if all the messaging providers were willing to gateway to other systems. Early-on, when the walled email gardens opened up to Internet email – Compuserve, AOL, etc – they did gateway to the Internet.
And you can layer protocols on top of that, like OTR, to provide communication security.
I think that the problem isn’t “XMPP as a protocol” is interesting, because if there was one big messaging provider and it internally used non-federated XMPP, we wouldn’t really notice a difference.
And it doesn’t even, honestly, require use of a single, explicitliy-federated protocol. That’s useful for things like addressing handling routing – it creates a single convention, that
username@xmpp-hostis a way to reach a user. If you used gateways, you might haveuser@xmpp-host.external@traditionally-nonfederated-messaging-system. We had stuff like UUCP that did that some decades back, and you could build some sort of system for looking up a route to a user. Hell, I’m not even convinced that XMPP has that necessarily right – maybe it’d be better to beuser@pubkey-signature, to permit for cross-host account portability. We could have ICQ and Matrix and Signal and SMS all co-existing with gateways, and that’d work okay from my standpoint.Federated XMPP is designed to work like email, to have global interoperability, but even a shift to XMPP doesn’t guarantee that that happens – or that, over the long term, that’s where we wind up, even if we start there.
I don’t think that the issue is really one of protocol, but of interoperability. Moving to XMPP won’t (necessarily) solve it, though I wouldn’t be sad to see things move in that direction. And it’s a problem that can be solved without moving to XMPP; we could even do it with multiple messaging protocols.
I think that the issue is one of business incentives. If you have a good chance to be a walled garden, you don’t want a competitive market, because competition kills your ability to make money. If you are big enough, you can leverage network effect to gain an advantage – your users provide value to the network, and you control access the outside world can have to your users – and lock-in. You are disincentivized from decoupling from other services in that you want your users to have access to those other users, but as one provider becomes a relatively-larger share of the network, their incentive to leverage access to their userbase grows and the disincentive of cutting off the outside world decreases; they tend more towards trying to be the new walled garden.
That is, I think that the core problem is one of incentives surrounding interoperability among providers. As a user, I would like to have a competitive market. As a provider – at least one with a chance to be The One Walled Garden – I don’t want a competitive market. Interoperability makes for a competitive market; it tends to commoditize a provider’s service insofar as they can’t leverage access to their users any more.
I’m not really trying to beat up on Snikket here in particular. They may be just fine (or are today). I’m just trying to provide a broader take on the problem that the author is talking about – the walled garden versus open system problem.