Skip Navigation

Products vs Protocols: What Signal Got Right (Snikket/Prosody Dev)

snikket.org Products vs Protocols: What Signal got right

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.

9
9 comments
  • I mean, XMPP did get uptake. Google Talk used federated XMPP at one point in time. But...there's not much money for a service provider in an open, competitive market. If you can get enough users, you want to put up walls, leverage network effect. Then you get to have a monopoly on access to your users, and there's more money to be had. So there's always going to be people trying to get everyone into a single provider.

    I think that with email, the magic factor was that there was no one entity large enough to pull that off at the time that email became common. Today, there are actually startlingly few email service providers of the "pay me a fee, I give you a couple mailboxes" variety -- I was amazed when I went looking this year. I'm wondering whether email might become a walled garden before messaging stops being a walled garden.

    • That sounds roughly correct, though I don't see the connection with the article? Unless you're saying that "products" (like Signal) will always exist, which is probably true but is orthogonal to whether or not other models will succeed.

      As for email, I think posteo does a pretty good job, but you're right options are few and far between. But self hosting email is just as viable as ever? Perhaps less so since e.g. gmail will instantly flag your incoming mail as spam if you're sending it from randomsite.tld, but honestly that issue hasn't gotten that bad (yet). Yes, whenever there's a protocol like email or xmpp, companies will create gmails and signals and turn them into walled gardens, but that doesn't spoil the protocol for everyone else. It just causes frustration that companies build closed products on top of open technologies, but not much to be done about that.

      • That sounds roughly correct, though I don’t see the connection with the article?

        It's saying that XMPP didn't take off. I'm saying that there was some uptake (well, of federated XMPP...that's an important distinction, because a business running an in-house XMPP server that can't talk to the outside world doesn't really address the same issues), but that services shifted away from it because they didn't want to have the kind of open ecosystem.

        I think that that's a problem for anyone trying to encourage adoption of an open ecosystem. 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.

        That is, IIRC it was Meta that talked about linking up to the Fediverse a while back. But...one would want to understand what their end game is. If it's to do a Google Talk, to help bootstrap a new walled garden, that may be a problem.

        I'm not accusing the author here of aiming to do that either, but it'd be a concern that would be in the back of my mind -- if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol.

        self hosting email is just as viable as ever?

        I used to do that, but anti-spam mechanisms finally reached the point where I wasn't willing to hassle with it -- running your own mail server tends to trip a number of anti-spam mechanisms in various mail servers.

  • Ironically, Signal is about to move user IDs towards something unattached to telephone numbers and it had not been able to do so yet. Meanwhile, the slow moving XMPP has never made the wrong decision of using phone numbers because it was developed in an era when phones where a whole other thing than today's pocket computers. Instead, XMPP accounts are federated like Lemmy or email...

9 comments