PassbackAI
Private
Under the hood · June 2026 · 6 min read

How do you share a doc when nobody has an account?

It's 23:48 and the draft is finally marked up — five comments, each anchored to the exact line it argues with. Before the whole thing goes back to the model, you want one more pair of eyes on it: the colleague who actually knows whether section three is true. So you reach for the usual moves. Paste it into a Google Doc, and your comments arrive as plain text torn off their anchors. Screenshot it into Slack, and they get a picture of a document instead of a document.

PassbackAI has a Share button instead. Which raises a fair question, because we have no accounts, no logins, and no server to upload anything to. Share it where, exactly?

TL;DR

A PassbackAI share link doesn't point at your document — it carries it. The whole doc, comments included, is compressed and encoded into the link's hash fragment: the part of a URL after the # that the browser never sends to any server, ours included. Nothing is uploaded, nothing is stored anywhere except inside the link itself, and nobody needs an account on either end. Add a password and the same payload travels end-to-end encrypted (AES-GCM, key derived from the password — which never rides in the link). Your colleague opens it in a browser, reads the draft with every comment exactly where you anchored it, adds their own notes under their own name, and hands it back — and the merged feedback returns to the model in one paste.

Share it where, exactly?

The question assumes something so universal it's invisible: that sharing means uploading. Every share flow you've ever used works the same way — the document goes to a server, the server hands back a pointer, and accounts exist to decide who may follow the pointer. The doc lives there; the link is just directions. That's what "share" has meant for twenty years, and it's why "share" and "sign in" arrive welded together.

So when an app whose whole promise is nothing you paste ever leaves your browser grows a Share button, the reasonable assumption is that the promise just quietly died — that somewhere a bucket now holds your draft, and the privacy page got a new paragraph of exceptions.

It didn't. The document still never touches a server. We just stopped using the URL as a pointer.

The part of the URL the browser keeps to itself

A URL has one section the browser treats differently from all the others: the fragment — everything after the #. It was designed to mean "a position within the page," which is a fact the server never needed, so browsers never send it. Not in the request. Not in the Referer header. Not to analytics. Of the entire address you see in the bar, the fragment is the one part that stays on your machine.

We take that property literally. When you share, PassbackAI compresses the whole document — the Markdown, your comments, their anchors — and encodes it, URL-safe, into the fragment of a single link. The address looks like passbackai.com/shared#s=…, and everything after #s= is your document.

When your colleague clicks it, our server sees a request for an empty page and nothing more. The page arrives blank; their browser reconstructs the document locally, from the link, on their machine. The draft made the entire trip inside the address bar — which is also why there's no account on their end either. There's no upload to gate, so there's nothing to log into. They click, and they're reading.

One honest limit: a link can only get so long before the world around it starts misbehaving. Past roughly 16,000 characters, chat apps and mail clients begin silently truncating URLs — so we refuse to mint a link we know will arrive broken, and tell you up front instead of letting it fail at the other end. In practice the ceiling is roomy; Markdown compresses well, and a long, dense, heavily commented draft fits with room to spare.

What rides along with the doc

Your comments, with your name on them. The recipient sees every note exactly where you anchored it, signed. When they add their own, both of you — and eventually the model — can tell who said what.

A lock, if you want one. Tick it when you share and your comments arrive read-only: your colleague can add notes next to yours, but not edit or delete them. If the doc gets passed onward, locked comments keep their original author and protection through every hop.

A note to the human. One line that travels inside the link itself — "section three: is this actually true?" — so the doc arrives with its question attached, not in a separate message they'll read after forming the wrong opinion.

And to be precise about what doesn't ride along: presence, live cursors, a shared workspace. The recipient's copy is a copy. This is one person handing a draft to one other person for a second pair of eyes — not a place where a team moves in. The draft is in transit, not in residence.

Add a password, and even the link can't read itself

A plain share link has the trust model of a printed page: holding it is reading it. Forward-friendly, and for most drafts exactly right. For the ones where it isn't, add a password when you share.

