Comment by mike_hearn
1 month ago
That's true if you define the problem as "does my parser crash" and not whether the app is perceived as working correctly. If some platform adds support for video posts, then the next thing that happens is people start making posts that are only video. Meaning that in every other client, users see what appears to be an entirely empty post. Which will be considered a bug.
This is the core argument of Moxie's seminal essay, The Ecosystem Is Moving:
https://signal.org/blog/the-ecosystem-is-moving/
One of the controversial things we did with Signal early on was to build it as an unfederated service. Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.
That was written in 2016 but it was true then and continues to be true today. Users reject federated open platforms because the coordination costs mean they don't move as fast as proprietary centralized platforms, and they often appear broken even if technically working as designed.
Nothing about that analysis is unique to social media. It is also true of file formats. OpenOffice never took off because new features got added to Office first, so files that used those features would open in semi-corrupted ways in OpenOffice. The fact that OO represented things internally using open unions didn't matter at all.
I disagree that Bluesky is in conflict with The Ecosystem Is Moving. In contrast to most decentralized/distributed protocol projects they've managed to maintain control of almost all of their infrastructure with the exception of the personal data servers (pdses) of which they control 99.01%[1]
Almost all ATProto apps just fetch posts by handle => did:plc => post-type aka "lexicon", so they depend on what Bluesky decides to give them. If someone were to introduce unknowns into the flagship product's "lexicon" they could fix that at the API or Indexing level before shipping this data to the apps that depend on their API.
An actually decentralized network would have to overcome Moxie's criticism of the ecosystem. Can it be done? We'll keep trying.
[1] https://arewedecentralizedyet.online/
Well, this doesn't prevent the "flagship" app from shipping things and doesn't slow it down. So it's at least not slowing down development which is the argument the parent post was making.
I've actually observed the exact opposite thing. Since Bluesky is open source, it's often visible when developers start working on a feature. And they often check in lexicon changes early on. As a result, there's been a few cases where third party client actually added support for these features earlier than the official one since they already knew the shape of the data.
This wouldn't always work, of course. Yes, if you're developing an app or a client, you better keep up with the ecosystem. But the landscape is competitive and there is no cost to switching. So if something falls behind, you can use something else.
Moxie's argument is that even if something has a flagship app, this doesn't help because if you use a new feature and then your friend complains that they can't see what you posted, the experience is just that the flagship app itself is broken. People don't experience this as, oh well, my friend should just have picked a better client. They experience it as, that's annoying, the video feature doesn't work reliably on Y but it always does on X.
An extreme example of this is WhatsApp and emojis. WhatsApp doesn't use the operating system's text rendering APIs to draw emojis, instead Meta license the Apple emoji font and draw the characters themselves. That's because if you do emoji the standards based, open way you get these problems:
• People use visual puns that only make sense if emojis look a certain way, without realizing they might look very different to other people.
• People use new emoji, without realizing that old operating systems can't draw them.
The experience in both cases is that it's simply broken and buggy. Version skew can kill platforms, which is why the most successful platforms today restrict which clients can connect and forcibly expire them on a regular basis.
BTW I don't think it's worth generalizing from Bluesky. Bluesky is an X clone whose unique competitive advantage is censoring conservatives even more aggressively than Twitter itself once did. It has no technical edge so they can develop the site as open source without it being a concern to them - they don't care if they leak what they're doing because technical innovation isn't a part of their brand to begin with - and the AT protocol clearly doesn't matter to more than a tiny fraction of its users. The point you're making in the essay is general, but ends up feeling overfit to Bluesky.
There is always one party "in control" of the lexicon and its canonical version.
I think it's important to distinguish this from the "every client adds their own features" thing. Technically yes, each app can add their own things to the open union that they support better. But it's also on each implementer's to consider how this would affect UX in other clients (e.g. if you add your own embed type, it seems reasonable to also prepopulate a link embed that acts as fallback). The problems you're describing are real, but I think we should give a bit more credit to the app builders since they're also aware that this is a part of their user experience design.
But still, whoever "owns" the lexicon says what's canonical. Then yes, some other software might not catch up to what's canonical but that's similar to what's happening with any platform that supports multiple clients today. Unless your outlook is that alternative clients in general are not competitive for this reason. I think that's a grim outlook, and if that were true, services wouldn't go to extra lengths to intentionally shut down their APIs, which so has been the trend with every network.
I think in longer term the bet is that the benefits unlocked by interop and a more competitive product landscape will become clearer to end users, who will be less interested in joining closed platforms and will develop some intuitions around that. This would not happen soon, so until then, the bet is that interop will allow creating better products. And if that doesn't happen, yes, it's pretty hard for open to compete.
3 replies →