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 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.