I made a small web app called memo to quickly jot down points, framing it as "a notepad you can't edit".

Similar to a piece of paper, you just note things down without editing or 'managing' much.

There are no buttons for each item: you can only add new things, and then copy or delete everything.

The interface supports routines I describe in work, then don't: capture points to deal with them later without distracting from whatever's happening at the moment.

Coming from other note taking apps like Simplenote, Apple Notes, or even Hyperdraft, it's nice to not manage conflict: "did I edit that already on another device?", "I synced but the changes aren't here yet", "I'd rather not think about that, let me make a new one and then copy/paste between later". Here, there's no need to trust in special sync — "just add and it will come together".

I find that 'not editing' also means 'not judging', thus allowing things to flow out as easily as possible—it can easily be cleaned up later; this is useful in brainstorming, writing long-form, and other modes.

So it's a little box to type in that's always ready when opening the app, and it syncronizes points to other devices, and none of the data is held hostage by me because you can bring your own storage. Great, but that's it?

Well, it's a 'real' app that I use everyday, but I think it's also a useful example of interoperability with other tools.

If you want to edit or delete individual items, you can connect the same data to this simple list app; the changes will sync back to memo.

If you like checking things off as 'done', use this todo app; they will show up completed (crossed out) in memo.

Some people want to keep everything forever, like a physical journal. Maybe someone could make another app that presents a nice 'archive'.

This is very primitive but it feels cool that separate apps work together pretty seamlessly. It's all possible because: 1) they each let you bring your own storage, and 2) they all share a similar format.

I think it would be nice if this was normal with apps and technology. The web is full of people making fun little tools but they're not connected to data in other places; I tend to imagine that by simply tweaking them to read and write data this way, we get some very cool new possibilities, and even give older projects new potential without much change.

Having different tools to deal with the same data is useful as an 'app user', but I love it as an 'app developer' because interop simplifies my life: I don't need to build all the features in my app — other apps can fill the gap, and together, we share one growing base of people who mix them in their workflows.

Try memo or the interop demo and let me know what comes to mind.

I made a small web app called memo to quickly jot down points, framing it as "a notepad you can't edit".

Similar to a piece of paper, you just note things down without editing or 'managing' much.

There are no buttons for each item: you can only add new things, and then copy or delete everything.

The interface supports routines I describe in work, then don't: capture points to deal with them later without distracting from whatever's happening at the moment.

Coming from other note taking apps like Simplenote, Apple Notes, or even Hyperdraft, it's nice to not manage conflict: "did I edit that already on another device?", "I synced but the changes aren't here yet", "I'd rather not think about that, let me make a new one and then copy/paste between later". Here, there's no need to trust in special sync — "just add and it will come together".

I find that 'not editing' also means 'not judging', thus allowing things to flow out as easily as possible—it can easily be cleaned up later; this is useful in brainstorming, writing long-form, and other modes.

So it's a little box to type in that's always ready when opening the app, and it syncronizes points to other devices, and none of the data is held hostage by me because you can bring your own storage. Great, but that's it?

Well, it's a 'real' app that I use everyday, but I think it's also a useful example of interoperability with other tools.

If you want to edit or delete individual items, you can connect the same data to this simple list app; the changes will sync back to memo.

If you like checking things off as 'done', use this todo app; they will show up completed (crossed out) in memo.

Some people want to keep everything forever, like a physical journal. Maybe someone could make another app that presents a nice 'archive'.

This is very primitive but it feels cool that separate apps work together pretty seamlessly. It's all possible because: 1) they each let you bring your own storage, and 2) they all share a similar format.

I think it would be nice if this was normal with apps and technology. The web is full of people making fun little tools but they're not connected to data in other places; I tend to imagine that by simply tweaking them to read and write data this way, we get some very cool new possibilities, and even give older projects new potential without much change.

Having different tools to deal with the same data is useful as an 'app user', but I love it as an 'app developer' because interop simplifies my life: I don't need to build all the features in my app — other apps can fill the gap, and together, we share one growing base of people who mix them in their workflows.

Try memo or the interop demo and let me know what comes to mind.

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 longer, more technical version, read interoperable visions.

---

Would it make sense to point Google Docs at your Twitter likes? Or Google Maps at your contact list? Or a flashcards app at your music collection? Some combinations are more complementary than others, but regardless, this flexibility would enable us to play with and combine data from various apps in meaningful ways without needing to wait for the developer or platform to build it first: we can just mash things up and see what happens.

For example, by pointing a note-taking app at your bookmarks, you might use fancier text-editing features (rather than a simple text field) to add notes to your saved links, perhaps more comfortably draft a personal message or blog post about that link. Pointing at other things (like contacts, recipes, correspondence, etc.) might mean editing them as if they were only 'plain editable text', and maybe having a new way 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?).

This flexibility sort of exists already with apps that open 'files', but pointing at 'collections of items' in the way previously described often requires specific integrations (as Find my shows your friends or Photos presents places from geotagged images). Would be nice to see this in every app, so that we always have multiple options to handle our digital stuff, as opposed to data being locked into specific apps and platforms.

I could imagine it useful to have a kind of 'data picker' without dealing too much with 'files', where even on a mobile device you can say 'open this from there' with just a few taps; maybe 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".

Imagine a text editor that can deal with the gamut of:

• text files, whether on your computer, Dropbox, Google Drive, iCloud, GitHub, etc…
• documents from Apple Notes or Simplenote
• documents from Google Docs or Microsoft Word, editable as simple text
• blog posts from Ghost or Wordpress
• contacts, calendars, or correspondence as text by 'pointing at the wrong thing'

What's the value of one app supporting a mix of these? Two apps? A whole ecosystem of apps? In the way we 'edit stuff as text' here regardless of where it is, what how else can apps 'edit stuff as X'?

This could be 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 the developer or platform specifying it. I'd certainly love to see this brighter future with more possibilities for our human agency. What about you? I would love to hear what you think about this especially if you consider yourself a 'less technical' person: be welcome to comment or message me anywhere.

👋 Heads up: if you're looking for the longer, more technical version, read interoperable visions.

---

Would it make sense to point Google Docs at your Twitter likes? Or Google Maps at your contact list? Or a flashcards app at your music collection? Some combinations are more complementary than others, but regardless, this flexibility would enable us to play with and combine data from various apps in meaningful ways without needing to wait for the developer or platform to build it first: we can just mash things up and see what happens.

For example, by pointing a note-taking app at your bookmarks, you might use fancier text-editing features (rather than a simple text field) to add notes to your saved links, perhaps more comfortably draft a personal message or blog post about that link. Pointing at other things (like contacts, recipes, correspondence, etc.) might mean editing them as if they were only 'plain editable text', and maybe having a new way 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?).

