When your archive sends an invitation, it first creates and seals the message. A delivery service then carries it to your friend. This page compares the options we considered, including the ones we rejected and why. The Message Transport technical page contains the protocol details.
A private shared folder, a text message, a USB stick, someday something else: the box itself stays the same. The road is the only thing that changes.
You've already seen this idea on two other pages: a private trusted folder was the first road we built, and a text message was the second. Both carry the exact same kind of sealed envelope. Neither road gets to open it, read it, or change what's inside. A road's whole job is to carry the box from your porch to your friend's.
That's what we mean by message delivery: moving the sealed envelope from your archive to hers. This page looks at several roads we considered: some we built, some we're saving for later, and a couple we looked at closely and decided against, on purpose.
Before touring the options, every road on this page gets asked the same three questions, in the same order:
Can it actually carry the box? Some "roads" are really databases. Nobody built them to move a private message between two specific people.
Who runs the road, and do you already trust them? Every road has an owner — a phone company, a tech company, sometimes nobody at all (a shared folder you and your friend both hold the only keys to).
Does that answer mean the box has to be double-locked? If you don't already trust whoever runs the road, the box gets sealed so even they can't see inside. We apply the same rule every time, to a big name and a familiar app alike.
Nothing about how famous a road is, how nice its map looks, or how clever its owner's other ideas are changes the answer to those three questions.
Signal is often called the gold standard for private messaging, and it's a fair reputation: the way it protects a conversation is excellent. But running Signal's own machinery ourselves would mean building and maintaining a small piece of Signal's own infrastructure, just to carry messages between people who, in a circle of ten, already know and trust each other from an in-person or voice-verified introduction. So we didn't install Signal. We borrowed the idea (the same "nobody but the two of you can read this" guarantee) and built it directly into the envelope itself, sealed before it ever leaves your house, no matter which road carries it. You get Signal's promise, and you never have to install Signal's app.
The road you already use to text this friend. We covered this one in full on its own page The short version: every messaging company is treated the same, and every invitation is locked before Messages ever sees it. This is the one road on this page that's actually working today.
It's tempting. Google Calendar already knows how to send an invite and collect a yes/no/maybe. But that's exactly the problem: Google Calendar's whole reason for existing is knowing your schedule, and the promise this whole system makes is that your calendar never leaves your house. Only a plain "yes" or "how about 10 instead?" ever travels. Routing invitations through Google would mean handing your comings and goings to a company whose business is knowing them. So we said no to using it as the road.
Where it might still show up: once you and your friend have already agreed a time (the negotiating is over, nothing private is left to protect), either of you could drop that one confirmed plan into your own Google Calendar, the same way you'd drag any plan into your calendar app today. That's a future idea. Nothing has been built.
Same reasoning as Google's calendar. The calendar itself must never leave the house. Where Apple's version is a little different: a family or circle could run its own private calendar server, with no big company involved. That changes who you'd be trusting. The underlying rule still holds: a negotiation shouldn't travel through any calendar service at all. What Apple's calendar tooling is well suited for is the very last step: sliding a confirmed plan onto your own iPhone or Mac calendar automatically, the moment it's agreed, the way apps that are allowed onto your phone's calendar already can. That last-step idea is a strong candidate for later. Nothing has been built.
BlueSky the social app runs on something called the AT Protocol, and two of its ideas rhyme with how this whole system already works: each person owns a portable identity nobody else can take away from them, and every change to your own data is written into a signed, tamper-evident history, which is exactly how your own archive already keeps its own record straight.
But the part of AT Protocol that makes BlueSky work as a public social network (a constant public broadcast of everyone's activity to anyone listening) is the exact opposite of what this system promises: known people only. No public feed. No stranger's search. Using it as a road for private walk invitations would mean either building something that looks nothing like BlueSky anymore, or accepting a public broadcast this system was built to refuse. So: an interesting idea for a much later, much narrower question (like whether identities could someday be portable the way theirs are). It is not a road for carrying private invitations.
Every road on this page got the same three questions, in the same order. We made no exception for a famous name or a beautiful app. Two roads passed and became real: a private shared folder, and a text message. The others are either the wrong tool for carrying a private invitation specifically (Google and Apple's calendars, wonderful at other things), a good idea whose expensive machinery we didn't need to build ourselves (Signal), or an interesting idea aimed at a completely different question (BlueSky's protocol, which is about identity).
Written July 12, 2026, as a survey. Nothing was built that day. Two roads are real today: the private shared folder (fully built and tested) and the text message (built and tested, not yet connected to a phone's Messages app). The other three roads on this page are ideas we looked at closely and wrote down our reasoning for. None of them is a design waiting for a build session. None of them is a promise.
This page will say so, dated, when any of that changes. Same as every page here.
See a problem, or something that worries you? On the main site: Write to us → "feedback," or Write to us → "security" for good-faith lock-testing — welcomed, credited, and protected by a safe harbor written into our Terms, §15.
Want to build it with us? Apply → "build," and read the technical page — it shows exactly what's enforced by tests today, and what's still an idea.
Just following along? The "New in this place" board on the home page announces every change, dated.