Hi, actual messaging app implementor here. (I researched, prototyped and co-implemented iChat at Apple in 2000-2004.)
The IETF set up a working group to do this in 1997 or 1998; I was subscribed to the ML for a while but it didn’t seem to go anywhere beyond writing some very vague feature specs.
Jabber/XMPP has of course been around since ~1999. It is a pain in the ass to implement (I did so for the iChat prototypes before Apple licensee the AIM engine), but a solid architecture that takes inspiration from the very successful example of SMTP. The real reason it never took off for IM is that the existing services (AIM, Yahoo Messenger, MSN Messenger, Google Chat) saw interoperability as bad for business … the exact same reason today’s social networks don’t interoperate.
So yes, I think this blog post is pretty naive. My biggest hollow laugh was at “messaging apps are all the same.” At a casual level, sure. But it’s the differences at the detail level that make interoperability, and designing a protocol that everyone can use, so difficult.
Why not XMPP? It’s been around for 20+ years, works well, and is extremely extensible. Social functions have already been implemented as extensions to XMPP before. No need to reinvent the wheel here.
That it’s extremely extensible makes it harder to write interoperable clients, people will implement a different subset of extensions and quite a few aspects are implementation-defined.
I still have nightmares from when I tried to set up a working XMPP video chat from my then-girlfriend’s macOS machine to my Linux machine. It all worked fine as long as everyone uses the same client, but when you don’t things can get very tricky. In the end I gave up and just used Skype.
Not everyone agrees with this, also see some of the comments on this previous story. For my part, I think providing a good UX is much more important than protocol choice and other technical aspects.
Second on proving a good UX. Just setting up a XMPP server is a pain because of all the options to enable and configure. It’s insane! Granted, once you have it, the features are pretty nice.
IRCv3 has a nice blend of features and extensibility IMO, but there aren’t very many clients out there that I could describe as “user-friendly”. I have some hope for Matrix, but I think it’s too early to tell if it will stick around.
Twitter is funding a small independent team of up to five open source architects, engineers, and designers to develop an open and decentralized standard for social media. The goal is for Twitter to ultimately be a client of this standard.
Apparently he either has never heard of Mastodon, or wants to create something that twitter can control completely (in which case, lol @ “decentralized standard”)
Bluesky did tweet this after the announcement so they could end up supporting ActivityPub/Mastodon - although if you give five developers the option to either support an existing system or build something from scratch I’d put my money on the latter…
As we mentioned, the team will have complete freedom to identify and consider all the great work already done, and if they believe it’s best to work on a pre-existing standard 100%, they will. If not, they’re free to create one from scratch. Their discretion, not Twitter, Inc’s.
So the team can decide to re-implement stuff from scratch to fit their tastes and get credit as the creators of a new standard while getting paid a Twitter salary, or cut their work short and use what already exists. Sounds like Twitter has created the conditions for one choice to be much more likely…
if you give five developers the option to either support an existing system or build something from scratch I’d put my money on the latter
That depends on the leadership of the (project) team. In my experience, it’s the younger and less experienced developers that push for reinventing things. In this case, it’s most likely going to depend heavily on the goals/requirements set by Twitter, so I’d be surprised if they end up going with AP.
Hi, actual messaging app implementor here. (I researched, prototyped and co-implemented iChat at Apple in 2000-2004.)
The IETF set up a working group to do this in 1997 or 1998; I was subscribed to the ML for a while but it didn’t seem to go anywhere beyond writing some very vague feature specs.
Jabber/XMPP has of course been around since ~1999. It is a pain in the ass to implement (I did so for the iChat prototypes before Apple licensee the AIM engine), but a solid architecture that takes inspiration from the very successful example of SMTP. The real reason it never took off for IM is that the existing services (AIM, Yahoo Messenger, MSN Messenger, Google Chat) saw interoperability as bad for business … the exact same reason today’s social networks don’t interoperate.
So yes, I think this blog post is pretty naive. My biggest hollow laugh was at “messaging apps are all the same.” At a casual level, sure. But it’s the differences at the detail level that make interoperability, and designing a protocol that everyone can use, so difficult.
[Comment removed by author]
Why not XMPP? It’s been around for 20+ years, works well, and is extremely extensible. Social functions have already been implemented as extensions to XMPP before. No need to reinvent the wheel here.
That it’s extremely extensible makes it harder to write interoperable clients, people will implement a different subset of extensions and quite a few aspects are implementation-defined.
I still have nightmares from when I tried to set up a working XMPP video chat from my then-girlfriend’s macOS machine to my Linux machine. It all worked fine as long as everyone uses the same client, but when you don’t things can get very tricky. In the end I gave up and just used Skype.
Not everyone agrees with this, also see some of the comments on this previous story. For my part, I think providing a good UX is much more important than protocol choice and other technical aspects.
Second on proving a good UX. Just setting up a XMPP server is a pain because of all the options to enable and configure. It’s insane! Granted, once you have it, the features are pretty nice. IRCv3 has a nice blend of features and extensibility IMO, but there aren’t very many clients out there that I could describe as “user-friendly”. I have some hope for Matrix, but I think it’s too early to tell if it will stick around.
Agreed, there’s every feature the author mentions in XMPP, open standard(s) for e2e encryption, and a plethora of good clients for mobile & desktops.
https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp%3F
[Comment removed by author]
Jack’s twitter thing announcing this:
Apparently he either has never heard of Mastodon, or wants to create something that twitter can control completely (in which case, lol @ “decentralized standard”)
Bluesky did tweet this after the announcement so they could end up supporting ActivityPub/Mastodon - although if you give five developers the option to either support an existing system or build something from scratch I’d put my money on the latter…
The team’s discretion, not Twitter’s?
So the team can decide to re-implement stuff from scratch to fit their tastes and get credit as the creators of a new standard while getting paid a Twitter salary, or cut their work short and use what already exists. Sounds like Twitter has created the conditions for one choice to be much more likely…
That depends on the leadership of the (project) team. In my experience, it’s the younger and less experienced developers that push for reinventing things. In this case, it’s most likely going to depend heavily on the goals/requirements set by Twitter, so I’d be surprised if they end up going with AP.
[Comment from banned user removed]
Reminds me of https://xkcd.com/927/
related to the topic: https://twitter.com/matrixdotorg/status/841424770025545730?lang=en
This is very interesting. But if the goal is to build upon the matrix.org network, why not just use Riot.im?
No, they should start with fucking right off outta the space.