Comment by danabramov
21 days ago
For me, part of it is that we have no power collectively against products turning their back on users because coordination to "export data all at once and then import it into specific other place" is near-impossible. So this creates a perverse cycle where once you capture enough of the market, competition has very little chance unless they change the category entirely.
What AT enables is forking products with their data and users. So, if some product is going down a bad road, a motivated team can fork it with existing content, and you can just start using the new thing while staying interoperable with the old thing. I think this makes the landscape a lot more competitive. I wrote about this in detail in https://overreacted.io/open-social/#closed-social which is another longread but specifically gets into this problem.
I hear you re: not wanting "weird aggregation", that just be a matter of taste. I kind of feel like if I'm posting something on the internet, I might as well have it on the open web as aggregatable by other apps.
Thanks for your thoughts. I do feel like this is all very specifically connected to Twitter. Which tech people really adopted, but I never used much, so it is interesting that these different perspectives are somewhat tied to one's megaplatform(s) of choice. I don't know of another social network that has inspired such a consistent effort to be forked or cloned. I do kind of feel like "change the category" and create a new network with the traits you want to see is the right move.
For better or worse, Twitter built their network. That many people willingly signed up and posted and continue to post there. I don't think anyone really should be able to fork it, because the users didn't collectively agree to that, and they don't all agree on what a good road or a bad road is. Ultimately, they can choose to leave if and when they want. Are these networks rather sticky, yes of course, but that's life.
We've seen lots of social networks come and go, things do change over time, there's ample opportunity for new ideas to flourish. In that sense, AT is perfectly welcome to throw their hat in the ring and see if that resonates and sticks. If people want their social network to be forkable, that concept will succeed.
I do think it misses what a lot of people find valuable about the tangibility and constraints of "I am making this content specifically for this platform and this audience at this point in time." I don't think most people think of their social media posts as a body of work that they want to maintain and carry over in an abstract sense independent of platform, and give open license to anyone to cook up into whatever form they can dream of.
I don't this is tied to Twitter.
Just the other week, another service that people actively used called Bento announced shutdown: https://bento.me/. This sucks for the user.
Someone created an alternative called Blento (https://blento.app/) on AT. Of course, by itself, this doesn't mean they'll be successful. But the thing is that, if Blento shuts down, someone can put it right back up because (1) it's open source, and (2) the data is outside Blento. Any new app can kickstart with that data and get people's sites back up and running. And two platforms can even compete on top of the same data.
I agree content is tailed to the platform and resurrecting something doesn't necessarily makes sense. But that's the point of lexicons. You get the choice of what makes sense to resurrect (actively moving to an alternative) vs what doesn't (something with a style that doesn't work elsewhere) vs new recontextualizations we haven't even tried or thought of. I think it's early to dismiss before trying.
Adding more to this, what's wild to me is that Blento can already show public data from other AT apps on the homepage. For example, your teal.fm plays. It's just one of the block types: https://bsky.app/profile/flo-bit.dev/post/3mcqx5pwrrk26. Despite teal.fm not really even "existing"!
It feels like file formats and protocols is the wrong prism through which to view this. What users actually want is the ability to move as much data as possible from point A to point B, whilst remapping it as much as possible to meet the different features and identities of point B. A unified data format is actually a hindrance for meeting that need because it boils it all down to a lowest common denominator. A simple data pump utility that just copies data back and forth, with lots of special case logic like "X has a character limit of 5000, Y has a character limit of 500 so I'll truncate and add a link to the original post on X", is going to work far better for this use case.
More generally I feel like you kinda missed the point of filing systems in your first writeup. The moment you say "posts don't have natural names", ok, that's a serious problem that should put a halt to the entire concept. A file is nothing but a natural name for a byte array and a little bit of metadata. That's why we think of file managers and explorers when we think of what files are all about: lists of names. It's also why people directly use files for relatively few things - they were a big deal in the early days of personal computing because the killer apps for it were direct translation of physical office tasks. It's mostly but not entirely possible to come up with natural names for office documents (the gap is in suffixes like "draft final v3__real final draft.docx"). That's why we use analogies for 1950s paperful office objects like files and manila folders to begin with. But most computing tasks even back then weren't oriented around documents, they were oriented around database records and the user interface was just screens, or possibly direct SQL. It's a remarkable gap in our infrastructure that there is no agreed on file format for a SQL result set. Maybe Arrow is that format.
>A unified data format is actually a hindrance for meeting that need because it boils it all down to a lowest common denominator.
Exactly, which is what I'm saying in the article:
We could try to put every app developer in the same room until they all agree on a perfect lexicon for a post. That would be an interesting use of everyone’s time.
(That's meant to be slightly sarcastic.) Then the article says:
For some use cases, like cross-site syndication, a standard-ish jointly governed lexicon makes sense. For other cases, you really want the app to be in charge. It’s actually good that different products can disagree about what a post is! Different products, different vibes. We’d want to support that, not to fight it.
The point isn't having a lowest common denominator format. It's to enable precisely the granularity of formats that app developers want. The default one is "each app has its own formats". But what changes is that
1. Other apps can still read/write in other apps' formats. This makes the landscape competitive: if some app is going down a bad road, it's easy to fork their product with all the data already in there.
2. It is possible for multiple app developers to use the same format where it makes sense. As linked from the article, https://standard.site/ is a good example of that.
>More generally I feel like you kinda missed the point of filing systems in your first writeup.
I'll admit that I used the metaphor to highlight a specific thing, and names in particular don't play a big role in that thing (what plays a big role is links). The reason I picked filesystem as a metaphor is because it highlights how file formats mediate interactions between apps. This is exactly how lexicons mediate interactions between social apps. That felt like the backbone of the argument.
It's true this isn't describing a filesystem exactly. Maybe a web of identity-addressed hyperlinked JSON is a more precise way to say it. But then nobody knows what that means. I'm happy with my choice of metaphor.