Addressing and discovery: contact exchange with a static-only origin; the user@host question; per-user published content

[lannbot]

Decide how users find and verify each other when the trusted origin is static-only. See NOTES.md — Addressing and discovery.

user@host addressing keeps trying to sneak a dynamic lookup back onto the origin. Options on the table:

• Pure out-of-band contact exchange (QR / links through the sharing layer): honest, static-clean, changes the product.
• Per-user static records (.well-known JSON, DNS TXT): introduces a third origin class — live-ish, user-controlled, untrusted — which must never share the framework origin if it exists at all, and which complicates byte-identical release monitoring and the accountless-multi-tenancy property.
• Nothing in v1: contact exchange is bootstrap-by-invitation only.

Related pieces:

• The static share-link viewer (reader page + ciphertext from a storage backend + key in the URL fragment) covers "share with a non-user" without discovery infrastructure.
• Whether the home origin ever serves per-user content at all (threat-model issue) — if yes, the third origin class needs its own contract; if never, record that as the invariant's sharp edge.

Open sub-questions:

• Is human-memorable addressing a product requirement, or is invitation-graph growth acceptable?
• Invitation link anatomy (what a link discloses to the network path and to the recipient before verification).
• Interaction with the identity sigchain: what an address resolves to (a device list? a rendezvous hint?).