“Personal software” is software you create for yourself. It’s designed for your needs, your preferences, and your workflows. Its scale is you.

It’s allowed to be more idiosyncratic than any off-the-shelf app could ever afford. And it shouldn’t stop at just you– personal software should also encompass tools built within your family, friend group, company, or community.

Personal software is about choice. You pick your tools, and other apps respect your choices.

Historically, there’s been no good reason for commercial software to integrate with apps that only a handful of people use. But that dynamic is shifting. We’re seeing more non-technical people not just using, but writing their own software.

The question I often wonder is: what would it take for integrating with homebrew identity providers, social feeds, calendars, and beyond to actually become worthwhile?

If we ever get there…

To make personal software interoperable, we’ll need standards for discovery and protocol negotiation.

I worked on an Ethereum wallet for a while. I was drawn in by what was happening around the ERC-721 standard. Not just NFTs as art or speculation, but that a few standards enabled anyone to build a client that could manage identity, exchange value, and mutate and interact with a wide ecosystem of apps even without knowing anything about them.

That led me into over a year of research on interoperability: how apps could connect and communicate without ever having heard of each other.

One experiment was a client-side protocol: a webpage could send requests to the apps of the user’s choice by opening a new window and using postMessage to communicate. The initial window would be to a well-known URL where the user’s chosen provider for a given protocol would be cookied, then they’d be immediately redirected to the provider app, and the provider would initiate communication with the requesting app so they could begin communicating.

It worked, but the best-case UX wasn’t great because the initiating app had no way to know whether the user used the protocol. Apps would have to show an option that most users would never choose.

Another attempt, a Peering Protocol, let apps share a connection link (or scan a QR code) to establish a peering connection, negotiate protocols, and begin communicating. Technically sound, but still too much hassle.

What might actually work

The most promising approach came from a network-level protocol.

I used Tailscale with a custom DNS server to set up a well-known hostname: principal.internal (“principal” referring to the human end user; “internal” being a safe ICANN-reserved TLD). Any app on any device on the tailnet could query principal.internal to:

• Check if I used an app supporting a desired protocol.
• Discover which protocols I used (e.g., ai.ollama.chat, com.selfref.identity).

Requests sent to principal.internal would be relayed to my chosen app, which would handle the request and send a response back to the requesting app. This design lets apps only display “Sign In with Self Ref” or “Add to Self Ref Calendar” buttons if they I used those apps.

This one has no public repo currently, but the concept is straightforward enough to hack together :)

Why this matters

Personal software will only “arrive” when everyday apps support it as naturally as they do Sign in with Google, OpenAI APIs, or Add to Calendar.

It’s time to build the standards that will enable personal software to take on a new level of visibility and relevance.