hachiflow.com
Invitaciones

Por qué los enlaces de invitación mueren, y por qué eso es una ventaja

Un enlace de invitación es un código firmado con un reloj de 30 días, no una fila en una base de datos. Caduca, muere al instante cuando rota la identidad de firma del espacio, y el arreglo duradero para ambas cosas es una URL estable bajo tu 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 la URL estable que publicas una invitación: código firmado, 30 días rota la identidad toda invitación abierta muere la invitación vigente tiempo →
Las invitaciones son códigos firmados con reloj. Rotar la identidad de firma mata de golpe todas las invitaciones emitidas; la URL publicada sobrevive, porque apunta a la invitación que esté vigente.

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.

← Todas las notas