By John Gruber
WorkOS: APIs to ship SSO, SCIM, FGA, and User Management in minutes. Check out their launch week.
Bluesky: Twitter Announces Effort to Build ‘Decentralized Standard for Social Media’
Wednesday, 11 December 2019
Jack Dorsey drops a bombshell:
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.
Twitter was so open early on that many saw its potential to be a decentralized internet standard, like SMTP (email protocol). For a variety of reasons, all reasonable at the time, we took a different path and increasingly centralized Twitter. But a lot’s changed over the years…
First, we’re facing entirely new challenges centralized solutions are struggling to meet. For instance, centralized enforcement of global policy to address abuse and misleading information is unlikely to scale over the long-term without placing far too much burden on people.
The whole thing could (and perhaps is likely to) fizzle out, but if successful, decentralizing Twitter-like social media should be a huge win for the world. But why create something new? There’s a whiff of boil-the-ocean in Dorsey’s description of the plan — “blockchain” is the new second step in the South Park “(1) Steal underpants, (2) …, (3) Profit!” to my mind).
I advocate something different, Twitter already has the bugs and scaling issues solved for a global notification network. Let’s add a few APIs and create a new universe. It’ll happen a lot faster with much better results imho. […]
It’s time for a proprietary approach, one that is open to cloning. That can work because there’s a single decision-making entity. If their goal really is to create a standard they can do it, much the way we created standards for content syndication when our product dominated.
What’s the downside to letting the Twitter API as it stands be v1.0? Let third parties implement it, clients could connect to any compatible service, communication between services would evolve as needs evolve, you end up with something designed naturally (see HTML5 vs XHTML).
The HTML5 vs. XHTML analogy is exactly what triggers my spidey sense with Bluesky. XHTML was a boil-the-ocean plan to create a new version of HTML, its creators’ ideal for how HTML should be used — a prescriptive spec. HTML5 took the approach of standardizing how HTML already was being used — a descriptive spec. We all use HTML5 today.