alt Hacker NewsFor 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.
Replies
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.
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.