This flexibility sort of exists already with apps that open 'files', but pointing at 'collections of items' in the way previously described often requires specific integrations (as Find my shows your friends or Photos presents places from geotagged images). Would be nice to see this in every app, so that we always have multiple options to handle our digital stuff, as opposed to data being locked into specific apps and platforms.

I could imagine it useful to have a kind of 'data picker' without dealing too much with 'files', where even on a mobile device you can say 'open this from there' with just a few taps; maybe 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".

Imagine a text editor that can deal with the gamut of:

• text files, whether on your computer, Dropbox, Google Drive, iCloud, GitHub, etc…
• documents from Apple Notes or Simplenote
• documents from Google Docs or Microsoft Word, editable as simple text
• blog posts from Ghost or Wordpress
• contacts, calendars, or correspondence as text by 'pointing at the wrong thing'

What's the value of one app supporting a mix of these? Two apps? A whole ecosystem of apps? In the way we 'edit stuff as text' here regardless of where it is, what how else can apps 'edit stuff as X'?

This could be 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 the developer or platform specifying it. I'd certainly love to see this brighter future with more possibilities for our human agency. What about you? I would love to hear what you think about this especially if you consider yourself a 'less technical' person: be welcome to comment or message me anywhere.

👋 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:

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

I've been thinking about these three framings of what is possible with a specific technology:

1. Look what I can do
2. Look what you can do
3. Look what we can do

An example of the first would be when someone (maybe an artist/hacker/nerd) creates a bespoke experience that showcases a way of doing things: maybe a cool visualization of events in their life, a fun automation that connects disparate services and tells you things like the current height of a beloved plant, or an utterly custom web page design to be used only once perhaps as a portfolio site. It can be a way to demonstrate control over one's materials, and a marvel to observe and interact with, but you can't make your own—this isn't meant to cast the creation as selfish, but rather to draw where the line is in terms of your ability to build something with it—perhaps even the goal is to be unique and therefore not replicatable by others.

Most apps fall into the second category by encapsulating the 'principles of an experience' (to roughly paraphrase Steve Jobs): they enable people to create their own version of the thing, be it a text document, map of meaningful locations, photo albums, or pretty much anything imaginable. We now say "there's an app for that" and it's the default way for most people to express themselves through digital mediums. 'Look what you can do' empowers people to explore, create, and then share with others, more so than the first category, so there's an order of magnitude difference in the possibility space, but it's also more complex to build as one needs to consider the assumptions of multiple kinds of stakeholders or 'users'.

In the third category, adding social layers can encourage network effects and moves the technology beyond a tool or utility into collective creation; this can occur through follower graphs, timelines, multiplayer, ratings, etc… Producing a digital artifact has platform native ways for people to interact and react, either passively through comments and 'likes' or more actively through 'remixing' (such as reaction videos on YouTube or lip-syncing on TikTok). It's even more difficult to build than the second category because of the additional complexity of network interactions and identity management, but the result is that the technology starts to take on a life of its own as the experience becomes dominated by how other people use it.

Somewhere between these categories, one can find extensions and customization (achieved through some apps as 'scripting'). When someone extends an app for themselves, it might be an example of the first category, whereas passing that around brings it closer to the second, and sharable platform native 'plugins' or 'add-ons' or 'bots' can bring it closer to the third.

Usability and accessibility can impact where a technology falls on the spectrum: not paying attention to these dimensions makes it harder to move to higher levels of agency, staying more exclusive as "Look at what I/you/we can do, as the capable ones"; as in the first level, it's not necessarily selfish but if the intention is to maximize agency, then this creates a mismatch. Self-hosting generally suffers from this, but there are Easy Indie platforms that enable one-click installation, thereby broadening the potential base of people able to participate. Tools like WAVE can help spot simple improvements to accessibility in web-based projects. Although mainstream software expectations can be an antipattern, a cultural appreciation for the simple and functional can help raise usability standards, turning design into a language understood by more people.

I see adding interoperability between systems and enabling data to be re-combined in abstract ways as kind of another level, maybe "Look what a not-yet-existing entity can do": enabling future possibilities by opening data to be composed by the unknown is, in my opinion, just as transformative as moving from 'I' to 'you' or 'you' to 'we'. The emerging Zero Data ecosystem (keeping data and apps encapsulated from one another) feels promising as a usable example of what this could be like. Automation systems like Zapier or n8n are also useful as a way to ensure data is composable, or at least exposed as an API. It shows to me that #OwnYourData is not just about privacy or autonomy, but also about the cool cybernetic possibilities of a future we haven't imagined yet.

I've been thinking about these three framings of what is possible with a specific technology:

1. Look what I can do
2. Look what you can do
3. Look what we can do

An example of the first would be when someone (maybe an artist/hacker/nerd) creates a bespoke experience that showcases a way of doing things: maybe a cool visualization of events in their life, a fun automation that connects disparate services and tells you things like the current height of a beloved plant, or an utterly custom web page design to be used only once perhaps as a portfolio site. It can be a way to demonstrate control over one's materials, and a marvel to observe and interact with, but you can't make your own—this isn't meant to cast the creation as selfish, but rather to draw where the line is in terms of your ability to build something with it—perhaps even the goal is to be unique and therefore not replicatable by others.

Most apps fall into the second category by encapsulating the 'principles of an experience' (to roughly paraphrase Steve Jobs): they enable people to create their own version of the thing, be it a text document, map of meaningful locations, photo albums, or pretty much anything imaginable. We now say "there's an app for that" and it's the default way for most people to express themselves through digital mediums. 'Look what you can do' empowers people to explore, create, and then share with others, more so than the first category, so there's an order of magnitude difference in the possibility space, but it's also more complex to build as one needs to consider the assumptions of multiple kinds of stakeholders or 'users'.

In the third category, adding social layers can encourage network effects and moves the technology beyond a tool or utility into collective creation; this can occur through follower graphs, timelines, multiplayer, ratings, etc… Producing a digital artifact has platform native ways for people to interact and react, either passively through comments and 'likes' or more actively through 'remixing' (such as reaction videos on YouTube or lip-syncing on TikTok). It's even more difficult to build than the second category because of the additional complexity of network interactions and identity management, but the result is that the technology starts to take on a life of its own as the experience becomes dominated by how other people use it.

Somewhere between these categories, one can find extensions and customization (achieved through some apps as 'scripting'). When someone extends an app for themselves, it might be an example of the first category, whereas passing that around brings it closer to the second, and sharable platform native 'plugins' or 'add-ons' or 'bots' can bring it closer to the third.

