LinkJar 0.1: Genesis

There was a version of the internet where the hyperlink was the whole point. You didn’t open an app and wait to be fed. You landed on a page, followed a link in the middle of a sentence, ended up on someone’s “cool sites” list, and surfaced an hour later somewhere wonderful you couldn’t have searched for. We called it surfing, and it was awesome and the name was accurate: the links were the waves. Webrings, blogrolls, directories, a stranger’s meticulously curated bookmarks page. The web was navigable because people who cared left trails for each other.

As ranked feeds grew, discovery increasingly depended on engagement scores. The tools that supported personal curation also began to disappear. Del.icio.us was sold, sold again, and shut down. Google Reader’s shared items vanished. Read-it-later services closed, sometimes leaving people only a short export window. People had spent years collecting links in services whose owners stopped maintaining them.

Those products helped people discover and organize links. Many were great. The problem was structural: access to the collection depended on one service.

LinkJar is our attempt to make personal link collections less dependent on any one service. It’s a social bookmarking system where your links are stored in a repository you own, on an open protocol, and where anything you mark private is encrypted on your device before storage. Requested previews, snapshot capture, and cloud AI can send selected URLs or content to the service that performs the task. Today we’re publishing version 0.1 of the specification (an early version we’re actively still shaping) and opening the private alpha. This post is the why and the what. The how gets its own posts.

Records, not rows

LinkJar is built on AT Protocol, the open network behind Bluesky. Every user has a personal data repository hosted by a provider they can change at any time, addressed by a portable identity. Applications don’t own your data. They read and write records in your repo.

The entire protocol surface of LinkJar is nine record types under the io.linkjar.* namespace. A public bookmark is just a record anyone can read, index, and build on:

{
  "$type": "io.linkjar.bookmark",
  "url": "https://example.com/a-good-read",
  "normalizedUrl": "https://example.com/a-good-read",
  "title": "A good read",
  "visibility": "public",
  "tags": ["essays", "web"],
  "createdAt": "2026-07-04T10:30:00Z"
}

The spec’s first two rules set the tone for everything else: user data must be stored as records in the user’s repo, and services may build derived indexes for performance but must treat the repo as the source of truth. If LinkJar disappeared tomorrow, your jar would still be sitting in your repo, readable by any client that speaks the lexicons. Your data remains in your account even when you change clients.

How private storage works

Public bookmarks are half the story. The other half is the Private Jar, and it’s where most of the engineering went.

Private records are encrypted on your device. LinkJar services and your hosting provider do not receive the keys needed to decrypt those stored records. That storage guarantee is separate from services you request: fetching a preview or snapshot reveals its URL, and cloud AI receives the selected content.

The whole key hierarchy grows out of a single 32-byte seed generated on your device. Account working keys are derived from that seed; individual links also use random content keys wrapped by an account key. What lands in your repo is ciphertext, a nonce, and a wrapped key. The URL, the title, your notes, your tags: all of it is opaque to us, to your hosting provider, and to anyone crawling the network.

One seed buys two things. Backup is a single secret instead of a keychain, exportable as a compact recovery string or a 24-word phrase. And there is an honest cost, which we state plainly: if you lose your Recovery Kit and every device unlock method, we cannot recover your private data. Save your Recovery Kit somewhere you can find it without access to LinkJar.

Useful without seeing anything

Zero-knowledge is easy if you’re willing to ship a bad product. The hard part is keeping the features people expect from a bookmarking tool when the server can’t read the data.

Search runs entirely on your device: encrypted records sync down, get decrypted locally, and are indexed in an in-browser database. The plaintext only ever exists in your browser’s memory.

Deduplication (“you already saved this”) would normally require the server to compare URLs. Instead, your device computes a keyed fingerprint of each URL: the same URL always produces the same opaque token for you, and a different one for everyone else, so nobody can build a table of who saved what.

Multi-device editing can’t rely on a server to referee conflicts it cannot read, so the records are built to merge themselves: any two devices that have seen the same edits arrive at the same result, no coordination required. Save on your phone, tag on your laptop, and the merge is deterministic.

Sharing a private board was the gnarliest one: hand someone a single board key and they can decrypt exactly the bookmarks on that board, and nothing else in your jar.

Each of these hides real machinery (key derivation trees, envelope encryption, CRDTs) that deserves more than a paragraph. That’s what the follow-up posts in this series are for.

Why

Personally, I miss the old web: the discovery, the curation, the sense of following a trail someone left. The underlying issue matters beyond nostalgia.

Data sovereignty is a basic right. You should own your data, decide what’s private, and share it on your terms. LinkJar is built on AT Protocol which is naturally suited for that.

What 0.1 means

We want to be precise about the version number. The spec is in an early phase. The core ideas (records in your repo, client-side encryption, one seed) are settled. The details, like field constraints, lexicon shapes, and the exact sharing flow, are still moving as we build the first clients (web and extension, now in private alpha) and discover where the paper design meets reality. Nothing is live yet, which is exactly why now is the moment to get the foundations right rather than to freeze them.

Publishing early is deliberate. The whole point of building on an open protocol is that you don’t have to take our word for anything, and the corollary is that you can tell us where we’re wrong before 1.0, while being wrong is still cheap.

Coming next in this series: a walk through the spec itself (the key hierarchy, envelope encryption, and how tags merge without a referee) and a post on how the spec was written: the decision records, the threat model, and the test vectors that let other people implement LinkJar without reading our source.

If any of this resonates, request an invite, read the manifesto, or dig into the spec and tell us where we’re wrong. You can also email us at hi@linkjar.io.

Your links. Your jar. Forever.