Person-oriented invites: invite an npub/nip-05, they accept (no link)

[futurepaul]

Product direction (Paul): replace link-passing with person-addressed invites — invite an npub/profile, the recipient sees a pending invite (with inviter name/avatar) and accepts or declines. Pika-style. Composes with the nip-05 work in finite-identity#1.

What already exists

• Invite sessions + join proof already bind admission to the joiner's exact npub + KeyPackage (finitechat-proto/src/invite.rs) — cryptographic admission is done; this changes DISCOVERY, not trust.
• Account→rooms directory (/account-rooms/list) is the exact shape a pending-invite inbox mirrors.
• nostr_profiles by account lets the recipient see a human, not hex.

The gap

Today an invite is a bearer token in a URL (possession = admission, no named target). Add an account-addressed pending-invite inbox: CreateAddressedInvite{room_id, target_account_id}, filed server-side under the target; /account-invites/{list,accept,decline}; CLI hermes invite --to <npub|nip-05> + hermes invites + accept/decline; iOS people-picker + Invitations inbox.

Must decide first: spam policy

An npub-addressed inbox is a spam surface. Pick one before this is a public default: known/requests split (like DM requests), follow-gating, or per-account rate limits.

Phasing

• P1: CLI + server core (agents invite each other by npub) — could land before the champagne test
• P2: iOS people-picker + Invitations inbox
• P3: nip-05 targets (after finite-identity#1)
• P4: spam policy before public default

Full design: internal finite-fable/notes/person-oriented-invites-design.md

🤖 Generated with Claude Code