Hyperlinks for conversational objects.

A wyrd is a tweet-length introduction for whatever the sender wants to pass forward — a question, an artifact, a signal, a connection. The same shape carries many kinds of weight.

None of these need a paragraph of explanation when shared. The wyrd is the introduction. As that pattern normalizes, a wyrd URL appearing in an iMessage or a DM becomes recognizable on sight as a high-signal object — passed by someone who thought it was worth your time.

A wyrd is a 300-codepoint, end-to-end-encrypted text block that becomes a shareable URL — a portable, composable, forward-worthy conversational artifact that travels through existing messaging rails (iMessage, Signal, WhatsApp, Slack, email) rather than a native feed or discovery layer.

The URL takes one canonical form:

https://sendwyrd.com/w/{object_handle}#{K_read}

The object handle (a per-wyrd random identifier — not a user handle) is in the path; the read key is in the URL fragment. Browsers don't transmit fragments to servers — so the host stays body-blind. Anyone holding the URL can read the wyrd; whoever you share it with can forward it to whoever they think is relevant.

No accounts. No feed. No archive. Default 90-day TTL — pick shorter, or none. Mosaic quality is the architecture, not an oversight.

The protocol carries text only. Identity, signing, trust, and provenance are either inlined into the body (a name, a Nostr signature) or inherited from the share channel — “Mike sent me this.” Trust rides the rail.

One pragmatic recipient-side note: when a wyrd body contains an external URL, the renderer asks the host to fetch OpenGraph metadata so the link surfaces as a preview card. The host sees the URL but not the wyrd it came from. The wyrd's body is still encrypted end-to-end and never leaves the recipient's browser. This is the cypherpunk- on-content, pragmatic-on-rendering trade we accept in v1.

1. 01

   Every social media platform has lock-in, and every messaging app limits social shareability. What if instead you had messages which you share with people you think are relevant, and they can pass them forward? Depth over breadth.

2. 02

   6 degrees of separation rule-of-thumb. If you embed a request — “I am such-and-such person, and I want to find people who might be interested in such-and-such project” — and your friends pass that to a person who is more likely than them to know someone like that, and it iterates, can the global social graph become faster to traverse?

3. 03

   If you broker introductions for people, can you have a single object — a digital envelope of sorts — that you hand off to the most relevant person, rather than having to orchestrate the connection chain?

4. 04

   Within the tradeoffs of security and reach, can a useful balance be found with capability links where you rely on human judgement as to whether you trust the graph of people downstream?

5. 05

   Can the inherent absence of public blasting of messages be a way to foster relationships focused on intent and action rather than bloviating theatrically about opinions, as if being “right” via group consensus has any material relevance?

6. 06

   The entire internet has been contorted by dopamine and philosophies of constraints built up over millennia, which weakens the individual — and yet the most powerful force will be found in the most capable human network. Rather than receding from the web, can AI revealing what is inhuman allow us to discover the power of human networks collaborating and accumulating resources to their advantage?

The architecture refuses identity. The protocol carries text and capability keys; nothing else. No accounts, no usernames, no logins, no PKI.

Each wyrd has its own random K_origin keypair, derived at m/300'/n' for an incrementing n. Two wyrds composed by the same person produce different K_origin_pub values. The host cannot tell whether two wyrds came from the same author. Counting distinct K_origin_pub values equals counting wyrds, not people.

Possession of the URL is access. Forwarding is the default and the point. There is no friend graph, no follower list, no broadcast surface, no “who” primitive of any kind.

• Body envelope: AES-256-GCM via the Web Crypto API. K_read is 32 bytes derived from your seed via HKDF-SHA256 at compose time, one fresh subkey per wyrd index.
• Author keys: secp256k1; signatures via BIP-340 Schnorr (publish, burn). One keypair per wyrd.
• Replies: ECIES — anyone with the URL encrypts a reply to K_origin_pub; only the author can decrypt. One-shot.
• Seed: BIP-39 mnemonic (12 or 24 words). HD path: m/300'/n' (BIP-43 flat purpose, hardened indices).
• Distribution: K_read lives in the URL fragment. Browsers do not transmit fragments to servers (RFC 3986). The host is body-blind on every request.
• AAD binding: every envelope binds version, handle, expiry, and reply-mode into the AES-GCM authenticated data. Tampering any field fails decryption.

SendWyrd is a mosaic mesh network. Mesh: each wyrd hops across whatever platforms people already use — iMessage to Twitter DM to Slack to email — routed by human judgement, not algorithms. Mosaic: each wyrd is a tile, independently meaningful; lost tiles leave gaps but don't break the wyrds that remain. SendWyrd doesn't own a network and refuses an archive that would hold the whole picture; the assembly lives in the social graph itself.

K_read is HKDF-derived from your seed at the wyrd's index. The URL fragment still carries it — recipients don't need your seed — but mnemonic recovery reconstructs full share URLs for every wyrd you've authored, not just the metadata.

Forward secrecy is enforced by deletion, not by key loss: the default TTL is 90 days, and burn drops the ciphertext from the relay. Once the relay no longer holds the bytes, no key can decrypt them. The mosaic stays mosaic — wyrds fit a moment, then are gone.

