If you have a website, what are your earliest meaningful links that still work? I have almost no broken links at least since 2012 because I usually add a redirect whenever something changes.

Redirects help links in a healthy web resolve, avoid rot, and last a long time, but they also increase agency by letting own your data (own your URLs).

own your links

When I link to a platform I don't control, I try to at least use a URL that I do control. I have found this useful in recent years when switching my newsletter provider (/list), Mastodon instance (/mastodon), or crowdfunding platform (/fund)–I didn't have to change any links when that happened.

I'm considering even my Twitter account (/twitter in case the site goes bankrupt, and GitHub repositories (/hyperdraft-source) or YouTube videos (/strolling-0172-video) in case I start self-hosting; neither has happened yet, but if it occurs, I can easily update the destination once and point it somewhere else retroactively.

self-hosting a link manager

My links tend to be readable, but I like Derek Sivers' idea of making them short and speakable. I use YOURLS one-click self-hosted via Cloudron to manage my redirects which makes it easy to have both short and speakable if necessary; the links technically are something like go.rosano.ca/whatever, but because I own the data, I can make it further accessible under my root domain, as rosano.ca/whatever is often shortest, simplest, and most memorable. I also do the same contraction with blog permalinks so that utopia.rosano.ca/interoperable-visions/ can be accessed at rosano.ca/interoperable-visions; I stick with Ghost's simple permalinks design of /post-title-as-a-slug and find it more readable and predictable.

self-hosting legacy redirection

For legacy domains and permalinks, I made a simple single-file Node.js Express app (git push self-hosted via CapRover). There are about two dozen domains pointing to the same app to handle:

1. removing www.
2. correcting old and mispelled domains
3. redirecting archived projects to a single page
4. masking a domain that functions as a landing page
5. redirecting PeerTube links to YouTube
6. redirecting gibberish slugs to friendly slugs
7. redirecting to the Wayback Machine as a last resort, (but I may have done this one incorrectly, as it might cause some recursive issues).

This is hopefully a graceful degradation that takes care to guide existing links somewhere useful. It also supports HTTPS so if you write https://[OLD_DOMAIN] it works, which is not the case when you 'forward' URLs via registrars like Hover who only support writing http://[OLD_DOMAIN].

static versus dynamic

I love the simplicity of static sites and how they're basically free to keep alive forever, but all of my redirect pipework makes me feel forever tied to dynamic systems. It's possible to redirect via meta refresh on a static page but I find it ugly to write and manage with HTML; I'm also not sure if all search engines understand them, although Google claims to yet still recommends server-side redirects:

This tag, commonly called meta-refresh, sends the user to a new URL after a certain amount of time, and is sometimes used as a simple form of redirection. However, it is not supported by all browsers and can be confusing to the user. We recommend using a server-side 301 redirect instead.

conclusion

Maybe it's the librarian in me that finds it fun to have my stuff organized and moving along smoothly. I like the sense of ownership that comes with being able to direct links where I want, and the care to avoid throwing visitors into the weeds by making sure they land somewhere useful, always and forever.

---

If you want to keep reading, learn about the difference between fragile data and durable data, dream some interoperable visions with me, or marvel at how the person who wrote this needed six tries to learn iPhone programming.

---

If you have a website, what are your earliest meaningful links that still work? I have almost no broken links at least since 2012 because I usually add a redirect whenever something changes.

Redirects help links in a healthy web resolve, avoid rot, and last a long time, but they also increase agency by letting own your data (own your URLs).

own your links

When I link to a platform I don't control, I try to at least use a URL that I do control. I have found this useful in recent years when switching my newsletter provider (/list), Mastodon instance (/mastodon), or crowdfunding platform (/fund)–I didn't have to change any links when that happened.

I'm considering even my Twitter account (/twitter in case the site goes bankrupt, and GitHub repositories (/hyperdraft-source) or YouTube videos (/strolling-0172-video) in case I start self-hosting; neither has happened yet, but if it occurs, I can easily update the destination once and point it somewhere else retroactively.

self-hosting a link manager

My links tend to be readable, but I like Derek Sivers' idea of making them short and speakable. I use YOURLS one-click self-hosted via Cloudron to manage my redirects which makes it easy to have both short and speakable if necessary; the links technically are something like go.rosano.ca/whatever, but because I own the data, I can make it further accessible under my root domain, as rosano.ca/whatever is often shortest, simplest, and most memorable. I also do the same contraction with blog permalinks so that utopia.rosano.ca/interoperable-visions/ can be accessed at rosano.ca/interoperable-visions; I stick with Ghost's simple permalinks design of /post-title-as-a-slug and find it more readable and predictable.

self-hosting legacy redirection

For legacy domains and permalinks, I made a simple single-file Node.js Express app (git push self-hosted via CapRover). There are about two dozen domains pointing to the same app to handle:

1. removing www.
2. correcting old and mispelled domains
3. redirecting archived projects to a single page
4. masking a domain that functions as a landing page
5. redirecting PeerTube links to YouTube
6. redirecting gibberish slugs to friendly slugs
7. redirecting to the Wayback Machine as a last resort, (but I may have done this one incorrectly, as it might cause some recursive issues).

This is hopefully a graceful degradation that takes care to guide existing links somewhere useful. It also supports HTTPS so if you write https://[OLD_DOMAIN] it works, which is not the case when you 'forward' URLs via registrars like Hover who only support writing http://[OLD_DOMAIN].

static versus dynamic

I love the simplicity of static sites and how they're basically free to keep alive forever, but all of my redirect pipework makes me feel forever tied to dynamic systems. It's possible to redirect via meta refresh on a static page but I find it ugly to write and manage with HTML; I'm also not sure if all search engines understand them, although Google claims to yet still recommends server-side redirects:

This tag, commonly called meta-refresh, sends the user to a new URL after a certain amount of time, and is sometimes used as a simple form of redirection. However, it is not supported by all browsers and can be confusing to the user. We recommend using a server-side 301 redirect instead.

conclusion

Maybe it's the librarian in me that finds it fun to have my stuff organized and moving along smoothly. I like the sense of ownership that comes with being able to direct links where I want, and the care to avoid throwing visitors into the weeds by making sure they land somewhere useful, always and forever.

---

If you want to keep reading, learn about the difference between fragile data and durable data, dream some interoperable visions with me, or marvel at how the person who wrote this needed six tries to learn iPhone programming.

---

After the experiences that prompted my encryption rant, I have started to notice other moments when my digital stuff seems precarious, fleeting, as if slipping out of my hands; I hope to describe this a little and then consider some solutions.

fragile data

Encrypted messaging apps (like Signal and WhatsApp) can be volatile: you can easily lose access to your conversations; messages can fail to sync or deliver; your data might be secure with encryption, yet still trapped in an app.

Beeper and Texts help bring your messaging app data in one place, but export is not yet possible, even with open-source Element and the half dozen Matrix clients I've tried.