Usability and accessibility can impact where a technology falls on the spectrum: not paying attention to these dimensions makes it harder to move to higher levels of agency, staying more exclusive as "Look at what I/you/we can do, as the capable ones"; as in the first level, it's not necessarily selfish but if the intention is to maximize agency, then this creates a mismatch. Self-hosting generally suffers from this, but there are Easy Indie platforms that enable one-click installation, thereby broadening the potential base of people able to participate. Tools like WAVE can help spot simple improvements to accessibility in web-based projects. Although mainstream software expectations can be an antipattern, a cultural appreciation for the simple and functional can help raise usability standards, turning design into a language understood by more people.

I see adding interoperability between systems and enabling data to be re-combined in abstract ways as kind of another level, maybe "Look what a not-yet-existing entity can do": enabling future possibilities by opening data to be composed by the unknown is, in my opinion, just as transformative as moving from 'I' to 'you' or 'you' to 'we'. The emerging Zero Data ecosystem (keeping data and apps encapsulated from one another) feels promising as a usable example of what this could be like. Automation systems like Zapier or n8n are also useful as a way to ensure data is composable, or at least exposed as an API. It shows to me that #OwnYourData is not just about privacy or autonomy, but also about the cool cybernetic possibilities of a future we haven't imagined yet.

We're going to present 'the simplest possible integrations' for the various protocols. Noel De Martin has already started a Hello World for SOLID. Rosano will try one or both of remoteStorage and Fission (although a volunteer for either would be very much appreciated). Be welcome to join us and ask questions: let's learn together.

See also the previous swap.

We're going to present 'the simplest possible integrations' for the various protocols. Noel De Martin has already started a Hello World for SOLID. Rosano will try one or both of remoteStorage and Fission (although a volunteer for either would be very much appreciated). Be welcome to join us and ask questions: let's learn together.

See also the previous swap.

Rosano and cblgh and invite you to a show-and-tell. Come and share what projects you’re working on: experiments, works-in-progress & under construction, mundane or extraordinary—anything goes, as long as it’s yours~

See also the previous swap.

---

Summary

Over a dozen people attended or presented a wide range of software and hardware projects. We took collaborative notes with HackMD, tracked seven-minute timers with DuckDuckGo, and determined the order of presentations via Python's Random.shuffle().

hoody: 'moderator'

Running collaborative tools on low-power devices, indestructible distributed 4chan dark-net market place, quick to disappear, using tech from Aljoscha Meyer.

cinnamon: Earthstar

• inspired by trying to fix scuttlebut ui/ux issues that run deep
  • device-oriented over people-oriented, can't use same identity on different devices
  • processing the entire backlog is network/storage/cpu intense, slow
  • immutability is not good for a social network. what's safe to say today might not be safe tomorrow, need to be able to delete stuff
  • need to be able to download a subset of data related to stuff you care about
• earthstar fixes all of the above
  • people-oriented identity, can log in from multiple devices
  • can download a subset of data as needed
  • everything is mutable and can be deleted by author
  • also can have mutable docs that anyone can edit
  • designed for small groups, ~100 people, separated into "workspaces". not a big single global network.
  • trying to use simple boring technology as much as possible
  • very detailed specification: https://earthstar-docs.netlify.app/docs/reference/earthstar-specification
• simple CRDT last writer wins merge strategy. Better CRDTs exist but are complicated, we decided to use the simplest one
• every peer has a copy of the data they care about. pubs exist to get around firewalls; they are just peers in the cloud.
• goal: pubs are easy to run by community members, keep governance as local as possible, avoid moderations external to local community
• pubs are easy to run, push buttons on glitch, no need to use a command line, pub owner has no power, can only turn it off, can have multiple pubs run by different people for redundancy
• zero data event with rosano at some later point?
• cinnamon stepping down for health reasons, looking for contributors

mix: ssb-crut

Pre-recorded presentation.

juha

Wants to track carbon via Zero Data apps and integrate with Home Assistant.

mauve: hypergodot

P2P for godot game engine.

• avoid managing server-stuff for games by using hypercore https://hypercore-protocol.org
• works like bittorrent: downloads your platform binary, gateway gets spawned, game sends http requests to gateway for doing p2p; user just plays game, dev just imports node to scene graph
• https://github.com/RangerMauve/hyper-gateway
• https://github.com/RangerMauve/hypercore-fetch
• https://github.com/hyperswarm/hyperswarm

rosano: automated testing via github actions

gwil: letterbox

• runs anywhere javascript runs (browser, node, deno)
• would be great to have libraries in other languages, shouldn't be hard to port to another language
  • refer to the detailed spec: https://earthstar-docs.netlify.app/docs/reference/earthstar-specification/
• and join our discord: https://discord.gg/RGsvu9a9

cblgh: lieu

a community search engine

• code: https://github.com/cblgh/lieu
• thread of recent feature update: https://twitter.com/cblgh/status/1455197377065799689

nanomonkey: recipe manager

UI works with both keyboard and mouse

• frontend https://github.com/nanomonkey/scratch
• backend https://github.com/nanomonkey/ssb%5Fclj%5Frepl

Chat

