hachiflow.com
招待

招待リンクはなぜ死ぬのか、そしてなぜそれが機能なのか

招待リンクは、データベースの行ではなく、30 日の時計を持つ署名済みコードです。期限で失効し、ワークスペースの署名アイデンティティがローテーションすれば即座に死にます。その両方への恒久的な対策が、自分で管理する固定 URL です。

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 公開する固定 URL 招待 = 署名済みコード、30 日 アイデンティティのローテーション 発行済みの招待がすべて失効 現行の招待 時間 →
招待は時計を持つ署名済みコードです。署名アイデンティティをローテーションすると発行済みの招待は一斉に失効しますが、公開した URL は常に現行の招待を指すため生き残ります。

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.

← フィールドノート一覧