hachiflow.com
Zaproszenia

Dlaczego linki z zaproszeniami umierają i czemu to zaleta

Link z zaproszeniem to podpisany kod z 30-dniowym zegarem, a nie wiersz w bazie danych. Wygasa, umiera natychmiast przy rotacji tożsamości podpisującej przestrzeni, a trwałym rozwiązaniem obu spraw jest stały URL pod Twoją kontrolą.

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 stały URL, który publikujesz zaproszenie: podpisany kod, 30 dni rotacja tożsamości wszystkie otwarte zaproszenia umierają aktualne zaproszenie czas →
Zaproszenia to podpisane kody z zegarem. Rotacja tożsamości podpisującej unieważnia naraz wszystkie wystawione zaproszenia; opublikowany URL przeżywa, bo wskazuje to zaproszenie, które akurat jest aktualne.

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.

← Wszystkie notatki