1. 44
  1.  

  2. 31

    Email got lucky. A standard protocol managed to break down the walls of even the final fortress of resistance, AOL. This was achieved largely because the adoption of standard protocols by smaller providers allowed them to form a network together that began to threaten even America’s largest ISP.

    This is backwards. SMTP has been around since 1982 — twelve years before AOL connected to the Internet. When the first commercial ISPs appeared in the early ‘90s, providing SMTP/POP email accounts was an obvious requirement, and AOL just did the same.

    The open communication protocols with mass consumer adoption — HTTP and SMTP— were grandfathered in; they predate the commercial Internet. Everything since is proprietary. Which sucks, but I don’t know what to do about it. I played a minor role as XMPP and RSS/Atom fought the good fight, but got squashed by AOL and Google.

    (I guess SIP and related A/V protocols are in wide use and may be exceptions? But I know very little about those.)

    1. 6

      Thanks for your contributions @snej!

      XMPP was directly inspired by the architecture of SMTP, and it also suffered its largest weakness: spam.

      Having been a bofh/webmaster at a small midwest ISP from 94-96 my experience was that we would get people switching from AOL/CompuServe more-so to use 3rd party internet software like browsers and games. The fact that they could get a new email address and email update their contacts with it was definitely a big part of reducing the friction though.

      1. 5

        The open communication protocols with mass consumer adoption — HTTP and SMTP— were grandfathered in; they predate the commercial Internet. Everything since is proprietary.

        That was especially enlightening. I’ll definitely commit this to memory.

        1. 9

          Disheartening, isn’t it?

          When you’re a big player in a communications medium (like IM/chat), you benefit from network effects because your system gets more valuable the more users are already on it. Interoperability causes you to lose that; the benefits of the medium get spread around between all the interoperating systems. So the winners don’t want it.

          Also, as @quartzjer pointed out, incoming traffic brings legitimate problems like spam, that are a lot harder to deal with than in a closed system. These two things together explain why, when Google did enable an XMPP gateway, it was only for outgoing connections.

          I think any big new open communications media will have to be P2P. I used to say “…or federated,” but I’ve kind of lost faith in that, at least in the broken way Mastodon etc. are federated, where your identity belongs to whichever server you sign up with.

          (PS: IMAP might be seen as a semi-exception; I think it appeared in the late 90s. But it’s an “edge” protocol, between an ISP/mail service and its customers, so it doesn’t play the same role.)

          1. 3

            I think any big new open communications media will have to be P2P. I used to say “…or federated,” but I’ve kind of lost faith in that, at least in the broken way Mastodon etc. are federated, where your identity belongs to whichever server you sign up with.

            Agreed. There’s a fundamental problem though: to receive a message, machines have to be online. That’s the reason for federation over P2P. (Of course federation doesn’t work because setting up a server is a pain in the butt at best, and mos people have no idea how to do it.) So the P2P version needs a way to publish messages out there in the distributed hash table or something, such that the recipient can retrieve them later. Worse, you often have to get past NAT/Firewalls, and such hole punching often requires a mediating server…

            Or you try to install the server on people’s routers, which are almost always online.

            1. 1

              I think SSB made the right tradeoff here - you can sync P2P, or you can sync via a Pub(lic server) to get any content from friends who also visit the same pub.

              1. 1

                Yeah, that works pretty well. In the protocol pubs are mostly just “super-peers” with higher availability.

                Another approach is to route along the social graph. For instance, have every peer cache & route messages addressed to any ‘friend’ of the user. That way friends help pick up your mail while you’re on vacation ;-)

          2. 1

            It makes you wonder that if the mass-adoption had been delayed by a few years, that the situation would be better today. Then again, a lot of the problems were first realized after the mid 90’s–2000’s.

        2. 3

          (I guess SIP and related A/V protocols are in wide use and may be exceptions? But I know very little about those.)

          I don’t know as much about SIP’s history, but I can tell you H.323 and friends (the Bellhead/telecom equivalent to the “nethead” SIP) is more like ISDN over IP. I’m not sure how you could fit that into the comparison.

          1. 8

            I deal with SIP at work, and I’m convinced it was a conspiracy by the telcos to make it impossible for anyone other than a telco to get a connection established on the Internet between Alice and Bob. It’s a Byzantine protocol, and it took my company about five years to get one telco [1] to add an extra field to a non-core SIP message. The only advantage that SIP has, is that it is NOT SS7 and we don’t need to deal as much with a million dollar network stack that is no longer supported [2] with a command line interface that scares me, a user of the command line since 1986!

            [1] Technically, a vendor of one of the telcos we deal with.

            [2] Yup. We paid something like six figures to license an SS7 stack, and it’s now past its end-of-life. It’s horrible, but at the time, it was the “best of breed” SS7 stack. I shudder to think how bad the competition was.

            1. 2

              I will say my experiences with H.323 have been a lot better than my (fewer) SIP experiences. Establishment is certainly faster, at least.

              1. 1

                Have there been any attempts to simplify SIP? Honestly, every time I read over SIP it gives me a headache. I can only imagine what working with it regularly must be like.

                1. 4

                  Not that I know of. My manager went to an industry conference a year or two ago, and he said that the designers of SIP said they don’t like SIP.

          2. 8

            XMPP got a lot of things wrong. There are a bunch of successful IEFT protocols but the IETF has always required two interoperable implementations to move things forwards. XMPP also required this (or something similar) for ‘standards track’ things, mirroring the RFC mechanism, but there was never any incentive to advance things to standards track. I gave up on XMPP when there were no implementations of PubSub, yet all of the new and exciting things aiming for standards-track acceptance were built on top of PEP (Personal Eventing via Pubsub). Google ignored all of this for Jingle and released a reference implementation.

            XMPP started with jabberd as the reference server implementation, jabberd 2 took too long and didn’t get much buy-in so eJabberd became the reference implementation. There was never a reference implementation of the client side of the protocol (I don’t mean a reference client, just a permissively licensed library that implemented the client side of the protocol that clients can use). If you want to build an ecosystem for a client-server protocol, ship a permissively licensed reference implementation of both ends. This is especially important for an extensible protocol like XMPP, because it’s easier for people to build their own non-interoperable extensions than it is for them to support the standard.

            1. 1

              I gave up on XMPP when there were no implementations of PubSub, yet all of the new and exciting things aiming for standards-track acceptance were built on top of PEP (Personal Eventing via Pubsub). Google ignored all of this for Jingle and released a reference implementation.

              This must have been a long time ago. As PubSub and PEP are fundamental building blocks for many XMPP extensions, just as you described, they are ubiquitous in modern XMPP server implementations.

              1. 2

                I was involved quite actively back around 2002. By around 2008, it was a complete mess. I tried again about four years ago and couldn’t find two different mobile XMPP clients that implemented the same protocol for sharing pictures.

              2. 1

                I don’t think the XMPP people who cloned what they thought was the IETF process really understood the process. They cloned the process as described, and actual IETF practice is a bit different. As an author of ten RFCs, I should’ve seen that “two interoperable” requirement ten times, no? I think I have about three times.

                The IETF relies to an astonishing degree on a connected set of smart people and a network of old farts. Copying the wrotten rules doesn’t produce an IESG composed of people who know what rules need close enforcement and what not in each case.

                (And yes, the IETF fails to some degree. BGP is a well-known example; a production-ready BGP implementation has to implement the right drafts, and do it in the right way. The IETF does many things right, but even doing all of that is no guarantee of consistent success. But the XMPP people didn’t do all of that, they mostly just copied the rules and AFAICT didn’t try to do the rest.)

                1. 2

                  I don’t think the XMPP people who cloned what they thought was the IETF process really understood the process.

                  The process of the XMPP Standards Foundation (XSF) was probably mostly designed by Peter Saint-Andre, who is also the author of the XMPP RFCs (RFC 6120 / 6121). According to the IETF Datatracker he as written 46 RFCs in total.

                  Hence, I am not sure if I would concur with your statement.

                  As an author of ten RFCs, I should’ve seen that “two interoperable” requirement ten times, no?

                  The requirement is basically written down once in RFC 2026 § 4.1.2. Why do you expect to see it ten times?

              3. 5

                Despite a marked increase of signups on XMPP and Matrix servers, of these three it was Signal that won by far the largest share of new users.

                If I am not wrong, I think that Telegram has gained even more users than Signal over the last few months.

                Also, I am not sure if calling Signal a “product” is right, as they are not selling anything.

                1. 17

                  Products can be free. Services are products. Signal maintains some exclusivity and lock-in because not all of its software is free as in beer or free as in freedom. This closedness doesn’t make it bad necessarily but advantages competing for products that have these qualities to those who value them.

                  1. 2

                    Signal maintains some exclusivity and lock-in because not all of its software is free as in beer or free as in freedom.

                    May I ask what you are referring to here?

                    1. 6

                      It was my understanding some parts of the back-end of Signal are not publicly released yet, but maybe I’m behind on what’s been released. I see now that there’s Signal Server and the support docs seem not to indicate that anything is non-public anymore. So, I’m probably wrong and I’m pretty happy to be wrong in this case!

                      There’s still network effect lock-in with hosting the canonical instance, though. If someone goes and starts their own Signal instance, I’m not sure how they’d market it and there’s almost certainly no federation built-in to allow Signal™ Signal and the alternatives to intercommunicate.

                      1. 11

                        As far as I can see, the Signal Server repo hasn’t been updated for almost a year now. Development has clearly been ongoing but they’re apparently not publishing the source code any more. Not sure if there was any kind of announcement about this.

                      2. 2

                        I’m not “you”, but…

                        1. Signal relies very much on the server that is reachable by a particular domain name. Whoever has control of the server that answers requests to that domain name has considerable control.
                        2. The signal clients are open source (in name as well as in practice) but if you want to communicate with someone whose client needs to be using a patch you’ve written, your patch has to be merged into a branch controlled by Moxie, because that branch is what’s deployed to almost all of your correspondents.

                        Both of these are similar to XMPP, except different. If you want to make a change and want it deployed, you can’t on Signal, and also not on XMPP.

                        Most XMPP servers and clients are maintained by people you can’t persuade and most of the deployed clients and servers are updated by people you can’t persuade. But for Signal, one team, even one person, can, and that person isn’t you, so it’s very concentrated compared to XMPP, but similar in that you call precisely zero shots.

                      3. 1

                        My point was taht I think that “service” or “platform” would be a better word to describe what Signal is offering.

                      4. 8

                        Also, I am not sure if calling Signal a “product” is right, as they are not selling anything.

                        I understand the commercial connotations of the term “product”. Still, I’m mostly using it here in the broader sense of a package, a thing that is produced. The term fits what I’m trying to convey in practically every other way, so I think it’s a good choice overall. Not all products need to be sold and paid for.

                      5. 5

                        The Matrix folks are trying to learn from the mistakes of XMPP and are developing a product (element.io) to drive the protocol.