Design: generic invite delegation — iroh tickets and links for worlds and groups

Extends #2146 (program sessions / routing). Cross-links: #5684 (identity / login / delegation), #835 (scope bits + session-frame wiring), #5675 (discovery — invites are the private counterpart of discovery).

The ruling this implements (Drew, 2026-11-04)

• Anonymous public program sessions are the norm: a participant with an iroh ID (IRID) who was not specifically invited can join public sessions. Anonymous does not mean no token — an iroh ID is the minimum identity, always.
• Both modes get built: public-by-default AND invite-gating, because we need a way to invite-gate. Gating is a property a world/group can choose, not the platform's default posture.

The model: an invite is a delegation object

An invite is a signed, self-contained delegation from an inviter to whoever redeems it:

• Target: a world, or a group — joining the group grants access to everything the group fronts (a group can front a set of worlds; one redemption, many worlds).
• Inviter: an IRID, plus the authority source that makes this invite valid (see below).
• Terms: uses (one-time / N uses / bearer-link until revoked), expiry, and optional constraints (role granted on join — tying into id(world): F14.6 builder and moderator authority through session frames (F12.3 remainder) #835's scope bits; the invite grants at most what its terms say).
• Carriers — one object, three envelopes: an iroh ticket containing the details (iroh-native is the primary form), a plain URL, and an ID protocol URL. The carrier differs; the delegation object inside is identical.

Redemption = exercising a delegation

• Accepting an invite is recorded as an action delegated from the inviter: the join is journaled with its full provenance (who invited, under which authority source, which ticket/link, when).
• One-time tickets self-invalidate on redemption. Link invites are bearer capabilities — anyone holding the link can join, like a Discord invite link but more capable: scoped to a target and role, expiring, use-counted, and revocable (revoking a link kills future redemptions; already-redeemed memberships are separate state, removed by group/world operations, not by invite revocation).
• Redemption must verify offline-capable: the ticket is signed, so a world/group node can validate it against the inviter's key and the authority chain without a home server round-trip.

Where invite power comes from

• Open delegation: a world created with open delegation lets participants invite others (the public-norm case still uses invites for its gated rooms/groups).
• Moderator grant: moderators hold invite power and can extend it (bounded — an inviter can never grant more than their own authority; chain rules per design(id): identity, login & delegation — simplicity-first key custody, security-code recovery, and pseudo-login identities #5684's delegation model).
• Invite power is itself a scope (see id(world): F14.6 builder and moderator authority through session frames (F12.3 remainder) #835): grantable, revocable, auditable — not an ambient property of being present.

Open questions for the design pass

• Ticket encoding: postcard per id: design: Wire format & transport adapters — postcard schema, non-UDP carriers, relays/proxies #5674's wire format work; what's the size budget for a ticket that must survive being pasted into chat?
• Delegation depth: can a redeemer re-invite (chain length caps)? Under open delegation presumably yes within scope; under moderator grant?
• Link leakage: a bearer link posted publicly is indistinguishable from intended distribution — rotation UX and per-link join auditing are the mitigations; anything stronger?
• Group-fronted worlds added after a redemption: does an existing group member automatically gain the new world (group = live set) or is access snapshotted at join? (Recommendation to evaluate: live set — that's the point of fronting — with per-world sensitivity filters from id: design: Querying local and remote ID servers v1 #5675 still applying.)

Non-goals

• No zero-identity access paths, ever — every join, public or gated, is an IRID acting.
• No central invite registry service; tickets are self-verifying objects.