13:36 cblgh says: order ['hoody', 'juha', 'mauve', 'fellow jitsi', 'cinn', 'mix', 'rosano', 'cblgh', 'gwil']
13:39 Mauve says: https://agregore.mauve.moe/
13:40 cblgh says: https://merveilles.town/web/accounts/57295 <-- amatecha
13:42 cinnamon says: https://github.com/earthstar-project/earthstar
13:42 cinnamon says: p.s. I use they/them pronouns
13:44 cblgh says: (updated order: ['hoody', 'juha', 'mauve', 'fellow jitsi', 'cinn', 'mix', 'rosano', 'cblgh', 'gwil', 'geoffrey', 'interfect'])
13:44 cblgh says: o ya he/him/they i guess 😃
13:44 rosano says: he/they
13:46 Juha Autero says: he/they also
13:48 rosano says: https://duckduckgo.com/?q=timer+7+min&ia=answer
13:49 cblgh says: https://github.com/AljoschaMeyer/bamboo
13:49 cblgh says: https://collapseos.org/
13:55 cblgh says: o/ nanomonkey 😃
13:56 gwil says: fully sick
14:07 cblgh says: https://github.com/AljoschaMeyer
14:07 cblgh says: https://github.com/fraction/oasis
14:07 cblgh says: https://github.com/earthstar-project/earthstar
14:09 nanomonkey says: So, I built the first two boards for the disaster radio project. I have some experience with building Lora antannas in Kicad if you need any help.
14:10 interfect says: Thanks!
14:12 cblgh says: https://cblgh.org/trustnet/
14:12 cblgh says: (pardon the orange halloween theme x)
14:16 hoody says: earthstar is dope
14:17 cblgh says: https://buntimer-earthstar.netlify.com
14:21 cinnamon says: https://earthstar-demo-pub-v6-a.glitch.me/
14:21 cinnamon says: https://github.com/earthstar-project/earthstar-pub
14:21 cblgh says: https://gitlab.com/ahau/lib/ssb-crut
14:21 cblgh says: https://ahau.io/
14:22 nanomonkey says: Any suggestions on how to get mics working? I've tried all the options available through jitsi that I can find.
14:23 cblgh says: hm not sure 😕 replug it probably, or try chrome and see if that does it?
14:23 gwil says: which browser are you on? safari always gives me trouble
14:23 rosano says: @nanomonkey i think you probably did it right, maybe try a different browser?
14:23 nanomonkey says: firefox
14:23 rosano says: yea safari doesn't work for me
14:23 nanomonkey says: on llnux
14:24 Mauve says: I'm on Firefox on Linux and I think my mic works FWIW.
14:24 Mauve says: I'm guessing your mic gain is up and your system is seeing stuff when you try to test it outside the browser?
14:25 cblgh says: once i had to click on the lil tab above the mic and pic another microphone, cause it was picking up a different one
14:25 cblgh says: (guess you already tried that tho!)
14:25 cblgh says: hey cryptix 😃
14:25 cblgh says: we're streaming mix (not sure if you can see it)
14:26 cryptix says: hey ya'll!
14:26 cryptix says: yea i can. sorry for being late.. i somehow messed up writing down the wrong time
14:26 cblgh says: nw 😃
14:26 rosano says: timezones are complicated… but thanks for being here, be welcome 😃
14:27 Juha Autero says: nanomankey: Does addressbar show that you have granted extra permissions on website?
14:27 cblgh says: boost ON
14:27 amatecha says: oh wow I figured out how to set name and use chat. woot
14:28 cblgh says: (mix gave me permission to 1.25x it once it got close to the 7 min work fwiw 😃
14:28 rosano says: dj alex
14:31 cblgh says: 💿😎
14:31 cblgh says: https://github.com/mixmix/ssb-crut-demo
14:31 cblgh says: if anyone wants to rewatch it it's here: https://www.youtube.com/watch?v=URIUbupxxU4
14:31 cblgh says: ['hoody', 'juha', 'mauve', 'fellow jitsi', 'cinn', 'mix', 'rosano', 'cblgh', 'gwil', 'geoffrey', 'interfect', 'nanomonkey', 'cryptix']
14:35 hoody says: getting super flaky net here at y homeboys house
14:35 hoody says: heading back to home and trying again
14:36 Mauve says: lol, I can't share screen from Agregore yet since I haven't implemented the UI for it. 😂
14:36 rosano says: #browsergoals
14:41 cblgh says: i guess this
14:41 https://www.home-assistant.io/ :^)
14:41 rosano says: https://www.home-assistant.io
14:42 Mauve says: Just confirming with the person I'm meeting though
14:44 cblgh says: https://godotengine.org/
14:44 cblgh says: https://github.com/RangerMauve/hypergodot
14:45 nanomonkey says: Juha, there is a couple of libraries in Python for opening and writing to excel files. This might help you out.
14:45 nanomonkey says: Pandas can do it directly and has lots of support.
14:46 cblgh says: (also known as dat previously : )
14:46 cblgh says: https://hypercore-protocol.org/
14:46 amatecha says: oohhh (didn’t know dat was “rebranded”!)
14:47 Juha Autero says: I'm experienced Python programmer. What I'm trying to learn is javascript frameworks.
14:47 rosano says: "as little as possible to make stuff just work" all the things
14:50 cblgh says: big brain energy
14:51 Mauve says: https://github.com/RangerMauve/hyper-gateway
14:51 Mauve says: https://github.com/RangerMauve/hypercore-fetch
15:00 cblgh says: https://github.com/hyperswarm/hyperswarm
15:00 cblgh says: https://hyperdraft.rosano.ca
15:00 cblgh says: https://github.com/sveltejs/svelte
15:02 cblgh says: https://www.cypress.io/
15:04 Mauve says: K, gotta go. TY folks!
15:06 cblgh says: gwil u can go ahead of me if you want 😃
15:06 gwil says: I'll take you up on that
15:09 gwil says: https://earthstar-letterbox.netlify.app/join/earthstar:///?workspace=+plaza.prm27p8eg65c&pub=https://earthstar-demo-pub-6b.fly.dev&pub=https://earthstar-demo-pub-v6-a.glitch.me&v=1
15:13 cblgh says: (i love the pocket terminology that gwil is putting into action here)
15:13 cblgh says: if u remember (from cinn): to participate u gotta make an identity, and then you click on "join plaza" or whatever at the bottom!
15:14 rosano says: local-first!
15:16 cblgh says: 👏👏👏
15:16 rosano says: ❤️
15:18 hoody says: back on track. hallo cryptix
15:19 cblgh says: wb!
15:20 gwil says: https://discord.gg/RGsvu9a9 <-- earthstar discord
15:20 cblgh says: remaining potential presentations [ 'cblgh', 'nanomonkey', 'cryptix']
15:20 gwil says: cinnamon's docS are NUTS
15:22 rosano says: https://lieu.cblgh.org
15:23 Juha Autero says: Accidentally closed tab.
15:26 rosano says: ooooh lala
15:26 hoody says: any preferred thing to do to make your site lieu friendly?
15:27 gwil says: yeah, is there a way for it to handle browser-rendered apps / pipe data in?
15:28 cblgh says: p:first-of-type
15:28 gwil says: A whole new industry of dark web SEO
15:29 hoody says: heh heh
15:29 hoody says: how about a button you could display
15:29 hoody says: oldskool, part of webring / use lieu here
15:30 cblgh says: oh ya, like ready made?
15:32 hoody says: yup, to help people find this thing
15:32 hoody says: neocities friendly stuff, simple
15:32 hoody says: https://vmx.cx/cgi-bin/blog/index.cgi/category/Noise
15:32 hoody says: might be handy soehow
15:32 hoody says: somehow
15:32 gwil says: thanks everyone, I've got to run!
15:33 hoody says: cheers gwil
15:33 cblgh says: am i the only one that can't see it?
15:33 cryptix says: nope
15:33 amatecha says: i see nothing lol
15:33 Juha Autero says: me neither
15:34 cblgh says: now we're good
15:34 Juha Autero says: now i can see
15:45 cblgh says: varasanos og
15:45 cblgh says: https://www.varasanos.com/PizzaRecipe.htm
15:45 cblgh says: this guy is so serious, check out his site to learn everything about making pizza
15:45 cblgh says: related: just found out about this markup language for recipes today https://cooklang.org/
15:45 cblgh says: high yield recipe
15:45 cblgh says: https://clojurescript.org/
15:45 cblgh says: https://valueflo.ws/
15:45 cblgh says: https://bob.mikorizal.org/users/bhaugen
15:45 cblgh says: (bob's fedi)
15:45 cblgh says: https://github.com/ssb-ngi-pointer/ssb-db2
15:47 hoody says: it's snowing here, got some cocoa and cryptix explaining stuff on the headphones, this is cool
15:49 cblgh says: ohh wow
15:49 cblgh says: just arctic circle things
15:49 cblgh says: https://github.com/nanomonkey/scratch
15:49 cblgh says: https://github.com/nanomonkey/ssb%5Fclj%5Frepl
15:52 hoody says: ssbCRUD
15:52 hoody says: i think many people are interested in running ssb as distributed key-val store
15:52 cryptix says: +1
15:54 nanomonkey says: What ssb client are folks using these days?
15:54 cblgh says: still patchwork x)
15:54 hoody says: is there a zero data manifesto somewhere?
15:54 hoody says: patchwork
15:55 rosano says: @hoody some principles at https://0data.app
15:55 hoody says: cheers rosano
15:57 amatecha says: \o/
15:59 cryptix says: also nano, feel free to mention me with these questions
15:59 nanomonkey says: will do
15:59 cryptix says: also sure cel would be down to answer - also req criquets: like gwil said, somethomes these threads just vanish
15:59 rosano says: https://chat.rosano.ca/t/zero-data-swap-3-maker-meet-october-27-2021/44
15:59 rosano says: https://0data.app
16:00 hoody says: super cool, thanks for doing this
16:00 hoody says: cu!

Rosano and cblgh and invite you to a show-and-tell. Come and share what projects you’re working on: experiments, works-in-progress & under construction, mundane or extraordinary—anything goes, as long as it’s yours~

See also the previous swap.

---

Summary

Over a dozen people attended or presented a wide range of software and hardware projects. We took collaborative notes with HackMD, tracked seven-minute timers with DuckDuckGo, and determined the order of presentations via Python's Random.shuffle().

hoody: 'moderator'

Running collaborative tools on low-power devices, indestructible distributed 4chan dark-net market place, quick to disappear, using tech from Aljoscha Meyer.

cinnamon: Earthstar

• inspired by trying to fix scuttlebut ui/ux issues that run deep
  • device-oriented over people-oriented, can't use same identity on different devices
  • processing the entire backlog is network/storage/cpu intense, slow
  • immutability is not good for a social network. what's safe to say today might not be safe tomorrow, need to be able to delete stuff
  • need to be able to download a subset of data related to stuff you care about
• earthstar fixes all of the above
  • people-oriented identity, can log in from multiple devices
  • can download a subset of data as needed
  • everything is mutable and can be deleted by author
  • also can have mutable docs that anyone can edit
  • designed for small groups, ~100 people, separated into "workspaces". not a big single global network.
  • trying to use simple boring technology as much as possible
  • very detailed specification: https://earthstar-docs.netlify.app/docs/reference/earthstar-specification
• simple CRDT last writer wins merge strategy. Better CRDTs exist but are complicated, we decided to use the simplest one
• every peer has a copy of the data they care about. pubs exist to get around firewalls; they are just peers in the cloud.
• goal: pubs are easy to run by community members, keep governance as local as possible, avoid moderations external to local community
• pubs are easy to run, push buttons on glitch, no need to use a command line, pub owner has no power, can only turn it off, can have multiple pubs run by different people for redundancy
• zero data event with rosano at some later point?
• cinnamon stepping down for health reasons, looking for contributors

mix: ssb-crut

Pre-recorded presentation.

juha

Wants to track carbon via Zero Data apps and integrate with Home Assistant.

mauve: hypergodot

P2P for godot game engine.

• avoid managing server-stuff for games by using hypercore https://hypercore-protocol.org
• works like bittorrent: downloads your platform binary, gateway gets spawned, game sends http requests to gateway for doing p2p; user just plays game, dev just imports node to scene graph
• https://github.com/RangerMauve/hyper-gateway
• https://github.com/RangerMauve/hypercore-fetch
• https://github.com/hyperswarm/hyperswarm

rosano: automated testing via github actions

gwil: letterbox

• runs anywhere javascript runs (browser, node, deno)
• would be great to have libraries in other languages, shouldn't be hard to port to another language
  • refer to the detailed spec: https://earthstar-docs.netlify.app/docs/reference/earthstar-specification/
• and join our discord: https://discord.gg/RGsvu9a9

cblgh: lieu

a community search engine

• code: https://github.com/cblgh/lieu
• thread of recent feature update: https://twitter.com/cblgh/status/1455197377065799689

nanomonkey: recipe manager

UI works with both keyboard and mouse

• frontend https://github.com/nanomonkey/scratch
• backend https://github.com/nanomonkey/ssb%5Fclj%5Frepl

Chat

13:36 cblgh says: order ['hoody', 'juha', 'mauve', 'fellow jitsi', 'cinn', 'mix', 'rosano', 'cblgh', 'gwil']
13:39 Mauve says: https://agregore.mauve.moe/
13:40 cblgh says: https://merveilles.town/web/accounts/57295 <-- amatecha
13:42 cinnamon says: https://github.com/earthstar-project/earthstar
13:42 cinnamon says: p.s. I use they/them pronouns
13:44 cblgh says: (updated order: ['hoody', 'juha', 'mauve', 'fellow jitsi', 'cinn', 'mix', 'rosano', 'cblgh', 'gwil', 'geoffrey', 'interfect'])
13:44 cblgh says: o ya he/him/they i guess 😃
13:44 rosano says: he/they
13:46 Juha Autero says: he/they also
13:48 rosano says: https://duckduckgo.com/?q=timer+7+min&ia=answer
13:49 cblgh says: https://github.com/AljoschaMeyer/bamboo
13:49 cblgh says: https://collapseos.org/
13:55 cblgh says: o/ nanomonkey 😃
13:56 gwil says: fully sick
14:07 cblgh says: https://github.com/AljoschaMeyer
14:07 cblgh says: https://github.com/fraction/oasis
14:07 cblgh says: https://github.com/earthstar-project/earthstar
14:09 nanomonkey says: So, I built the first two boards for the disaster radio project. I have some experience with building Lora antannas in Kicad if you need any help.
14:10 interfect says: Thanks!
14:12 cblgh says: https://cblgh.org/trustnet/
14:12 cblgh says: (pardon the orange halloween theme x)
14:16 hoody says: earthstar is dope
14:17 cblgh says: https://buntimer-earthstar.netlify.com
14:21 cinnamon says: https://earthstar-demo-pub-v6-a.glitch.me/
14:21 cinnamon says: https://github.com/earthstar-project/earthstar-pub
14:21 cblgh says: https://gitlab.com/ahau/lib/ssb-crut
14:21 cblgh says: https://ahau.io/
14:22 nanomonkey says: Any suggestions on how to get mics working? I've tried all the options available through jitsi that I can find.
14:23 cblgh says: hm not sure 😕 replug it probably, or try chrome and see if that does it?
14:23 gwil says: which browser are you on? safari always gives me trouble
14:23 rosano says: @nanomonkey i think you probably did it right, maybe try a different browser?
14:23 nanomonkey says: firefox
14:23 rosano says: yea safari doesn't work for me
14:23 nanomonkey says: on llnux
14:24 Mauve says: I'm on Firefox on Linux and I think my mic works FWIW.
14:24 Mauve says: I'm guessing your mic gain is up and your system is seeing stuff when you try to test it outside the browser?
14:25 cblgh says: once i had to click on the lil tab above the mic and pic another microphone, cause it was picking up a different one
14:25 cblgh says: (guess you already tried that tho!)
14:25 cblgh says: hey cryptix 😃
14:25 cblgh says: we're streaming mix (not sure if you can see it)
14:26 cryptix says: hey ya'll!
14:26 cryptix says: yea i can. sorry for being late.. i somehow messed up writing down the wrong time
14:26 cblgh says: nw 😃
14:26 rosano says: timezones are complicated… but thanks for being here, be welcome 😃
14:27 Juha Autero says: nanomankey: Does addressbar show that you have granted extra permissions on website?
14:27 cblgh says: boost ON
14:27 amatecha says: oh wow I figured out how to set name and use chat. woot
14:28 cblgh says: (mix gave me permission to 1.25x it once it got close to the 7 min work fwiw 😃
14:28 rosano says: dj alex
14:31 cblgh says: 💿😎
14:31 cblgh says: https://github.com/mixmix/ssb-crut-demo
14:31 cblgh says: if anyone wants to rewatch it it's here: https://www.youtube.com/watch?v=URIUbupxxU4
14:31 cblgh says: ['hoody', 'juha', 'mauve', 'fellow jitsi', 'cinn', 'mix', 'rosano', 'cblgh', 'gwil', 'geoffrey', 'interfect', 'nanomonkey', 'cryptix']
14:35 hoody says: getting super flaky net here at y homeboys house
14:35 hoody says: heading back to home and trying again
14:36 Mauve says: lol, I can't share screen from Agregore yet since I haven't implemented the UI for it. 😂
14:36 rosano says: #browsergoals
14:41 cblgh says: i guess this
14:41 https://www.home-assistant.io/ :^)
14:41 rosano says: https://www.home-assistant.io
14:42 Mauve says: Just confirming with the person I'm meeting though
14:44 cblgh says: https://godotengine.org/
14:44 cblgh says: https://github.com/RangerMauve/hypergodot
14:45 nanomonkey says: Juha, there is a couple of libraries in Python for opening and writing to excel files. This might help you out.
14:45 nanomonkey says: Pandas can do it directly and has lots of support.
14:46 cblgh says: (also known as dat previously : )
14:46 cblgh says: https://hypercore-protocol.org/
14:46 amatecha says: oohhh (didn’t know dat was “rebranded”!)
14:47 Juha Autero says: I'm experienced Python programmer. What I'm trying to learn is javascript frameworks.
14:47 rosano says: "as little as possible to make stuff just work" all the things
14:50 cblgh says: big brain energy
14:51 Mauve says: https://github.com/RangerMauve/hyper-gateway
14:51 Mauve says: https://github.com/RangerMauve/hypercore-fetch
15:00 cblgh says: https://github.com/hyperswarm/hyperswarm
15:00 cblgh says: https://hyperdraft.rosano.ca
15:00 cblgh says: https://github.com/sveltejs/svelte
15:02 cblgh says: https://www.cypress.io/
15:04 Mauve says: K, gotta go. TY folks!
15:06 cblgh says: gwil u can go ahead of me if you want 😃
15:06 gwil says: I'll take you up on that
15:09 gwil says: https://earthstar-letterbox.netlify.app/join/earthstar:///?workspace=+plaza.prm27p8eg65c&pub=https://earthstar-demo-pub-6b.fly.dev&pub=https://earthstar-demo-pub-v6-a.glitch.me&v=1
15:13 cblgh says: (i love the pocket terminology that gwil is putting into action here)
15:13 cblgh says: if u remember (from cinn): to participate u gotta make an identity, and then you click on "join plaza" or whatever at the bottom!
15:14 rosano says: local-first!
15:16 cblgh says: 👏👏👏
15:16 rosano says: ❤️
15:18 hoody says: back on track. hallo cryptix
15:19 cblgh says: wb!
15:20 gwil says: https://discord.gg/RGsvu9a9 <-- earthstar discord
15:20 cblgh says: remaining potential presentations [ 'cblgh', 'nanomonkey', 'cryptix']
15:20 gwil says: cinnamon's docS are NUTS
15:22 rosano says: https://lieu.cblgh.org
15:23 Juha Autero says: Accidentally closed tab.
15:26 rosano says: ooooh lala
15:26 hoody says: any preferred thing to do to make your site lieu friendly?
15:27 gwil says: yeah, is there a way for it to handle browser-rendered apps / pipe data in?
15:28 cblgh says: p:first-of-type
15:28 gwil says: A whole new industry of dark web SEO
15:29 hoody says: heh heh
15:29 hoody says: how about a button you could display
15:29 hoody says: oldskool, part of webring / use lieu here
15:30 cblgh says: oh ya, like ready made?
15:32 hoody says: yup, to help people find this thing
15:32 hoody says: neocities friendly stuff, simple
15:32 hoody says: https://vmx.cx/cgi-bin/blog/index.cgi/category/Noise
15:32 hoody says: might be handy soehow
15:32 hoody says: somehow
15:32 gwil says: thanks everyone, I've got to run!
15:33 hoody says: cheers gwil
15:33 cblgh says: am i the only one that can't see it?
15:33 cryptix says: nope
15:33 amatecha says: i see nothing lol
15:33 Juha Autero says: me neither
15:34 cblgh says: now we're good
15:34 Juha Autero says: now i can see
15:45 cblgh says: varasanos og
15:45 cblgh says: https://www.varasanos.com/PizzaRecipe.htm
15:45 cblgh says: this guy is so serious, check out his site to learn everything about making pizza
15:45 cblgh says: related: just found out about this markup language for recipes today https://cooklang.org/
15:45 cblgh says: high yield recipe
15:45 cblgh says: https://clojurescript.org/
15:45 cblgh says: https://valueflo.ws/
15:45 cblgh says: https://bob.mikorizal.org/users/bhaugen
15:45 cblgh says: (bob's fedi)
15:45 cblgh says: https://github.com/ssb-ngi-pointer/ssb-db2
15:47 hoody says: it's snowing here, got some cocoa and cryptix explaining stuff on the headphones, this is cool
15:49 cblgh says: ohh wow
15:49 cblgh says: just arctic circle things
15:49 cblgh says: https://github.com/nanomonkey/scratch
15:49 cblgh says: https://github.com/nanomonkey/ssb%5Fclj%5Frepl
15:52 hoody says: ssbCRUD
15:52 hoody says: i think many people are interested in running ssb as distributed key-val store
15:52 cryptix says: +1
15:54 nanomonkey says: What ssb client are folks using these days?
15:54 cblgh says: still patchwork x)
15:54 hoody says: is there a zero data manifesto somewhere?
15:54 hoody says: patchwork
15:55 rosano says: @hoody some principles at https://0data.app
15:55 hoody says: cheers rosano
15:57 amatecha says: \o/
15:59 cryptix says: also nano, feel free to mention me with these questions
15:59 nanomonkey says: will do
15:59 cryptix says: also sure cel would be down to answer - also req criquets: like gwil said, somethomes these threads just vanish
15:59 rosano says: https://chat.rosano.ca/t/zero-data-swap-3-maker-meet-october-27-2021/44
15:59 rosano says: https://0data.app
16:00 hoody says: super cool, thanks for doing this
16:00 hoody says: cu!

• Gordon Brander works on a tool for imagination, and recently wrote about composability with other tools.
• Rosano works on various Zero Data apps like Hyperdraft and Launchlet.

Reading Inspiration

Composability with other tools:

With one-off API integrations, every app must be connected with every other app in both directions. The number of integrations required for interoperability is equal to the maximal number of edges in a directed graph, or n * (n-1). Adding one more app, for a total of 6, means going from 20 to 30 integrations. 10 apps is 90 integrations! […] Imagine any of these apps needs to change its API. Now every single other app in the network needs to change its integration code. Everyone in the network has to coordinate, because everyone in the network has to implement everything.

The protocol acts as a hub in the network, cutting the number of connections necessary for full interoperability from n * (n - 1), to just n. The number of integrations scales 1:1 with the number of apps. […] none of these apps have to know anything about each other. All they need to know is the protocol. This makes the set of possible workflows between apps an open set. […] Files make interoperability the default […] Files allow interoperability 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. This has happened many times, from .doc, to .rtf, to .psd. Competing products are able to get off the ground by interoperating with incumbents. New workflows can be created permissionlessly.

Protocols produce creative combinatorial explosions […] When you have a universal API for composition each additional tool increases the number of possible workflow combinations by n * (n - 1). […] That’s our directional graph equation again, but this time the network effect is on our side. The more tools, the more possibilities. […] If a tool supports composition with other tools, it supports open-ended evolution. At that point, all of the other ways in which it might be terrible become incidental, because an evolutionary system will always be more expressive than one that isn’t. Nothing else can widen the potential of creative tools as rapidly as composability with other tools. It's not even close.

The future needs files – Scott Jenson:

The power of files comes from them being powerful nouns. They are temporary holding blocks that are used as a form of exchange between applications. A range of apps can edit a single file in a single location. On mobile, the primary way to really use files is to “Share” between apps. This demotes files from a powerful abstract noun into a lackluster narrow verb. […] For example, I can import a text file into the Notes app but it’s really nothing more than a glorified copy/paste, not an editing of an object in place. This makes a cloud storage service like DropBox nearly useless as I’m not editing “the thing” but a copy of the thing. I need to save it back out to Dropbox if I want anyone else to see my changes. That’s vastly underutilizing the power of the abstraction that comes from files.

This isn’t some feeble political statement to liberate my data from a company. I want files to liberate my data from my own apps and create an ML explosion of activity! Files are at some level a hack, I get that, there are limits but they are an extremely useful and flexible hack. Like the QWERTY keyboard, they are “good enough” for most tasks. Files encapsulate a ‘chunk’ of your work and allow that chunk to be seen, moved, acted on, and accessed by multiple people and more importantly external 3rd party processes.

LN 002: Universal data portability:

What if you could move data items, with views provided by their hosting applications, around system and application views? What if we could bring together a series of things that all relate, even if they are of different types, and are from different apps or windows? What if you could browse your things in one fluid interface, without regard for their differing data types?

When you pull an item into some other place, it is still rendered by its hosting application. Hosting applications provide the view components for rendering data items in different situations or sizes. It can be thought of much like a widget in today’s operating systems: the system defines what the data item is and what size it should take up, then it relies on the data item’s hosting application to provide the view component that renders it.

See also the previous swap.

---

Summary

We discussed what makes files composable and extensible, how to be supportive of files in ecosystems where they aren't present (such as mobile), what changes when using files via Zero Data protocols, and more. Participants included Alexander Cobleigh, Boris Mann, Doug Reeder, Gordon Brander, Jess Martin, Noel De Martin, Rosano.

Recording

The half the video failed to record, and rendering for the remainder was glitchy, so this is essentially an audio podcast.

time	section
00:00	Intro
01:31	Aggregators dominate the web
03:08	Aggregators are incentivised to keep systems closed
05:13	Every app eventually implements email and Clubhouse
06:19	Files and app security
07:58	Files as a lego dot of computing
10:39	Files give data an object metaphor
12:22	Disadvantages of files on the network
13:44	LAMP stack is too hard
15:05	Civilization-scale infrastructure for persisting information
16:10	Nouns, verbs, and files
18:08	Files enable interoperability to emerge
22:20	Build tools around workflows
25:03	Customizing apps without programming
26:52	Authentication raises the barrier to entry for interoperability
28:41	Helping people understand where data lives
30:21	Authorization dialogues are complex
32:19	Comparing Personal Data Store with Wallet
34:03	Comparing access via apps and search
37:51	Why does stuff need to exist only in one place?
40:58	Teaching people drag-and-drop with Tiddlywiki
43:06	Complexity of network connections with scale
43:46	File formats are like network hubs
45:40	Drag-and-drop is a versatile endpoint
47:00	Helping people understand technical metaphors
48:39	Patterns from web3 wallets
50:07	QR codes for transferring data
51:21	Collaboration via Croquet and QR codes
53:26	Global and unique and memorable
56:11	Trust by device proximity
57:30	Keeping parity with features popularized by Apple
61:19	Interoperability by producing narrow output and accepting broad input
65:29	Onboarding issues
67:19	QR codes enabling multiplayer

Chat

The first half of the chat was lost due to a call drop. These times reflect a start time of 16:00.

16:48 cblgh says: ( haha oh dang, sorry for dropping out x) )
16:48 Noel says: ( I think everyone did )
16:49 Rosano says: ( if anyone has the old chat can they save it? )
16:49 cblgh says: ( "tiddlers" thoooooo )
16:49 Jess says: ( we all lost it 😦((( )
16:50 Gordon says: nooooooo
16:50 Gordon says: TiddlyWiki is so compelling
16:50 Gordon says: ( https://subconscious.substack.com/p/composability-with-other-tools)
16:53 Jess says: it's the cause of Brooks Law
16:53 Jess says: as well
16:53 Jess says: https://en.wikipedia.org/wiki/Brooks's_law
16:53 Jess says: "Communication overhead increases as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3] Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing."
16:53 Jess says: we're focusing on the workflow! 😛
16:53 Jess says: the UX
16:53 Jess says: the action
16:53 Jess says: sets up an expectation that it will work
16:53 Jess says: atJSON
16:53 Jess says: ( 😛 )
16:54 Gordon says: ( can y'all share a link to this? )
16:54 cblgh says: https://developer.mozilla.org/en-US/docs/Web/API/HTML%5FDrag%5Fand%5FDrop%5FAPI
16:54 Boris says: https://twitter.com/bmann/status/1443246811607560193?s=20
16:55 Gordon says: ( love it )
16:56 Boris says: And then the actual reference docs for TW https://tiddlywiki.com/dev/#TiddlyWiki Drag and Drop Interoperability
16:56 Boris says: OK, it's already a bag of JSON. Title and Text and arbitrary custom fields var titleString = "This is the string that appears when the block is dragged to a text input"; var tiddlerData = [{title: "Tiddler One", text: "This is one of the payload tiddlers"}, {title: "Tiddler Two", text: "This is another of the payload tiddlers", "custom-field": "A custom field value"}];
16:58 cblgh says: it's interesting to think about the "education of users" from the perspective of storytelling; do you do the exposition thing and dump it all on people in the beginning ("hello, welcome!" screen), or do your characters (whatever that is in an app? a feature? its affordances?) pull people in gradually to the understanding
16:58 cblgh says: ( lol cmd-w is lethal in notetaking apps in browsers (it doesn't delete the last word!!) )
16:58 Jess says: ooooooooohhh I like this direction
16:58 Jess says: ( we're working heavily with QR codes at Croquet )
16:58 Gordon says: ( 100 )
16:59 Jess says: and to think of their phone as a container!
16:59 Jess says: or my phone as the key...
16:59 Jess says: ( or something )
16:59 Gordon says: ( yes! )
16:59 Jess says: ( the metaphor )
16:59 Rosano says: ( @cblgh i avoid the hello welcome but fail to do onboarding… something fundamental to think about, i like the story metaphor )
16:59 Gordon says: ( It makes intuitive sense. Phones are very personal. )
17:01 Jess says: 2FA
17:01 Jess says: in general
17:01 Jess says: ( magic links, so true )
17:01 Noel says: ( We were talking about gen Z before, I think a lot of them don't even use email, they just have social logins (like login with Facebook) )
17:01 Doug says: This particular hardware didn't catch on, but this video shows where we'd like to be: https://www.youtube.com/watch?v=2oLfKqpUJT4
17:02 Jess says: http://www.aaronsw.com/weblog/squarezooko
17:02 cblgh says: great article on squaring zooko's triangle for a particular set of use cases
https://www.inkandswitch.com/backchannel/
17:02 Boris says: doesn't square it at all
17:02 Boris says: it uses pet names
17:02 Boris says: ( not globally unique )
17:03 cblgh says: ( the relationship is though )
17:03 Boris says: ( yep! )
17:04 Jess says: ( I definitely will, because I want to work on more hardware stuff once we solve this software stuff 😃 )
17:04 Boris says: ( @Rosano -- please make sure to copy / paste / export this chat at end of call )
17:05 Rosano says: ( @boris just copied now, hope to copy later, the first chat may be gone )
17:06 Jess says: ( amazing UX )
17:07 Rosano says: https://youtu.be/cpNk6fkwS2I?t=15
17:07 Rosano says: ( ethereal blue dots )
17:07 Doug says: ( That youtube video is private )
17:07 cblgh says: kinda related project i put together for sharing cabal keys across computers in physical space "whisperlinks" https://github.com/cblgh/paperslip "share hard-to-transmit snippets with easy-to-pronounce names using dht magic"
17:08 Boris says: ( Oh yeah, the video is private )
17:09 Gordon says: https://en.wikipedia.org/wiki/Celestial%5FEmporium%5Fof%5FBenevolent%5FKnowledge
17:10 cblgh says: oops gotta go, thanks for the chat everyone!
17:10 cblgh says: ( (sorry i didnt participate that much, but 23:00 here '😃 )
17:10 Rosano says: ( see ya alex! thanks for coming, good night )
17:10 Gordon says: ( thanks everyone! )
17:11 Jess says: https://en.wikipedia.org/wiki/Robustness%5Fprinciple "Be conservative in what you do, be liberal in what you accept from others."
17:11 Jess says: and text can be assumed to be first line...
17:11 Jess says: ( sorry, title can be assumed to be first line of text )
17:12 Gordon says: ( Files, copy/paste, drag-drop the ur-interop features )
17:13 Jess says: ( opencollective??? )
17:13 Gordon says: ( I Would Simply Have Expede Solve Sync )
17:13 Jess says: ( I'm free 😉 )
17:13 Gordon says: ( I'm game )
17:14 Boris says: ( passwordless file-less onboarding something something )
17:14 Jess says: ( "shared language of onboarding in passport-less, data-less systems" )
17:14 Gordon says: ( +1 doorless is awesome )
17:15 Jess says: ( MAYA: most advanced, yet acceptable )
17:15 Noel says: ( doorless does not contradict onboarding, you can put an onboarding in place of a blank canvas )
17:15 Jess says: oooooh the natto.dev interactive tutorial is AMAZING btw
17:15 Noel says: ( that's sort of what I did with Media Kraken )
17:15 Rosano says: ( @noel but that takes work )
17:15 Jess says: ( https://natto.dev/tutorial/tip-calculator)