hachiflow.com
Invites

Why invite links die, and why that is a feature

An invite link is a signed code on a 30 day clock, not a row in a database. It expires, it dies instantly when the workspace's signing identity rotates, and the durable fix for both is a stable URL you control.

The link carries everything

An invite into a Buzz workspace looks like any invite link, but the relay behind it keeps no invite table. The code in the link is an HMAC: a signature minted with a key derived from the relay's own identity. When someone knocks with the code, the relay recomputes the signature and compares. Match: come in. No match: not a code it issued.

Storing nothing per invite is the elegant part. There is nothing to leak, nothing to clean up, and nothing to drift out of sync, because an invite's validity is a property of the math, not of a stored record.

Everything it carries includes a clock

The signed code embeds an expiry, and ours cap at 30 days. Until that moment, anyone holding the link can join. That is not a flaw to engineer away; it is what an invite link is. A link that can be forwarded is a door you cannot see, so the only safe shape is a short life and an easy rotation.

Treat an invite like a visitor badge, not a keycard: date-stamped, freely handed over the counter, and worthless next month.

Rotation is a kill switch you already own

Because every invite is signed with a key derived from the relay's identity, rotating that identity invalidates every outstanding invite at once. No list to purge, no revocation table: the old signatures simply stop verifying. If a link escapes somewhere you regret, one rotation closes every open door, instantly, for free.

hachiflow.com/hive the stable URL you publish an invite: a signed code, 30 days identity rotates every open invite dies the current invite time →
Invites are signed codes on a clock. Rotating the signing identity kills every outstanding invite at once; the published URL survives, because it points at whichever invite is current.

Publish a pointer, not the key

The practical consequence: never put the invite itself anywhere durable. A homepage, a README, a bio, a printed slide all outlive any 30 day code. Publish a stable URL you control, and have it redirect to the current invite. Ours is hachiflow.com/hive: the address on our homepage never changes, and what it points at rotates behind it.

It is the same discipline as never hardcoding a credential: the durable surface carries a name, and the name resolves to whatever is currently valid.

We learned this on our own homepage

The day we put our own invite on our homepage, the invite behind the link was already dead. The workspace's signing identity had rotated a few days earlier, after that invite was minted, and everything looked fine until someone pressed the button. Because the homepage published the stable URL rather than the invite itself, the fix was updating one pointer to a freshly minted invite: not a copy change, not a website deploy, one line. That afternoon is the whole argument for this pattern, made by us, at our own expense.

← All field notes