Platforms (like Discord, Slack, Telegram, or Facebook) don't let you own your messages: their systems can go offline and temporarily obstruct access; one of your contacts can delete their account and disappear your correspondence; smaller ones get acquired or shut down; you can only hope to get your data out or somewhere useful; your 'permalinks' (which you didn't own or control) break (remember that cool URLs don't change).

Microblogging platforms make it hard to own your posts: Twitter oscillates in states of chaos; Mastodon (or ActivityPub) ties them to whichever server you published from; Bluesky claims to let you move your data, but somehow it's not directly tangible.

Self-hosting gives you more control, but you still might end up losing stuff to 'export'. Discourse will give you SQL that has 'everything', which you need technical expertise to 'do something'; Datasette can be helpful to browse what you have and maybe convert to more accessible formats. Ghost claims creators get "access to 100% of their data", and WordPress claims you can "Own your data, all of it", but both their exports only include what they consider important; to actually get 'everything', you need to have systems administrator expertise to export SQL and download your images or attachments, then more expertise once you have all that and want to 'do something'. Consider export harmful unless proven otherwise.

I've been enthusiastic about personal data stores, but can admit it doesn't feel like it's in my hands.

---

Let's summarize 'fragile data' as:

• volatile access
• limited or no export
• data tied to a provider
• unusable formats (needing technical expertise)
• hard to see or manipulate data directly

durable data

I want to stop my stuff slipping out of reach as platforms change, depending on companies to stay around and hold it for me, or losing it to 'security', 'encryption', and 'export'. I want to have all my correspondence, publishing, and data, forever, defragmented from various networks and apps. I want to search my archive. I want to avoid being tied to a risky provider or format.

So far, the options that feel durable to me are email, files, Delta Chat, and git: they all continue to work, are supported by older systems and diverse new ones, and enable interesting possibilities via interop; the closest to 'future-proof' that I'm aware of.

email

Email will likely be around for at least as long as it has been around and remains ubiquitous and accessible to more people than any other data storage system. You can take your messages with you, switch providers, interact with everything in a variety of apps and clients.

Too bad many associate it with 'transactional B.S. from startups', 'marketing offers', 'newsletters one can't unsubscribe to', '10,000+ unread and no way to process'. Comprehensive solutions to information overload would be beyond the scope of what I'm writing (off the cuff, I can think of technical, philosophical, social, and political ones), but even if your main account isn't usable, it's easy and basically free to create a quiet new one to play with possibilities.

Email is a nice way to store data associated with a specific moment in time without considering how to structure files or tag items. Sometimes when I research an answer that I likely won't need anymore, I send myself an email instead of putting it in my notes. I would love to have a rich summary of activity on various platforms periodically archived there to maintain my history. Gmail used to harmonize chats and email by archiving and automatically grouping messages by conversation.

Email means copies. Using platforms with their own messaging system relies on the site to be online and hold your messages, while it's also possible for them to go offline (temporarily or permanently), erase data of someone who deletes their account, and sell or get acquired (sending your data who knows where). I used to delete emails with 'messages' sent on these platforms, but now I keep them as I don't trust the platform to do it for me.

Email is the original 'all your stuff in one place that you control', and as long it's designed to protect and respect your attention, it can serve an important function in supporting more durable data.

files

I don't like managing files and consider them a holdover from an older time, preferring interoperable apps (ideally as pluralistic lenses on data), yet they remain a useful response to ephemeral software. Files let you choose how to use them, and can be moved between different devices or storage providers.

I don't like hand-editing CSV, reading JSON or XML or HTML, but I'll be able to 'do something' with them probably forever. Plaintext is the way to my heart, and also one of the most interoperable types out there.

There are so many common formats and it's not easy to get an ecosystem to agree on which ones to use. Despite their limitations, having the data stored this way liberates it from any app. Your data could be available in these formats through export or integrations, but ultimately the app developer chooses whether to make that available; some solutions could be to ask people nicely, pressure companies publicly, or take it ourselves.

Delta Chat

(Disclosure: I've done paid work in the past to help with this project. I write my own opinions here to describe how it relates to durable data.)

Delta Chat uses your existing email account as a messaging app, and lets you do many things you'd want to do with apps like Signal and WhatsApp.

Unlike other messaging apps: you can move your messages between providers as easily as email; if the app goes away or stops working, you'll still have access to your messages (even if encrypted); it can help defragment your social graph across various platforms; it supports webxdc as an emerging way to do 'app things', including collaboration; it requires no permission, no company, and "no coins" to participate.

As documented in encryption rant, it's easy to transfer devices and never leaves me with the feeling that my messages will disappear. And because the data is stored in my email account, it's not dependent on any app, including Delta Chat itself.

It's basically as durable as email, with extra features and benefits: one approach to 'email without crap'.

git and GitHub

GitHub still leans technical but is becoming increasingly accessible.

It turns git into version control you can see and lets you edit directly on the site without installing apps.

There are virtually infinite integrations and automations available.

Backup, replication, and copies are built into the underlying technology.

Git enables credible exit from GitHub so you can take your files with you.

It's also collaborative and doesn't rely on a specific app's format of version control.

Connecting GitHub as the storage backend for apps would be a powerful way to enable backup and sync to multiple devices.

building for ownership

There's a reason why Zero Data defines data ownership specifically to mean 'having access without export or permission'. In the sea of shiny features advertised by apps, startups, and projects, it can be confusing to understand whether you actually have or own your stuff in the end.

'Encryption' helps avoid unauthorized access, but your data could easily disappear.

Many efforts that use the 'local-first' label focus on 'working offline', 'sync', and 'collaboration via CRDTs' without consideration for the seventh ideal of data ownership (perhaps leaving some company holding the data); in this way, plenty of Apple software could be misunderstood as 'local-first' while locking data into their ecosystem; DXOS is the closest I've seen to doing local-first right.

Ideally, data ownership is not a coincidental byproduct of someone's goodwill, but rather baked into how the system works. It should go beyond a technical concept to make people feel safe and able to trust the space as they might in a long-term relationship.

After the experiences that prompted my encryption rant, I have started to notice other moments when my digital stuff seems precarious, fleeting, as if slipping out of my hands; I hope to describe this a little and then consider some solutions.

fragile data

Encrypted messaging apps (like Signal and WhatsApp) can be volatile: you can easily lose access to your conversations; messages can fail to sync or deliver; your data might be secure with encryption, yet still trapped in an app.

Beeper and Texts help bring your messaging app data in one place, but export is not yet possible, even with open-source Element and the half dozen Matrix clients I've tried.

Platforms (like Discord, Slack, Telegram, or Facebook) don't let you own your messages: their systems can go offline and temporarily obstruct access; one of your contacts can delete their account and disappear your correspondence; smaller ones get acquired or shut down; you can only hope to get your data out or somewhere useful; your 'permalinks' (which you didn't own or control) break (remember that cool URLs don't change).

Microblogging platforms make it hard to own your posts: Twitter oscillates in states of chaos; Mastodon (or ActivityPub) ties them to whichever server you published from; Bluesky claims to let you move your data, but somehow it's not directly tangible.

Self-hosting gives you more control, but you still might end up losing stuff to 'export'. Discourse will give you SQL that has 'everything', which you need technical expertise to 'do something'; Datasette can be helpful to browse what you have and maybe convert to more accessible formats. Ghost claims creators get "access to 100% of their data", and WordPress claims you can "Own your data, all of it", but both their exports only include what they consider important; to actually get 'everything', you need to have systems administrator expertise to export SQL and download your images or attachments, then more expertise once you have all that and want to 'do something'. Consider export harmful unless proven otherwise.

I've been enthusiastic about personal data stores, but can admit it doesn't feel like it's in my hands.

---

Let's summarize 'fragile data' as:

• volatile access
• limited or no export
• data tied to a provider
• unusable formats (needing technical expertise)
• hard to see or manipulate data directly

durable data

I want to stop my stuff slipping out of reach as platforms change, depending on companies to stay around and hold it for me, or losing it to 'security', 'encryption', and 'export'. I want to have all my correspondence, publishing, and data, forever, defragmented from various networks and apps. I want to search my archive. I want to avoid being tied to a risky provider or format.

So far, the options that feel durable to me are email, files, Delta Chat, and git: they all continue to work, are supported by older systems and diverse new ones, and enable interesting possibilities via interop; the closest to 'future-proof' that I'm aware of.

email

Email will likely be around for at least as long as it has been around and remains ubiquitous and accessible to more people than any other data storage system. You can take your messages with you, switch providers, interact with everything in a variety of apps and clients.

Too bad many associate it with 'transactional B.S. from startups', 'marketing offers', 'newsletters one can't unsubscribe to', '10,000+ unread and no way to process'. Comprehensive solutions to information overload would be beyond the scope of what I'm writing (off the cuff, I can think of technical, philosophical, social, and political ones), but even if your main account isn't usable, it's easy and basically free to create a quiet new one to play with possibilities.

Email is a nice way to store data associated with a specific moment in time without considering how to structure files or tag items. Sometimes when I research an answer that I likely won't need anymore, I send myself an email instead of putting it in my notes. I would love to have a rich summary of activity on various platforms periodically archived there to maintain my history. Gmail used to harmonize chats and email by archiving and automatically grouping messages by conversation.

Email means copies. Using platforms with their own messaging system relies on the site to be online and hold your messages, while it's also possible for them to go offline (temporarily or permanently), erase data of someone who deletes their account, and sell or get acquired (sending your data who knows where). I used to delete emails with 'messages' sent on these platforms, but now I keep them as I don't trust the platform to do it for me.

Email is the original 'all your stuff in one place that you control', and as long it's designed to protect and respect your attention, it can serve an important function in supporting more durable data.

files

I don't like managing files and consider them a holdover from an older time, preferring interoperable apps (ideally as pluralistic lenses on data), yet they remain a useful response to ephemeral software. Files let you choose how to use them, and can be moved between different devices or storage providers.

I don't like hand-editing CSV, reading JSON or XML or HTML, but I'll be able to 'do something' with them probably forever. Plaintext is the way to my heart, and also one of the most interoperable types out there.

There are so many common formats and it's not easy to get an ecosystem to agree on which ones to use. Despite their limitations, having the data stored this way liberates it from any app. Your data could be available in these formats through export or integrations, but ultimately the app developer chooses whether to make that available; some solutions could be to ask people nicely, pressure companies publicly, or take it ourselves.

Delta Chat

(Disclosure: I've done paid work in the past to help with this project. I write my own opinions here to describe how it relates to durable data.)

Delta Chat uses your existing email account as a messaging app, and lets you do many things you'd want to do with apps like Signal and WhatsApp.

Unlike other messaging apps: you can move your messages between providers as easily as email; if the app goes away or stops working, you'll still have access to your messages (even if encrypted); it can help defragment your social graph across various platforms; it supports webxdc as an emerging way to do 'app things', including collaboration; it requires no permission, no company, and "no coins" to participate.

As documented in encryption rant, it's easy to transfer devices and never leaves me with the feeling that my messages will disappear. And because the data is stored in my email account, it's not dependent on any app, including Delta Chat itself.

It's basically as durable as email, with extra features and benefits: one approach to 'email without crap'.

git and GitHub

GitHub still leans technical but is becoming increasingly accessible.

It turns git into version control you can see and lets you edit directly on the site without installing apps.

There are virtually infinite integrations and automations available.

Backup, replication, and copies are built into the underlying technology.

Git enables credible exit from GitHub so you can take your files with you.

It's also collaborative and doesn't rely on a specific app's format of version control.

Connecting GitHub as the storage backend for apps would be a powerful way to enable backup and sync to multiple devices.

building for ownership

There's a reason why Zero Data defines data ownership specifically to mean 'having access without export or permission'. In the sea of shiny features advertised by apps, startups, and projects, it can be confusing to understand whether you actually have or own your stuff in the end.

'Encryption' helps avoid unauthorized access, but your data could easily disappear.

Many efforts that use the 'local-first' label focus on 'working offline', 'sync', and 'collaboration via CRDTs' without consideration for the seventh ideal of data ownership (perhaps leaving some company holding the data); in this way, plenty of Apple software could be misunderstood as 'local-first' while locking data into their ecosystem; DXOS is the closest I've seen to doing local-first right.

Ideally, data ownership is not a coincidental byproduct of someone's goodwill, but rather baked into how the system works. It should go beyond a technical concept to make people feel safe and able to trust the space as they might in a long-term relationship.

👋 Heads up: if you're more interested in solutions, read durable data.

---

This sort of 'complain-y' post fleshes out my encryption thread to highlight how data becoming inaccessible might feel to someone less tech-oriented than I am and who isn't going to document their experience; if you're a technology wrangler, read the rest of this while putting yourself in the shoes of someone whose relationship with owning data might be "new phone, please send your number".

encrypted bricks

In the end of 2023 I experienced the co-incidental deprecation of multiple messaging apps simultaneously. WhatsApp, Signal, and Beeper either suddenly stopped working or warned about 'going away soon'.

As a technologist, I can vaguely guess it's tied to something like 'availability of better encryption primitives or standards on newer versions of the operating system', but to a non-tech person it might be strange how WhatsApp says "you can use their web version instead, without upgrading your computer, but the native version that was working yesterday 'needs to' stop working today because of 'security'".

This could nicely tie into imagined stories of planned obsolescence and 'Apple pushing people to always get new stuff' even if that might not be what's really happening here; without technical knowledge, how would you tell the difference?

Also weird how many of these run in Electron (Chrome) as web apps with some kind of server component, but they don't work in a normal web browser.

volatile updates

It's fine that Beeper is no longer compatible with my older version of macOS, but not fine that the underlying self-update framework (Squirrel) forces an upgrade to a version that doesn't run on my machine: when is that ever desirable?

The threat of these workflow disruptions means one needs to keep backup copies of apps or lock them from being changed to prevent unintended updates.

locking Element on macOS to prevent it from incompatible upgrades

moving devices

Transferring both WhatsApp and Signal messages to a new phone, there's a scary thought (and real possibility) that all my messages could suddenly disappear because of 'security'. Since the app's transfer interface doesn't assure me of the correct path, I need to find the eight- to thirteen-step guide via a search engine and precisely follow it in order to understand and not mess up.

WhatsApp's transfer process simply didn't appear for me, but I was able to just re-register my number on the new phone (restored from iOS full backup) and unlock my data; phew, glad I didn't trust the documented process and relied on luck or a third party like Apple instead.

Signal's QR-code-based local network transfer is more straight-forward, but repeatedly failed at 99%, which although probably contains all my data, will not let me manage the last inch, thus leaving me locked out. After changing Wi-Fi networks, with a crash for success, it seemed to make it over safely.

Now, even though my messages are there at the moment, there's a lingering worry that my path was not acceptable for 'security' and so it might all get randomly taken away from me some day; this comes from seeing how message history is often not available on new linked devices. It doesn't matter whether my imagined story about possibly losing data is real. Does the experience make you feel safe? Does it reassure you that you have your data? Or does it threaten that you could become signed out and lose everything 'for your own protection'?

Delta Chat has the simplest device transfer and even an equivalent of 'changing your number'; the messages are also encrypted, yet I never worry about losing them.

clean by accident

If you can't afford larger storage capacity, you might find yourself managing space on your device. While cleanup up earlier in the year, I accidentally deleted Signal because my screen stalled — throw away your old, slower devices as they quickly become obsolete, right? — and my finger tapped and swiped perfectly because of muscle memory. My years of chat history were just gone. I have some messages on another linked device, but no possibility to export or transfer or merge because their desktop version is only 'linked' and not 'special', awaiting the next unfortunate accident; it sends the message that 'security' lacks agency.

decentralized if you know how

Is the solution is an open standard like Matrix? It's not so easy. Their "join" explainer is not as intuitive as other decentralized projects like Mastodon, PeerTube, or Lemmy. I don't believe a non-programmer would be able to do this without help, but assuming they sort through and understand the options of picking both a server and client, they will get stuck on errors like "Unable to decrypt message", "Verification failed", and the scary thought of losing messages if you log out.

Well, it was tricky to figure out how to trigger the Matrix verification process, but I managed to revive access to my Beeper messages with FluffyChat (which really might be "The cutest messenger in the Matrix network"), and it's nice to have access to my data in a variety of web apps that will probably remain backwards compatible forever. Still, "I managed to get it working" is a hard sell for normal people.

export impossible

I still have yet to see a built-in way to export all my messages at once with Signal, WhatsApp, or any popular Matrix client. It's possible to get a copy of some Signal Desktop messages with tools like sigtop and sqlcipher if you're comfortable typing into a terminal (I'm not). iMazing lets you export messages and attachments from WhatsApp. Not being part of official app interfaces just feels like platform capture to me: data in, but not out.

secure, complex, fragile

Why does all this 'security' have to feel so fragile? What does it mean when 'robustly-secured data' can accidentally vanish at a moment's notice, or that I can back up my entire phone for peace of mind, except for 'secure things'? Should it be normal to expect people to simply upgrade their operating system to the latest version when it's known to likely cause a slew of random issues?

How are ordinary people supposed to feel good about this? There may be workarounds, and maybe I'm even just taking the wrong approach in everything I've documented here, but if someone like me can't figure it out, it's bad: for people outside the tech world with little time or capacity to deal with these kinds of issues, the seeming possibility of them occurring is scary and unsafe, even if not real; for software developers to treat these circumstances as mere 'policy' is not very empathetic.

It's important to give space and patience to technology under development as people make it work, but there's no feigning moral superiority in using 'alternative tech' until it includes a real foundation to stand on for people without this domain expertise. Fleeting personal data is like alternative tech's equivalent of platform enshitification and doesn't fill me with confidence to trust these systems or recommend my non-tech friends to do so.

end rant

I hope to see more apps with comprehensive export or supporting personal data stores. And why not maximize compatibility where possible? If I can message all these platforms via Matrix bridges in a web browser, there's no reason to force an upgrade or brick my app.

Digital security should go beyond a technical concept: what if it made people feel safe, trusting the space as they might in a long-term relationship?

Are these stories of data becoming inaccessible just mine? If you have your own, be welcome to share. Maybe if the problems are documented, they're more likely to be fixed.

---

If you liked that, you might want to read durable data for some solutions, or interoperable visions in pointing at the wrong thing, or about different levels of agency.

---

👋 Heads up: if you're more interested in solutions, read durable data.

---

This sort of 'complain-y' post fleshes out my encryption thread to highlight how data becoming inaccessible might feel to someone less tech-oriented than I am and who isn't going to document their experience; if you're a technology wrangler, read the rest of this while putting yourself in the shoes of someone whose relationship with owning data might be "new phone, please send your number".

encrypted bricks

In the end of 2023 I experienced the co-incidental deprecation of multiple messaging apps simultaneously. WhatsApp, Signal, and Beeper either suddenly stopped working or warned about 'going away soon'.

As a technologist, I can vaguely guess it's tied to something like 'availability of better encryption primitives or standards on newer versions of the operating system', but to a non-tech person it might be strange how WhatsApp says "you can use their web version instead, without upgrading your computer, but the native version that was working yesterday 'needs to' stop working today because of 'security'".

This could nicely tie into imagined stories of planned obsolescence and 'Apple pushing people to always get new stuff' even if that might not be what's really happening here; without technical knowledge, how would you tell the difference?

Also weird how many of these run in Electron (Chrome) as web apps with some kind of server component, but they don't work in a normal web browser.

volatile updates

It's fine that Beeper is no longer compatible with my older version of macOS, but not fine that the underlying self-update framework (Squirrel) forces an upgrade to a version that doesn't run on my machine: when is that ever desirable?

The threat of these workflow disruptions means one needs to keep backup copies of apps or lock them from being changed to prevent unintended updates.

locking Element on macOS to prevent it from incompatible upgrades

moving devices

Transferring both WhatsApp and Signal messages to a new phone, there's a scary thought (and real possibility) that all my messages could suddenly disappear because of 'security'. Since the app's transfer interface doesn't assure me of the correct path, I need to find the eight- to thirteen-step guide via a search engine and precisely follow it in order to understand and not mess up.

WhatsApp's transfer process simply didn't appear for me, but I was able to just re-register my number on the new phone (restored from iOS full backup) and unlock my data; phew, glad I didn't trust the documented process and relied on luck or a third party like Apple instead.

Signal's QR-code-based local network transfer is more straight-forward, but repeatedly failed at 99%, which although probably contains all my data, will not let me manage the last inch, thus leaving me locked out. After changing Wi-Fi networks, with a crash for success, it seemed to make it over safely.

Now, even though my messages are there at the moment, there's a lingering worry that my path was not acceptable for 'security' and so it might all get randomly taken away from me some day; this comes from seeing how message history is often not available on new linked devices. It doesn't matter whether my imagined story about possibly losing data is real. Does the experience make you feel safe? Does it reassure you that you have your data? Or does it threaten that you could become signed out and lose everything 'for your own protection'?

Delta Chat has the simplest device transfer and even an equivalent of 'changing your number'; the messages are also encrypted, yet I never worry about losing them.

clean by accident

If you can't afford larger storage capacity, you might find yourself managing space on your device. While cleanup up earlier in the year, I accidentally deleted Signal because my screen stalled — throw away your old, slower devices as they quickly become obsolete, right? — and my finger tapped and swiped perfectly because of muscle memory. My years of chat history were just gone. I have some messages on another linked device, but no possibility to export or transfer or merge because their desktop version is only 'linked' and not 'special', awaiting the next unfortunate accident; it sends the message that 'security' lacks agency.

decentralized if you know how

Is the solution is an open standard like Matrix? It's not so easy. Their "join" explainer is not as intuitive as other decentralized projects like Mastodon, PeerTube, or Lemmy. I don't believe a non-programmer would be able to do this without help, but assuming they sort through and understand the options of picking both a server and client, they will get stuck on errors like "Unable to decrypt message", "Verification failed", and the scary thought of losing messages if you log out.

Well, it was tricky to figure out how to trigger the Matrix verification process, but I managed to revive access to my Beeper messages with FluffyChat (which really might be "The cutest messenger in the Matrix network"), and it's nice to have access to my data in a variety of web apps that will probably remain backwards compatible forever. Still, "I managed to get it working" is a hard sell for normal people.

export impossible

I still have yet to see a built-in way to export all my messages at once with Signal, WhatsApp, or any popular Matrix client. It's possible to get a copy of some Signal Desktop messages with tools like sigtop and sqlcipher if you're comfortable typing into a terminal (I'm not). iMazing lets you export messages and attachments from WhatsApp. Not being part of official app interfaces just feels like platform capture to me: data in, but not out.

secure, complex, fragile

Why does all this 'security' have to feel so fragile? What does it mean when 'robustly-secured data' can accidentally vanish at a moment's notice, or that I can back up my entire phone for peace of mind, except for 'secure things'? Should it be normal to expect people to simply upgrade their operating system to the latest version when it's known to likely cause a slew of random issues?

How are ordinary people supposed to feel good about this? There may be workarounds, and maybe I'm even just taking the wrong approach in everything I've documented here, but if someone like me can't figure it out, it's bad: for people outside the tech world with little time or capacity to deal with these kinds of issues, the seeming possibility of them occurring is scary and unsafe, even if not real; for software developers to treat these circumstances as mere 'policy' is not very empathetic.

It's important to give space and patience to technology under development as people make it work, but there's no feigning moral superiority in using 'alternative tech' until it includes a real foundation to stand on for people without this domain expertise. Fleeting personal data is like alternative tech's equivalent of platform enshitification and doesn't fill me with confidence to trust these systems or recommend my non-tech friends to do so.

end rant

I hope to see more apps with comprehensive export or supporting personal data stores. And why not maximize compatibility where possible? If I can message all these platforms via Matrix bridges in a web browser, there's no reason to force an upgrade or brick my app.

Digital security should go beyond a technical concept: what if it made people feel safe, trusting the space as they might in a long-term relationship?

Are these stories of data becoming inaccessible just mine? If you have your own, be welcome to share. Maybe if the problems are documented, they're more likely to be fixed.

---

If you liked that, you might want to read durable data for some solutions, or interoperable visions in pointing at the wrong thing, or about different levels of agency.

---

Writing interoperable visions got me thinking about how cool it would be to use a GitHub repository as the storage for Zero Data or local-first apps as many people have an account there, even some less technical people. Using their repository contents API it should be possible to connect it as a backend for web apps and store the data in a repository. Has this been done already?

GitHub has useful affordances for browsing files, understanding directory structure, editing text, collaborating, version control, and a whole wack of integrations hooking into every corner of the internet. A repo can be synced to your local device where you can also do all the things your device can, then push it back to the cloud.

Might be interesting to think of it like a Dropbox shared folder, but globally public and editable, or another way to get Datomic's "version control for your database".

Of course, you may not want the data created by your app to be public, so you might use a private repository instead of a public one. Choosing a public repository where it doesn't breach privacy could be a new way to encourage 'open data', as one can literally see, fork, and hack all of it with no extra steps,

The many affordances accessible point-and-click via GitHub's web interface ensures there are at least two apps that can edit the same data, which is great for interop, but factoring all the ways to edit GitHub repos via integrations and on your local device, it becomes closer to infinite: could it be one of the most interoperable formats out there? What would it say about sovereignty if similar flexibility via an API was replicated by Codeberg, or self-hostable options like GitLab, Gitea, or Gogs?

The remoteStorage.js library already supports Dropbox and Google Drive as an optional storage backend, with Solid on the way. Why not add GitHub? A polyglot library with five low-friction storage options would give developers more potential for their apps, and the people using them more ways into owning their data.

Writing interoperable visions got me thinking about how cool it would be to use a GitHub repository as the storage for Zero Data or local-first apps as many people have an account there, even some less technical people. Using their repository contents API it should be possible to connect it as a backend for web apps and store the data in a repository. Has this been done already?

GitHub has useful affordances for browsing files, understanding directory structure, editing text, collaborating, version control, and a whole wack of integrations hooking into every corner of the internet. A repo can be synced to your local device where you can also do all the things your device can, then push it back to the cloud.

Might be interesting to think of it like a Dropbox shared folder, but globally public and editable, or another way to get Datomic's "version control for your database".

Of course, you may not want the data created by your app to be public, so you might use a private repository instead of a public one. Choosing a public repository where it doesn't breach privacy could be a new way to encourage 'open data', as one can literally see, fork, and hack all of it with no extra steps,

The many affordances accessible point-and-click via GitHub's web interface ensures there are at least two apps that can edit the same data, which is great for interop, but factoring all the ways to edit GitHub repos via integrations and on your local device, it becomes closer to infinite: could it be one of the most interoperable formats out there? What would it say about sovereignty if similar flexibility via an API was replicated by Codeberg, or self-hostable options like GitLab, Gitea, or Gogs?

The remoteStorage.js library already supports Dropbox and Google Drive as an optional storage backend, with Solid on the way. Why not add GitHub? A polyglot library with five low-friction storage options would give developers more potential for their apps, and the people using them more ways into owning their data.

👋 Heads up: if you're looking for the shorter, less technical version, read pointing at the wrong thing.

---

I have been using my own Zero Data apps (storing all data on spaces you own) since 2018, starting with Hyperdraft for taking notes and gradually developing five more to optimize other meaningful workflows. It was enough back then to know that every iota of my data from these apps, including documents, configurations, and preferences, was in a place I control—a 'personal data store' (PDS).

It's been great, perhaps life-changing, and still continues to be a vital part of how I organize myself and my projects: my important stuff is with me at all times and eventually gets synced to all my devices; these web apps happen to be local-first and work fine without internet access; I've spent no time on spam, or proving to a machine that I'm human via captchas; and somehow I was even able to collaborate with other people on flashcards despite it not really being baked into my development frameworks—all without any felt presence of a large tech company deciding whether I can or not.

there, but invisible

One of the principles I listed on the Zero Data page is "do what you want with your data at any time", and I've been reflecting on some limitations of the current reality: it's technically true that I'm able to 'do what I want with it any time', but what can I actually do with this?

Most of my data in a PDS is stored in a format for machines ('JSON objects'), which I generally don't wrangle with my own hands—perhaps nobody should (to avoid throwing a computer into crisis by missing a comma). Sometimes I write code to maneuver this format into something meaningful, mostly for one-off situations that don't repeat and wouldn't be resolvable with any graphical interfaces ('GUI' software) that I'm aware of; I would prefer to avoid coding and can imagine it's not an option for most people (who still might not have the programming knowledge or mindset). More often, I use self-hosted n8n automations as a way to bridge different flows while using this data; it can be overall fantastic, yet still cumbersome and not quite low-code enough to include non-tech people. In the process, I learned about and self-hosted the no-code database Directus, which, although well-designed in many ways, feels quite heavy-handed and unfortunately not local-first. There are apps like Inspektor with useful affordances to edit key-value pairs as if they were 'fields', but it's not practical to do this regularly.

This data is somehow 100% mine, but as if I can't touch it or do much without technical expertise, as if I don't really have it even though it's right there; this is in some way strangely similar to having it stuck in one of those silos that I meant to avoid in the first place. The nicest way would be to simply use a variety of apps that can (inter-)operate on the same data without breaking each other. Observing how some of these Zero Data apps store the data (mine included), it seems there's a long way to go. Interoperability (interop) would make this better.

---

pure not practical

Related to silos, I've also been reflecting on how Zero Data shouldn't always mean asking people to leave the tools they know, or starting a new ecosystem from scratch. I've probably been as guilty of this as anyone else who claims to care about more ethical technology, and believed for a while in blank slates, but now I assume that things are and perhaps should be messy, because that's how it works in real life, with humans and their complex logistical or emotional entanglements. Only in the tech sphere would it be popular to 'start from scratch', with pristine self-declared confines unaffected by legacy; there's enough money and free time there to prop it up until there isn't, but for the rest of the world, subsidizing success isn't always sustainable: politically speaking, people generally gain leverage by forming imperfect coalitions rather than by staying 'pure' to any ideals or working exclusively with those who pledge the same; these pluralistic (messy) conditions for collaboration are exactly what an approach to apps and their data could exemplify.

In practice, that could mean:

• embracing popular formats, even if created by the devil
• not waiting for neat standards, instead letting systems grow from simple seeds
• not pushing people to a single blessed representation, instead perhaps supporting a dynamic vocabulary with something like Cambria
• having diverse options for import and export, then proliferating them through packages
• minimizing the 'destructive' tradeoffs of any decision.

Perhaps instead of forcing a choice to be made, there's potential to encourage a 'both and' mentality: alternative technology and the frameworks built in that world have an opportunity to become sort of 'data liberators' that help people avoid feeling stuck: personal data stores and apps built for them could, rather than feeling like silos, be considered bridges between or out of them by enabling credible exit where there is none. Interop would make this better.

---

function over formats

One way to restate and combine the above two perspectives is that the feeling of 'having your data in your hands' or 'handedness' (credit to Boris for the term)—being able to mold and maneuver it as you wish—comes not from a consecrated format but rather from access to diverse lenses, views, or 'applications' for the same data: maximizing what a human can do while minimizing the knowledge or skill required. I would say it's the variety in those possibilities that make the data tangible in this way, not the format itself, even though the format 'enables' it. Of course, interop would make this better.

---

apps as dumb, interoperable views

Various people (such as Ruben Verborgh and Geoffrey Litt) have articulated visions of apps almost like functions where your data goes in and a visual representation or interface comes out. I hope that by sketching out some more details around interop, something new can become discernible.

I've been thinking about this for my note-taking app and will use it as the main example, but there's probably lots that can be applied to other kinds of apps. As an aside, stealing these concepts for your project would not only be appreciated, but perhaps a way to 'do your part' if you're an interoperable app developer.

decouple type and location, enable pointing

Text editors are commonly used to 'edit text documents', often 'plain text' and sometimes 'rich text' with formatting. Unlike native apps where you can simply 'drag and drop' or 'share' files and the app will try to 'open' them, apps built for 'personal data stores' (Zero Data apps) currently link the format or 'type' to a specific location or 'path': for example, reading or writing note-like things in /notes versus /documents versus /$APP_NAME, which makes it hard to anticipate where your notes will be and breaks interop. There's also a tension here between 'app folder' versus 'type folder' (which I call 'chaos folder'), or 'document box' versus 'data graph'. One can debate whether there's such a thing as 'the correct' place, but let's assume it doesn't matter: if a Zero Data app wants to access a specific kind of data, ultimately it needs to be built 'knowing' about that relationship between location and type. Solid 'solves' this with type indexes, remoteStorage with data modules, but neither are guaranteed to be used when reading or writing data. Until there's a magical solution to that complex social problem of getting people (in this case, app developers) on the same page, it would be more flexible to perhaps have a default or preferred location but more importantly, like native apps, an option to 'point' the app at some data, whether local files, on cloud storage, or in PDS 'JSON objects'.

pointing at the 'wrong' thing

Would it make sense to point a notes app at your bookmarks? Or a maps app at your contact list? Or a flashcards app at your music collection? Some domains are more complementary than others, but regardless, the potential combinatorial possibilities of being open and flexible in this way are immense and would enable people to play with and combine data in interesting ways.

By pointing your notepad at a bookmarks app, for example, you might use fancier text-editing capabilities, rather than those of a simple text field, to add notes to saved links, perhaps more comfortably draft a personal message or blog post about that link, and have it automatically associated correctly with the corresponding document from a different app. Pointing at other things (like contacts, recipes, correspondence, etc.) might mean dealing with a 'plain editable text' representation of those 'items' or 'objects', and at the very least being able to read and search them. Consider also pointing a maps app at your contacts (maybe to see where your friends are?), or recipes (maybe to see where foods or ingredients come from or can be found?), or photos (maybe to see where you've made some memories?).

These are some of the possibilities when there's flexibility in the storage location and format; this sort of exists already with native apps and individual files, but pointing at 'collections of objects' in the way previously described often requires specific integrations (as Find my shows your friends or Photos presents places from geotagged images).

Again, I'd leave it to someone smarter than I to discover the best interface solution here: my imagination is currently limited to something like a 'file picker' without the burden of a deeply nested file system, where even on a mobile device you can say 'open this from there' with just a few taps; maybe the picker itself needs to be aware of various formats and how to convert random stuff into vocabularies that it knows the receiving app will understand—like the iOS Share sheet shows "what you can do with the shared content", but in reverse, to show "what content you can use with the current app"; anyone familiar with Quicksilver or Launchlet's 'pipe mode' might hear echos of 'subject' and 'action' ('with X, do Y').

two-way sync

Going a step further, let's imagine seeing contacts in this note-taking app (represented as plain editable text); modifying a name, address, or text blurb; and having the changes translate back from text into the original format (perhaps vCard). A bidirectional transformer or translator could be written once (perhaps even by one person), and any note-taking app could use that to flexibly view and edit all kinds of things. The closest usable solution I've seen for JSON objects (although not yet in common use) is remoteStorage data modules, encapsulating schema and logic together in a package that can enable any app to 'handle' specific data; similar efforts for Solid are currently in development. Lots of people use text editors (plain or rich) and would have an option to move data around fluidly while still benefiting from apps that use structured data under the hood. For a distant but novel approach, see how the Potluck research prototype cuts out the middleman and simply uses text in a notepad as the home for all kinds of data.

dynamic schemas from the start

It might take a lot of work to write and maintain many data converters, and although still useful under those circumstances, what if it could be easier or partially automated through a cheap pseudo-intelligent function? Perhaps a library could be preloaded with vocabularies from Schema.org or ShapeRepo and utilities that attempt a simple best guess when an input 'fits' a known structure? This could help with the issue of 'stale apps' (that either haven't been updated in a long time or may never be updated again) by enabling them to handle data dynamically from the start (as opposed to perpetually speaking only one fixed format), perhaps without requiring updates to learn about new schemas, and thus helping more of them remain compatible, interoperable, and useful without developer effort.

flexibility through pluralism

In addition to processing various forms of local data, I can imagine it being useful to have specific integrations with external services, transform their representations into one or multiple common data vocabularies, and package that integration to simplify inclusion in other apps. Imagine a text editor that can deal with input spanning the gamut of:

• .txt files in a personal data store, whether stored in /notes, /documents, or /$APP_NAME
• JSON text documents, whether stored as Schema.org/TextDigitalDocument or even Hyperdraft's occult format
• either of the above, whether stored on remoteStorage, Fission, Solid, Dropbox, Google Drive, iCloud, nextCloud, locally via the File System Access API, in a Git or GitHub repository, etc…
• documents from Apple Notes or Simplenote
• documents from Google Docs or Microsoft Word, editable as plain text, Markdown, or rich text
• blog posts from Ghost or Wordpress
• contacts, calendars, or correspondence as text by 'pointing at the wrong thing'
• perhaps not limited to one of the above sources or collections at a time, simultaneously handling multiple clouds or storage providers, multiple sources, or multiple formats

To more technical people, this might sound merely like 'integrating with 3rd party systems'. I would suggest that if those are the meaningful representations to someone using this kind of app, then it's what makes the data feel tangible and 'in the hands', clear that they actually have it without needing to trust any specific app, developer, or protocol.

What's the value of one app supporting a mix of these? Two apps? A whole ecosystem of apps? Not only reading but writing back via two-way sync? In the way we 'edit stuff as text' here, regardless of original format, what other affordances can be made for apps to 'edit stuff as X'? and how can it be enabled permisionlessly? This feels like an ideal for many protocol designers: a dynamic ecosystem where people are building and using software in unpredictable permutations, where progress happens faster than the speed of plugins, or perhaps even without codifying specific possibilities in advance. It's important to restate that these pluralistic potentials shouldn't be exclusive to Hyperdraft, as any note-taking app might benefit from at least some of this; ideally, it would be packaged in a way that minimizes complexity for the app developer while maximizing potential interop.

text editor as super-app

With all these concepts in mind, let's paint a picture of how software could be more interoperable.

Point your app at various formats and locations, and it will show you meaningful representations; where possible, it provides natural ways to shape those representations, transparently translating and syncing back if necessary. Use specialized features, shortcuts, and interfaces for text editing wherever some modifiable text is exposed: instead of 'editing text documents', simply 'edit text' wherever you see it. Try the same with non-text. Apps become smaller.

Connect multiple sources simultaneously, no need to have it all in one storage. Assume a messy ecosystem and embrace plurality. If the data's preferred transport is not available to web apps, make it available via something like sockethub. Bridges, converters, or dynamic vocabularies are written once and abundantly available—handy for whoever made them, but more likely for many other people; app developers can benefit without releasing new updates. At minimum, there are multiple useful options for import and export. Data is already everywhere, make use of it; rather than government surveillance and large tech companies monopolizing our data to cross-reference between multiple systems and silos, we own our data and the potentials that result.

It's a lot of work to consider, implement, and maintain storage, identity, CRDTs, encryption, and replication—on top of UX and the actual app: put it in the foundation, reduce pain for the interoperable app developer, minimize friction of having to choose—let them simply read and write data.

Every interoperable app becomes a super-app.

my future

I'm currently most excited to imagine: writing notes in Hyperdraft and 'seeing it' in Logseq; writing a Zero Data web app that syncs with my phone's contact list; a liberator app where you can read from (and maybe write to) your favourite centralized platforms; journaling 'daily notes' in Emoji Log and publishing as a digital garden via something like Quartz; a tool to edit arbitrary JSON objects; and my own apps supporting multiple clouds or sources simultaneously. It feels great to have space to progress on some of these ideas again: if you want to hear when I have this working in some way, sign up for the Zero Data mailing list here or follow me anywhere.

---

acknowledgements

Thanks (in reverse alphabetical order) to Sebastian Kippe, Michiel de Jong, Jess Martin, Heddi Ried, Gordon Brander, Elisa Guimarães, and Boris Mann for reading a draft of this and sharing feedback 🙏🏽.

---

P.S. Gordon shared some interesting notes which I'll quote here (with permission):

notes from Gordon

my own notes as I grapple with these same challenges:

• Credible exit. For exit to be credible, the data must be gettable, but also useful. What useful means depends upon the usecase/goal. So credible exit is a soft condition, or a gradient.
• Hostile interoperability. Historically, interoperability has often emerged through competition. Microsoft Word or Photoshop implement a proprietary format. The app becomes popular. It spawns competitors, and also adjacent apps. These apps implement all or a subset of the proprietary format. Finally, that format becomes a de facto standard, and sometimes an actual standard. [See Files allow interoperability to emerge retroactively].

Something I realized while writing these: Interoperability is not a feature. Interoperability is an ecological condition. It's what happens when different players with different incentives evolve networks of exchange. That means we can't force it to come about. We can only terraform the conditions where it might grow.

The desktop had the file system, a permissionless shared substrate belonging to the user. Apps could read each other's files and implement each other's file formats (each app effectively acts as a Cambria lens). These conditions were extremely conducive to the emergence of hostile interop.

This is what lead me personally toward building Noosphere protocol… it's essentially a very simple networked file system, supporting user ownership, multiplayer, and ability to permissionlessly plug multiple apps on top. There may be other paths to this outcome as well. In conversations with PVH he's mentioned that his motivation for investing in CRDT research is that if you have a file that knows how to sync itself, you don't have to care about the protocol.

---

P.P.S. I was thinking about this post before Jesse got me 'interop-pilled', but our conversation certainly helped add fuel to the fire:

👋 Heads up: if you're looking for the shorter, less technical version, read pointing at the wrong thing.

---

I have been using my own Zero Data apps (storing all data on spaces you own) since 2018, starting with Hyperdraft for taking notes and gradually developing five more to optimize other meaningful workflows. It was enough back then to know that every iota of my data from these apps, including documents, configurations, and preferences, was in a place I control—a 'personal data store' (PDS).

It's been great, perhaps life-changing, and still continues to be a vital part of how I organize myself and my projects: my important stuff is with me at all times and eventually gets synced to all my devices; these web apps happen to be local-first and work fine without internet access; I've spent no time on spam, or proving to a machine that I'm human via captchas; and somehow I was even able to collaborate with other people on flashcards despite it not really being baked into my development frameworks—all without any felt presence of a large tech company deciding whether I can or not.

there, but invisible

One of the principles I listed on the Zero Data page is "do what you want with your data at any time", and I've been reflecting on some limitations of the current reality: it's technically true that I'm able to 'do what I want with it any time', but what can I actually do with this?

Most of my data in a PDS is stored in a format for machines ('JSON objects'), which I generally don't wrangle with my own hands—perhaps nobody should (to avoid throwing a computer into crisis by missing a comma). Sometimes I write code to maneuver this format into something meaningful, mostly for one-off situations that don't repeat and wouldn't be resolvable with any graphical interfaces ('GUI' software) that I'm aware of; I would prefer to avoid coding and can imagine it's not an option for most people (who still might not have the programming knowledge or mindset). More often, I use self-hosted n8n automations as a way to bridge different flows while using this data; it can be overall fantastic, yet still cumbersome and not quite low-code enough to include non-tech people. In the process, I learned about and self-hosted the no-code database Directus, which, although well-designed in many ways, feels quite heavy-handed and unfortunately not local-first. There are apps like Inspektor with useful affordances to edit key-value pairs as if they were 'fields', but it's not practical to do this regularly.

This data is somehow 100% mine, but as if I can't touch it or do much without technical expertise, as if I don't really have it even though it's right there; this is in some way strangely similar to having it stuck in one of those silos that I meant to avoid in the first place. The nicest way would be to simply use a variety of apps that can (inter-)operate on the same data without breaking each other. Observing how some of these Zero Data apps store the data (mine included), it seems there's a long way to go. Interoperability (interop) would make this better.

---

pure not practical

Related to silos, I've also been reflecting on how Zero Data shouldn't always mean asking people to leave the tools they know, or starting a new ecosystem from scratch. I've probably been as guilty of this as anyone else who claims to care about more ethical technology, and believed for a while in blank slates, but now I assume that things are and perhaps should be messy, because that's how it works in real life, with humans and their complex logistical or emotional entanglements. Only in the tech sphere would it be popular to 'start from scratch', with pristine self-declared confines unaffected by legacy; there's enough money and free time there to prop it up until there isn't, but for the rest of the world, subsidizing success isn't always sustainable: politically speaking, people generally gain leverage by forming imperfect coalitions rather than by staying 'pure' to any ideals or working exclusively with those who pledge the same; these pluralistic (messy) conditions for collaboration are exactly what an approach to apps and their data could exemplify.

In practice, that could mean:

• embracing popular formats, even if created by the devil
• not waiting for neat standards, instead letting systems grow from simple seeds
• not pushing people to a single blessed representation, instead perhaps supporting a dynamic vocabulary with something like Cambria
• having diverse options for import and export, then proliferating them through packages
• minimizing the 'destructive' tradeoffs of any decision.

Perhaps instead of forcing a choice to be made, there's potential to encourage a 'both and' mentality: alternative technology and the frameworks built in that world have an opportunity to become sort of 'data liberators' that help people avoid feeling stuck: personal data stores and apps built for them could, rather than feeling like silos, be considered bridges between or out of them by enabling credible exit where there is none. Interop would make this better.

---

function over formats

One way to restate and combine the above two perspectives is that the feeling of 'having your data in your hands' or 'handedness' (credit to Boris for the term)—being able to mold and maneuver it as you wish—comes not from a consecrated format but rather from access to diverse lenses, views, or 'applications' for the same data: maximizing what a human can do while minimizing the knowledge or skill required. I would say it's the variety in those possibilities that make the data tangible in this way, not the format itself, even though the format 'enables' it. Of course, interop would make this better.

---

apps as dumb, interoperable views

Various people (such as Ruben Verborgh and Geoffrey Litt) have articulated visions of apps almost like functions where your data goes in and a visual representation or interface comes out. I hope that by sketching out some more details around interop, something new can become discernible.

I've been thinking about this for my note-taking app and will use it as the main example, but there's probably lots that can be applied to other kinds of apps. As an aside, stealing these concepts for your project would not only be appreciated, but perhaps a way to 'do your part' if you're an interoperable app developer.

decouple type and location, enable pointing

Text editors are commonly used to 'edit text documents', often 'plain text' and sometimes 'rich text' with formatting. Unlike native apps where you can simply 'drag and drop' or 'share' files and the app will try to 'open' them, apps built for 'personal data stores' (Zero Data apps) currently link the format or 'type' to a specific location or 'path': for example, reading or writing note-like things in /notes versus /documents versus /$APP_NAME, which makes it hard to anticipate where your notes will be and breaks interop. There's also a tension here between 'app folder' versus 'type folder' (which I call 'chaos folder'), or 'document box' versus 'data graph'. One can debate whether there's such a thing as 'the correct' place, but let's assume it doesn't matter: if a Zero Data app wants to access a specific kind of data, ultimately it needs to be built 'knowing' about that relationship between location and type. Solid 'solves' this with type indexes, remoteStorage with data modules, but neither are guaranteed to be used when reading or writing data. Until there's a magical solution to that complex social problem of getting people (in this case, app developers) on the same page, it would be more flexible to perhaps have a default or preferred location but more importantly, like native apps, an option to 'point' the app at some data, whether local files, on cloud storage, or in PDS 'JSON objects'.

pointing at the 'wrong' thing

Would it make sense to point a notes app at your bookmarks? Or a maps app at your contact list? Or a flashcards app at your music collection? Some domains are more complementary than others, but regardless, the potential combinatorial possibilities of being open and flexible in this way are immense and would enable people to play with and combine data in interesting ways.

By pointing your notepad at a bookmarks app, for example, you might use fancier text-editing capabilities, rather than those of a simple text field, to add notes to saved links, perhaps more comfortably draft a personal message or blog post about that link, and have it automatically associated correctly with the corresponding document from a different app. Pointing at other things (like contacts, recipes, correspondence, etc.) might mean dealing with a 'plain editable text' representation of those 'items' or 'objects', and at the very least being able to read and search them. Consider also pointing a maps app at your contacts (maybe to see where your friends are?), or recipes (maybe to see where foods or ingredients come from or can be found?), or photos (maybe to see where you've made some memories?).

These are some of the possibilities when there's flexibility in the storage location and format; this sort of exists already with native apps and individual files, but pointing at 'collections of objects' in the way previously described often requires specific integrations (as Find my shows your friends or Photos presents places from geotagged images).

Again, I'd leave it to someone smarter than I to discover the best interface solution here: my imagination is currently limited to something like a 'file picker' without the burden of a deeply nested file system, where even on a mobile device you can say 'open this from there' with just a few taps; maybe the picker itself needs to be aware of various formats and how to convert random stuff into vocabularies that it knows the receiving app will understand—like the iOS Share sheet shows "what you can do with the shared content", but in reverse, to show "what content you can use with the current app"; anyone familiar with Quicksilver or Launchlet's 'pipe mode' might hear echos of 'subject' and 'action' ('with X, do Y').

two-way sync

Going a step further, let's imagine seeing contacts in this note-taking app (represented as plain editable text); modifying a name, address, or text blurb; and having the changes translate back from text into the original format (perhaps vCard). A bidirectional transformer or translator could be written once (perhaps even by one person), and any note-taking app could use that to flexibly view and edit all kinds of things. The closest usable solution I've seen for JSON objects (although not yet in common use) is remoteStorage data modules, encapsulating schema and logic together in a package that can enable any app to 'handle' specific data; similar efforts for Solid are currently in development. Lots of people use text editors (plain or rich) and would have an option to move data around fluidly while still benefiting from apps that use structured data under the hood. For a distant but novel approach, see how the Potluck research prototype cuts out the middleman and simply uses text in a notepad as the home for all kinds of data.

dynamic schemas from the start

It might take a lot of work to write and maintain many data converters, and although still useful under those circumstances, what if it could be easier or partially automated through a cheap pseudo-intelligent function? Perhaps a library could be preloaded with vocabularies from Schema.org or ShapeRepo and utilities that attempt a simple best guess when an input 'fits' a known structure? This could help with the issue of 'stale apps' (that either haven't been updated in a long time or may never be updated again) by enabling them to handle data dynamically from the start (as opposed to perpetually speaking only one fixed format), perhaps without requiring updates to learn about new schemas, and thus helping more of them remain compatible, interoperable, and useful without developer effort.

flexibility through pluralism

In addition to processing various forms of local data, I can imagine it being useful to have specific integrations with external services, transform their representations into one or multiple common data vocabularies, and package that integration to simplify inclusion in other apps. Imagine a text editor that can deal with input spanning the gamut of:

• .txt files in a personal data store, whether stored in /notes, /documents, or /$APP_NAME
• JSON text documents, whether stored as Schema.org/TextDigitalDocument or even Hyperdraft's occult format
• either of the above, whether stored on remoteStorage, Fission, Solid, Dropbox, Google Drive, iCloud, nextCloud, locally via the File System Access API, in a Git or GitHub repository, etc…
• documents from Apple Notes or Simplenote
• documents from Google Docs or Microsoft Word, editable as plain text, Markdown, or rich text
• blog posts from Ghost or Wordpress
• contacts, calendars, or correspondence as text by 'pointing at the wrong thing'
• perhaps not limited to one of the above sources or collections at a time, simultaneously handling multiple clouds or storage providers, multiple sources, or multiple formats

To more technical people, this might sound merely like 'integrating with 3rd party systems'. I would suggest that if those are the meaningful representations to someone using this kind of app, then it's what makes the data feel tangible and 'in the hands', clear that they actually have it without needing to trust any specific app, developer, or protocol.

What's the value of one app supporting a mix of these? Two apps? A whole ecosystem of apps? Not only reading but writing back via two-way sync? In the way we 'edit stuff as text' here, regardless of original format, what other affordances can be made for apps to 'edit stuff as X'? and how can it be enabled permisionlessly? This feels like an ideal for many protocol designers: a dynamic ecosystem where people are building and using software in unpredictable permutations, where progress happens faster than the speed of plugins, or perhaps even without codifying specific possibilities in advance. It's important to restate that these pluralistic potentials shouldn't be exclusive to Hyperdraft, as any note-taking app might benefit from at least some of this; ideally, it would be packaged in a way that minimizes complexity for the app developer while maximizing potential interop.

text editor as super-app

With all these concepts in mind, let's paint a picture of how software could be more interoperable.

Point your app at various formats and locations, and it will show you meaningful representations; where possible, it provides natural ways to shape those representations, transparently translating and syncing back if necessary. Use specialized features, shortcuts, and interfaces for text editing wherever some modifiable text is exposed: instead of 'editing text documents', simply 'edit text' wherever you see it. Try the same with non-text. Apps become smaller.

Connect multiple sources simultaneously, no need to have it all in one storage. Assume a messy ecosystem and embrace plurality. If the data's preferred transport is not available to web apps, make it available via something like sockethub. Bridges, converters, or dynamic vocabularies are written once and abundantly available—handy for whoever made them, but more likely for many other people; app developers can benefit without releasing new updates. At minimum, there are multiple useful options for import and export. Data is already everywhere, make use of it; rather than government surveillance and large tech companies monopolizing our data to cross-reference between multiple systems and silos, we own our data and the potentials that result.

It's a lot of work to consider, implement, and maintain storage, identity, CRDTs, encryption, and replication—on top of UX and the actual app: put it in the foundation, reduce pain for the interoperable app developer, minimize friction of having to choose—let them simply read and write data.

Every interoperable app becomes a super-app.

my future

I'm currently most excited to imagine: writing notes in Hyperdraft and 'seeing it' in Logseq; writing a Zero Data web app that syncs with my phone's contact list; a liberator app where you can read from (and maybe write to) your favourite centralized platforms; journaling 'daily notes' in Emoji Log and publishing as a digital garden via something like Quartz; a tool to edit arbitrary JSON objects; and my own apps supporting multiple clouds or sources simultaneously. It feels great to have space to progress on some of these ideas again: if you want to hear when I have this working in some way, sign up for the Zero Data mailing list here or follow me anywhere.

---

acknowledgements

Thanks (in reverse alphabetical order) to Sebastian Kippe, Michiel de Jong, Jess Martin, Heddi Ried, Gordon Brander, Elisa Guimarães, and Boris Mann for reading a draft of this and sharing feedback 🙏🏽.

---

P.S. Gordon shared some interesting notes which I'll quote here (with permission):

notes from Gordon

my own notes as I grapple with these same challenges:

• Credible exit. For exit to be credible, the data must be gettable, but also useful. What useful means depends upon the usecase/goal. So credible exit is a soft condition, or a gradient.
• Hostile interoperability. Historically, interoperability has often emerged through competition. Microsoft Word or Photoshop implement a proprietary format. The app becomes popular. It spawns competitors, and also adjacent apps. These apps implement all or a subset of the proprietary format. Finally, that format becomes a de facto standard, and sometimes an actual standard. [See Files allow interoperability to emerge retroactively].

Something I realized while writing these: Interoperability is not a feature. Interoperability is an ecological condition. It's what happens when different players with different incentives evolve networks of exchange. That means we can't force it to come about. We can only terraform the conditions where it might grow.

The desktop had the file system, a permissionless shared substrate belonging to the user. Apps could read each other's files and implement each other's file formats (each app effectively acts as a Cambria lens). These conditions were extremely conducive to the emergence of hostile interop.

This is what lead me personally toward building Noosphere protocol… it's essentially a very simple networked file system, supporting user ownership, multiplayer, and ability to permissionlessly plug multiple apps on top. There may be other paths to this outcome as well. In conversations with PVH he's mentioned that his motivation for investing in CRDT research is that if you have a file that knows how to sync itself, you don't have to care about the protocol.

---

P.P.S. I was thinking about this post before Jesse got me 'interop-pilled', but our conversation certainly helped add fuel to the fire:

feedbox is an embed for previewing RSS feeds. Here's what it looks like:

Here it's configured to fetch the one from this blog, but you can use any RSS feed and drop in on your website with a few lines of code. I've added it to all my project home pages, including Zero Data App and my homepage.

It uses an instance of cors-anywhere to get around CORS complaints; I hope someday it will be simpler to just fetch the raw contents of a page.

Unlike most of my programming projects, I tried to write code that feels more 'messy' to me (simple human names instead of XYZVerboseNames, which is generally hell for other people). I also actually wrote a README (uncommon for most of the over 100 OldSkool modules) to describe the setup and possible options; hope to maintain this as a baseline for future modules.

Was kind of fun to let go, and not test everything, although I still wrote some tests…

As a more general complement, I automatically added link[rel="alternate] to sites that don't have one by setting an environment variable.

The sensation of stuff updating everywhere, even on static pages, without anybody doing anything, is kind of electric to me: isn't that what computers are for? bleep bloop!

feedbox is an embed for previewing RSS feeds. Here's what it looks like:

Here it's configured to fetch the one from this blog, but you can use any RSS feed and drop in on your website with a few lines of code. I've added it to all my project home pages, including Zero Data App and my homepage.

It uses an instance of cors-anywhere to get around CORS complaints; I hope someday it will be simpler to just fetch the raw contents of a page.

Unlike most of my programming projects, I tried to write code that feels more 'messy' to me (simple human names instead of XYZVerboseNames, which is generally hell for other people). I also actually wrote a README (uncommon for most of the over 100 OldSkool modules) to describe the setup and possible options; hope to maintain this as a baseline for future modules.

Was kind of fun to let go, and not test everything, although I still wrote some tests…

As a more general complement, I automatically added link[rel="alternate] to sites that don't have one by setting an environment variable.

The sensation of stuff updating everywhere, even on static pages, without anybody doing anything, is kind of electric to me: isn't that what computers are for? bleep bloop!

time	section
00:00	opening questions
01:13	zero data
02:05	DXOS
03:20	zero data origin
07:23	apps as public spaces
10:19	diffuse supporting multiple backends
11:04	rosano's apps
12:03	adoption challenges
15:01	interfaces for multi-device recovery
18:15	using a remoteStorage app to teach languages
22:05	prove functionality to groups
23:42	invisible technology
25:37	cross-app interoperability visions
27:02	syncing a shared data substrate
29:46	group chat as a catalyst for interop
31:16	integrating with existing storage
35:45	credible exit and exit by default
38:18	owning your data without handedness
42:44	interoperability needs adoption
45:51	valuable technology comes from other purposes
47:16	open-source can live on
49:58	re-thinking funding apps
51:10	making space for contributors
52:48	old house versus old app
53:49	personal spaces and malleable software
55:30	being handy with houses and software
57:11	shrinking programs

Links

• Jess Martin
• DXOS
• "The Humane Interface" by Jeff Raskin
• "Credible exit" by Gordon Brander
• Zero Data

time	section
00:00	opening questions
01:13	zero data
02:05	DXOS
03:20	zero data origin
07:23	apps as public spaces
10:19	diffuse supporting multiple backends
11:04	rosano's apps
12:03	adoption challenges
15:01	interfaces for multi-device recovery
18:15	using a remoteStorage app to teach languages
22:05	prove functionality to groups
23:42	invisible technology
25:37	cross-app interoperability visions
27:02	syncing a shared data substrate
29:46	group chat as a catalyst for interop
31:16	integrating with existing storage
35:45	credible exit and exit by default
38:18	owning your data without handedness
42:44	interoperability needs adoption
45:51	valuable technology comes from other purposes
47:16	open-source can live on
49:58	re-thinking funding apps
51:10	making space for contributors
52:48	old house versus old app
53:49	personal spaces and malleable software
55:30	being handy with houses and software
57:11	shrinking programs

Links

• Jess Martin
• DXOS
• "The Humane Interface" by Jeff Raskin
• "Credible exit" by Gordon Brander
• Zero Data

time	section
00:00	Introduction
01:26	Starting from scratch
03:33	Trying it out
04:08	Conclusion

Recipe

Name

Flashcards from translations

Callback

const source = document.querySelector('textarea[aria-label="Source text"]').value.split('\n');

const pronounce = source.map(e => '');

if (document.querySelector('div[data-location="2"] div')) {
document.querySelector('div[data-location="2"] div').textContent.split('\n').forEach((e, i) => pronounce[i] = e);
}

const translations = Array.from(document.querySelectorAll('div[aria-live="polite"] > div > div > span > span:nth-child(2n + 1) > span')).map(e => e.textContent);

const cardsText = translations.map((e, i) => [e, source[i], pronounce[i]].map(e => e.trim().replace(/^- ?/g, '')).join(';')).join(' ');

return this.api.LCHCopyToClipboard(cardsText);


URL Filter

https://translate.google.com

---

Part of Cooking with Launchlet.

time	section
00:00	Introduction
01:26	Starting from scratch
03:33	Trying it out
04:08	Conclusion

Recipe

Name

Flashcards from translations

Callback

const source = document.querySelector('textarea[aria-label="Source text"]').value.split('\n');

const pronounce = source.map(e => '');

if (document.querySelector('div[data-location="2"] div')) {
document.querySelector('div[data-location="2"] div').textContent.split('\n').forEach((e, i) => pronounce[i] = e);
}

const translations = Array.from(document.querySelectorAll('div[aria-live="polite"] > div > div > span > span:nth-child(2n + 1) > span')).map(e => e.textContent);

const cardsText = translations.map((e, i) => [e, source[i], pronounce[i]].map(e => e.trim().replace(/^- ?/g, '')).join(';')).join(' ');

return this.api.LCHCopyToClipboard(cardsText);


URL Filter

https://translate.google.com

---

Part of Cooking with Launchlet.