The same compressed payload is then encrypted with AES-256-GCM, under a key derived from your password — 600,000 rounds of PBKDF2, the current OWASP floor. The link carries only the salt, the nonce, and the ciphertext. The password itself never appears in the link, never reaches a server (there isn't one to reach), and never gets stored. You hand it to your colleague through some other channel; a wrong guess fails cleanly and they try again.

The cryptography is the standard, published kind, running in the browser's own WebCrypto — the security rests entirely on the password, not on anyone keeping the mechanism secret. Our code is public; go read it. The practical upshot is blunt: a protected link is unreadable without the password — to a chat app that previews it, to anyone who finds it later, and to us. There is no "recover document" button, because there is no place a recovery could come from. That's not a missing feature. That's the design holding.

The link doesn't point at the document. The link is the document.

And then it comes back

The trick is fun, but the trick isn't the point. The point is that a second pair of eyes joins the review without breaking the round trip. Paste the draft into a Google Doc to "show someone" and you've stranded it: the comments lose their anchors, and whatever feedback comes back arrives as prose you now get to retype into the chat box. The markup dies in transit, and the way back to the model dies with it.

A share link keeps both alive. Your colleague's notes land anchored on the same draft, next to yours, each signed. They hand the doc back the same way it arrived — one link. And then the whole conversation — your five comments, their three, every verbatim quote and heading anchor intact — boards the train back to the model in one paste. The format that makes the model apply all of it cleanly is in the guide; the case for why drafts should move this way at all is in the manifesto. PassbackAI is the smart clipboard for the AI era — and now the clipboard fits two people, with nobody signing in.


We went looking for the server to put your document on. We don't have one. Turns out the URL bar was big enough all along.

The questions a Share button with no Sign-in button raises.

How can you share a document if there are no accounts?

Because the link doesn't point at the document — it carries it. Every share flow you know uploads the doc to a server and hands out a pointer; accounts exist to decide who may follow the pointer. PassbackAI skips all of that: the whole document, comments included, is compressed and encoded into the URL's hash fragment — the part after the # that the browser never sends to any server. No upload means nothing to gate, which means nobody needs an account: not you to send it, not your colleague to open it. A browser is the only requirement on either end.

Where is the shared document actually stored?

Inside the link, and nowhere else. The fragment was designed to mean "a position within a page," so browsers never include it in any request — not to our server, not in the Referer header, not to analytics. When the recipient opens the link, our server sees a request for an empty page; their browser rebuilds the document locally from the fragment. Delete the link and that shared copy is gone — there's no server copy to chase down, because there never was one. The full promise is on the privacy page.

Can anyone who gets the link read my document?

A plain link, yes — holding the link is holding the document, the same trust model as handing someone a printed page. When that's not enough, add a password: the payload is then encrypted with AES-256-GCM under a key derived from your password (PBKDF2, 600,000 iterations), and the link carries only salt, nonce, and ciphertext. The password never travels in the link — you pass it through a different channel — so a protected link is unreadable to anyone without it, including us. No server copy, no recovery: lose the password and that link stays sealed.

Can the person I share with change my comments?

Only if you let them. Your comments arrive carrying your name, so when the recipient adds theirs, everyone can tell who said what. Tick the lock option when you share and your comments arrive read-only — they can add notes next to yours, not edit or delete them. Passed onward, locked comments keep their original author and protection. And their copy is a copy: this is one person handing a draft to one other person, not a shared workspace with live cursors.

Is there a size limit on share links?

About 16,000 characters of encoded link. Past that, chat apps, mail clients, and some address bars start silently truncating URLs — so PassbackAI refuses to mint a link it knows will arrive broken, and tells you up front instead of letting it fail at the other end. In practice the ceiling is roomy: Markdown compresses well, so a long, heavily commented draft fits comfortably. The cap protects the recipient's first click; it's not a nudge toward an upload.