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.

Then the feed ate the link, and everything changed. Discovery stopped being something you did and became something done to you, the personal and chaotic experience got ripped out in favor of ranked by engagement rather than by anyone’s judgment. And the tools and services that powered the old way died one by one. Del.icio.us was sold, sold again, and shut down. Google Reader’s shared items vanished overnight, once popular bb’s got outed. A parade of read-it-later apps sunsetted with a polite email and a 30-day export window (maybe). The pattern, same and predictable this every moment: people poured years of attention into someone else’s database, and the database outlived their interest in running it.

We don’t think those products were bad, and real progress in curation and patterns of use were made. Most were great. The problem was structural: the data lived in the wrong place.

LinkJar is our attempt to rebuild that layer of the web so it can’t be taken away again. 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 it ever touches a server. Data? Yours, to share and curate the way you want. 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",
  "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. That’s not an export feature. That’s the architecture.

Private means mathematically private

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

Our rule for private data is simple: LinkJar-operated services must be unable to decrypt it. Not “we promise not to look.” Unable. Everything private is encrypted client-side, and the keys never leave your custody.

The whole key hierarchy grows out of a single 32-byte seed generated on your device. Every working key — for bookmarks, for each shared board, for page archives, for deduplication — is derived from that seed. 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 the seed, we cannot recover your private data. Nobody can. That is the guarantee working as designed, and it’s why the app is persistent about making you save your recovery kit.

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. But the nostalgia is just a side effect, the underlyig issue is real.

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 — field constraints, lexicon shapes, 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. If you have any questions feel free to reach us out via mail @ hi@linkjar.io

Your links. Your jar. Forever.