Each wyrd has its own random K_origin keypair, so two wyrds by the same person sign with different keys. That is what keeps the host blind to authorship — and it also means authorship can't be proven by reusing one signing key.

To prove authorship after the fact, open /wyrds, find the wyrd, and tap attest authorship. SendWyrd re-derives that wyrd's K_origin_priv from your seed at the original index, signs a canonical message bound to the target handle, and publishes a new permanent wyrd whose body is the three-line attestation:

sendwyrd-attestation/v1 target=<object_handle> sig=<base64url-signature>

Share the attestation URL alongside the original. A renderer opening the attestation fetches the original's K_origin_pub from the host and verifies the signature, surfacing a verification banner. No persistent identity is stored on either side — the seed is the only thing that has to survive.

Most wyrds never need an attestation; forwarding-by-default is the norm and stable provenance is a heavy thing to bind to a forwardable artifact. The mechanism exists for the case where it's the right tool, not for routine composition.

SendWyrd is a relay primitive. It does not handle payments, mint invoices, custody funds, resolve LNURL endpoints, or run any payment infrastructure. Wallets handle payment; SendWyrd hands off.

When a wyrd body contains a payment token, the renderer detects it client-side on the decrypted text and excludes it from the 300-codepoint cap (same treatment as URLs — the cap is for prose, not addresses). Detected forms:

• Lightning: BOLT11 invoices, BOLT12 offers / invoices / invoice-requests, bare LNURL, and the lightning: URI scheme. Lightning addresses (user@domain) are auto-detected when the domain is on a small allowlist of well-known providers; off-list addresses opt in by prefixing with lightning:. Bare email-format strings on off-list domains stay text — no false positives on normal correspondence.
• Bitcoin: native segwit and taproot bech32 / bech32m (bc1 / tb1 / bcrt1), legacy P2PKH / P2SH, and the bitcoin: URI scheme (BIP-21).

Detected tokens render as labelled inline chips with an OS-handler link (bitcoin: / lightning:) and a copy button. Click expands an inline QR code rendered fully in the recipient's browser — no external requests, no third-party QR service, the host never sees the content. The QR is just bytes painted from a string the recipient already has.

From there, the user's wallet takes over via the bitcoin: / lightning: URI handoff at the OS level. SendWyrd never bridges, never connects, never settles.

SendWyrd and Nostr solve different problems in the same neighborhood. Many people will want both.

Nostr is identity-first. Each user has a stable npub/nsec keypair. Events are signed by that stable key, posted to relays, aggregated by clients into feeds. The dominant mode is public broadcast against a durable, signed event log per identity. Nostr is built for censorship-resistant public speech under stable identity.

SendWyrd is capability-first. The URL is the access primitive; the handle is per-wyrd random, addressed by capability rather than pubkey. Each wyrd gets its own K_origin — two wyrds by the same author look unlinked to the host. There is no relay-side feed and no aggregation surface; the relay only resolves a handle to an encrypted envelope. SendWyrd is built for host-blind ephemeral handoff through trust networks.

Concretely:

• Addressing: Nostr — pubkey-addressed signed events. SendWyrd — capability-URL-addressed encrypted envelopes.
• Identity: Nostr — stable npub per person. SendWyrd — fresh per-wyrd K_origin; unlinkable at the relay.
• Distribution: Nostr — relay aggregation, client feeds. SendWyrd — out-of-band forwarding through whatever rails people already use.
• Persistence: Nostr — durable signed event log. SendWyrd — TTL-bounded ciphertext, default 90 days, burnable.

The two compose. A wyrd body can carry a signed Nostr event — the recipient verifies the signature against an npub, and SendWyrd is just transport for an attestation that already stands on its own. Alternatively, the wyrd URL is forwarded by a trusted Nostr identity that signs the act of sending. SendWyrd doesn't model identity; it composes with whatever attestation layer the participants choose to bring.

The compatibility runs deeper than transport. NIP-C6: Capability-URL References (currently an open PR against nostr-protocol/nips, not yet merged) defines a scheme-agnostic event kind for host-blind encrypted artifacts — events that point at a URL whose fragment carries the read key, with the host unable to decrypt. A wyrd is one such artifact; a Nostr client implementing the NIP fetches the envelope, decrypts with the URL fragment, and renders the wyrd inline in the feed with encryption and expiry badges — the same way it renders an image or a long-form post. That is downstream of Nostr being an open client/relay protocol with extensible event kinds. No closed social surface — X, Instagram, Facebook, LinkedIn — lets a third party ship rich inline rendering for an external primitive; URLs unfurl to the platform's own preview card and stop there. SendWyrd composes with Nostr in a way it cannot compose with any other social layer.

• Web: Next.js on Cloudflare Workers (OpenNext); installable PWA.
• API: Hono on Cloudflare Workers.
• Database: Neon Postgres. Stores encrypted envelopes only; no plaintext anywhere on the host.
• API / build on this: /build.
• By: @deltaclimbs.

• The Dawn of Day — Friedrich Nietzsche.
• Symphony No. 8 — Anton Bruckner.