A protocol for asynchronous notification between independent peers. No servers to maintain. No accounts to create. No one in the middle. Just two peers and a pull.
Status
Draft 0.1 — Protocol Specification
Model
Asynchronous, consent-based, decentralised
How It Works
Think of it like post, not a phone call.
Telephone requires both parties to pick up at the same time. Post doesn't. PING works like post: you leave a note saying a parcel exists. They collect it when they choose.
1
A note in the letterbox
One peer writes content and sends a lightweight ping — just a notification that something exists. No content is attached. Think of it as a card that says "there's something here for you."
→
2
The receiver decides
The other peer sees the notification and chooses whether to collect. They can pull the content, ignore it, or never respond at all. Silence is always an option.
→
3
Content moves once
If the receiver decides to collect, the content travels for the first and only time — pulled by them, not pushed by the sender. Once pulled, delivery is complete.
At a Glance
What you don't need.
No accounts
Identity is an address you control
No always-on server
Both peers just need to be online eventually
No intermediaries
Nothing between sender and receiver
No expiry
Tolerates gaps of hours, days, or longer
The entire protocol is four states. Content never travels inside a ping — only the notification does. The receiver always chooses whether to pull. The two parties only need to briefly overlap in online status to advanced states.
Why
Neither existing model quite fits.
Email solved asynchronous delivery in 1971, but decades of accumulated infrastructure — SMTP, DKIM, SPF, spam filtering — have made self-hosting practically inaccessible. Federation protocols like ActivityPub require servers to talk to servers, which ties your identity to a platform and hands moderation authority to whoever runs it.
PING takes a different approach — closer to post than to telephony. The sender prepares a notification and posts it. The receiver collects when they choose. No intermediary holds authority over the exchange.
How it behaves
The protocol in five scenarios.
Every meaningful path through the protocol, animated. Block, ignore, and offline look identical from the sender's side — the distinction lives only with the receiver.
Ping travels to the receiver. The receiver decides to pull. Content moves once — pulled, not pushed. Delivery confirmed.
The receiver's endpoint is unreachable. Pings can't land. The sender retries on a backoff schedule until the receiver comes back.
The ping delivers fine. The receiver tries to pull, but the sender's outbox is unreachable. It retries until the sender comes back.
The ping lands. The receiver sees it and chooses not to pull. No response is sent. The sender cannot tell the difference.
The ping arrives and is dropped before any state is created. To the sender, this looks identical to offline.
Applications
One primitive, many systems.
PING doesn't interpret payload content. Any interaction that fits the shape "I have something for you, collect it when ready" can be built on it.
A reader leaves a question for a blog author.
The author pulls it when they choose, responds on their own terms. No inbox they didn't ask for.
payload: ask
Someone replies to your post from their own blog.
You're notified that a reply exists elsewhere. The thread is distributed, not centralised.
payload: reply
Your content is reblogged downstream.
You learn it's been shared. The chain is traceable without federation.
payload: reblog
A blog subscribes to your feed.
They inform you they're following. No central registry of relationships needed.
payload: follow
A self-hosted instance learns an update is available.
Pull when convenient, not when pushed. Software updates on the receiver's schedule.
payload: update
Anything that fits the shape.
Document changes. Game invitations. Event coordination. The payload type is opaque to the protocol.
payload: any
Access & Reception
You decide who can reach you.
Every ping endpoint is tiered. The tier determines who may ping, whether the sender's identity is visible, and how the payload is handled. No configuration is mandatory — and taking down an endpoint entirely is always valid.
Public
Anyone may ping. Sender identity visible.
User
Authenticated senders only. Identity visible.
Private
Receiver-only. Payload is end-to-end encrypted.
Anonymous
Routed via proxy. Sender identity stripped before arrival.
Masks
Masks are temporary subdomains that route to your primary inbox. They accept pings under a different address — one that never reveals your main identity. Revoke one by removing the subdomain: pending pings are silently abandoned, future ones find nothing, and your inbox continues unchanged.
Pings arrive at the mask and route to your inbox. Remove the subdomain — the mask disappears, your inbox does not.
Event-scoped
Opens for the event. Closes after.
The address is the event. Revoked when the window closes.
rsvp.you.instance/ping
Persona-scoped
A face with no identity behind it.
Never resolves to your primary endpoint. Retire the persona without a trace.
alias.you.instance/ping
Single-use
Accepts one ping, then closes.
Auto-revokes on first delivery. The address exists only long enough to receive once.
· · ·
Best Practices
Design with the grain.
The protocol's constraints are intentional. Work with them, not around them.
Never send content in the ping
Simplicity
The ping carries metadata only: origin, type, optional size hint. Content stays on the sender's infrastructure until the receiver explicitly pulls. That boundary is what gives the receiver genuine consent.
Keep the endpoint dumb
Simplicity
A ping endpoint receives pings. It doesn't parse content, doesn't run logic, doesn't make decisions. Decisions happen when the owner reviews their inbox — not at the protocol level.
Use masks for temporary reception
Privacy
Message masks give you disposable endpoints — event-scoped, persona-scoped, or single-use. Revocation is as simple as taking down the subdomain.
Encrypt at the content layer
Privacy
PING is transport-agnostic. If privacy matters, encrypt the payload before it enters the protocol. The ping carries ciphertext; only the intended recipient has the key.
Separate your control channels
Resilience
Don't route administrative commands through the same endpoints that receive pings. A dedicated panic channel — narrow, separate, dumb — lets you shut things down even when the main system is compromised.
Retry with backoff, not aggression
Resilience
If the receiver is offline, retry on an exponential schedule. Don't flood. The protocol is asynchronous — latency of hours or days is acceptable by design.
Silence is a valid response
Consent
The receiver never owes the sender a reason for not pulling. The sender cannot distinguish "offline" from "ignored" from "blocked." Don't try to close this gap — the ambiguity is the point.
Treat delivery as final
Consent
Once content is pulled, the receiver owns their copy. PING has no revocation mechanism — not as an oversight, but as a deliberate position. In any system where the receiver controls their own infrastructure, an unsend guarantee is largely theatre. You can remove your copy. You cannot remove theirs.
The recommended stance is the original web mentality: treat anything you send as permanent and potentially public from the moment it leaves your instance. Encryption limits who can read it. Access tiers limit who may request it. But delivery, once complete, is final. Sovereignty cuts both ways — the sender owns their content before delivery, the receiver owns their copy after.