Well, it looks like Elon Musk is buying Twitter. Pandemonium!
Fueling our cope and seethe is the fact that the structure of Twitter is fundamentally feudal. This town square is owned and controlled by a single company, now perhaps by a single person. There is lofty talk about democracy and free speech but there are no mechanisms for self-governance, no procedures for holding power to account, no checks and balances, no due process, no bill of rights. This is a battle for the Iron Throne. Who sits on the throne makes the rules. Pray for a benevolent despot.
But does it have to be this way? What if you weren’t locked in? What if Twitter offered credible exit? What might credible exit look like? In what ways might we enable it?
Credible exit
I’ve been developing rough notes on credible exit ever since I saw this exchange on Twitter. My thinking in this post is in-process, but I figured now is a good time to get something down on paper.
I like “credible exit” as a framing because it has clear value. Credible exit is also practical. There are examples of credible exit in the wild today. Let’s look at a few and see what we can learn from them…
Examples of credible exit
DNS offers credible exit for your domain name. You can move your files from one hosting provider to another and change the server your domain name points to. This prevents any one hosting provider from trapping its customers, and creates beneficial competition between hosting providers.
This decoupling of names and servers is part of the layered design of the internet. Layering is a useful tool for improving credible exit. Layered architectures create shearing layers in the system, where a part of the system can be decoupled and swapped out for something new.
Email offers credible exit for your social graph. It’s all there in your address book. The protocol is federated, so you can change between competing providers. You can even save your emails to your computer, or move them between services.
Federated and decentralized addressing schemes like email addresses and URLs are useful for credible exit, because they make it easy to reference things across services, and to move useful information between accounts through simple copy-paste.
Podcasts offer credible exit for subscriptions. Most podcast players let you import and export your subscriptions via an OMPL file. WordPress is a similar example. It lets you move your content between Wordpress installs with an XML file. Wordpress is so popular that many competing CMSs have implemented support for this export file. Hostile interoperability!
Mirror.xyz offers credible exit over distributed protocols. Mirror is kind of a Web3 Medium, with everything replicated to ARWeave, and pointers written to the Ethereum blockchain.
A competitor can fork Mirror and create something better or different. If Mirror disappears, a motivated developer can reboot it. The value of on-chain exit isn’t totally theoretical. When the on-chain service Hic et Nunc went down, it was mostly resurrected just days later. Interesting! I can’t imagine this happening with Medium, for example.
Github offers credible exit for code — a byproduct of building GitHub on top of Git, which is a distributed protocol. This credible exit isn’t perfect. You can git-clone many things on GitHub, including code, wikis, and websites, but you can’t clone issues, or GH-actions, or accounts, or many of the other services on top that make GitHub so effective. Still, it’s pretty good!
Git offers distributed sync nearly for free. This is a powerful primitive for credible exit.
Mastodon offers credible exit for communities. This constellation of Twitter-like services voluntarily federates with each other. Anyone can spin up their own Mastodon server. Users can message each other across servers. If your server goes off the rails, you can move to another.
What is the important axis of exit?
Credible exit happens through protocols. They might be implicit or explicit, but protocols are how communication happens between systems. This is one reason credible exit is often imperfect, even when it exists. Apps can evolve quickly, but protocols must evolve slowly. It is difficult to reify all of the behavior of an app in a protocol. When you do, it’s going to freeze that behavior in place. That’s not great.
Still, we might choose an axis of exit that aligns with the most important thing about the app. Perfect credible exit for everything might not be feasible, but at least we might offer a protocol for the most important things.
What is most important? It depends upon the app’s job-to-be-done. For email, this is the social graph, for Photos.app, it is images, for podcasts, your subscriptions.
Basic and generated data
At a glance, I see two broad buckets of data that seem worth thinking about, and possibly approaching differently:
Basic data: this is the content you create by hand. Photos you take, posts you write. This seems like a clear candidate for exit.
Generated data: the frosting on top that makes the app interesting. Likes, retweets, bookmarks, comments. You lose a lot if you can’t exit with this stuff. At the same time, the authorship of generated data is not always clear, and the line between data autonomy and privacy gets muddy here. Who owns my retweets? Should credible exit include comments on my posts? Should my social graph have credible exit and how easy should this be? Email makes this easy, and so did Facebook, until the Cambridge Analytica scandal! Right answers in this area are not always clear.
Dimensions of credible exit
I think there may be multiple dimensions along which to think about credible exit. An app might provide some or all of them.
I can export my data: This is pretty bog-standard due to GDPR regulations now. Often what you get is a zip full of JSON files. Pretty lackluster. JSON isn’t something that makes sense outside of an app.
Export also has the downside of being static. If you continue to use the app, your export becomes invalid. This makes export only really useful for hard exit. Still, it’s better than nothing. I might say “export considered harm reduction”.
I can sync my data, or at least export and re-import it multiple times. This resolves the “dead export” problem. It also makes export useful for other use-cases, like backup and basic interoperability between tools. One way to accomplish this is with immutable data. If the file never changes, it’s easy to sync. iTunes music library is a good example. CRDTs are a promising primitive for data that is frequently updated.
My data is in a useful format: exit happens through a common formats that work in other apps. Plain text, CSV, PNG, PDF, SVG, MP3 are all good examples of useful formats. Camera Roll is a standout example here. You can drag and drop images, in and out of the app freely.
This is one reason we’ve been prioritizing Lindy formats like plain text in Subconscious.
Also! What if there were a spreadsheet-like tool for slicing and dicing JSON? Could this transform GDPR-mandated data dumps into credible exit?
My data lives in local files. iTunes is a standout example. You can always take your MP3 files with you. Files are great because you have the bytes! Files also enable credible exit to emerge retroactively! New apps can come along and implement the file formats of other popular apps, uplifting their file format into a de facto protocol.
Multiple apps can share the same data over a permissionless API. This is where credible exit transcends itself and becomes broad interoperability.
The app is open source. A protocol will never capture the full fidelity of the app experience, but if the protocol and app are both open, you might unlock much deeper credible exit. Mastodon is a great example here.
Credible exit in Subconscious
So those are my working notes so far. Credible exit feels like a useful lens through which to consider user autonomy. It admits small, imperfect, and simple solutions (plain text export, archive with wget, etc) while leaving room for progressive improvement (local-first software, distributed apps, etc).
Aiming for credible exit is why Subconscious writes plain text files. It’s also the reason we’re experimenting with distributed protocols like IPFS for sync and multiplayer.
Update 2022-08: We’re building Noosphere, a protocol for thought that guarantees credible exit.