docs(design): how libID would integrate with ENS

[SupremaLex]

A design proposal for projecting IdentityNames bindings into ENS, so a name in
an X bio resolves in a wallet that has never heard of libID. Nothing here is
built, and it defines no ASM-*/SP-*/REQ-* identifiers — the parts carrying
trust assumptions would graduate into specs/ if this is approved.

The load-bearing finding

We would not be issuing subnames. We would be projecting state that already
exists: resolveHandle(platformId, handle) already answers the question an ENS
resolver asks. So a name needs no registry entry, no NFT, no mint and no storage
of its own — it is a view.

The cost is one small resolver contract on mainnet, one stateless read-only
gateway, and nothing on the write path: IdentityNames is untouched. A rename
or a wallet move then follows the binding with no ENS transaction at all.

Coinbase runs the same shape for eleven million *.cb.id names.

What the document decides

• Namespace — handles.link, the DNS domain we already own, imported
  on-chain via DNSRegistrar. .eth is rejected: an annual renewal whose expiry
  would kill every name beneath it. Gasless DNSSEC (ENSIP-17) cannot serve
  subnames at all.
• Name shape — <handle>.<platform>[.<chain>].handles.link. The chain is a
  label of the hierarchy; omitting it means "answer by the caller's coin type".
• Cross-chain — ENSIP-11 coin types say which chain's contract to read, and
  answering only for chains that hold a binding makes wrong-chain delivery
  impossible rather than unlikely.
• Handle mapping — specified, not described. ENSIP-15 is not UTS-46; on our
  lowercase ASCII exactly two of its rules can fire. GitHub passes unchanged, X
  goes through an injective _ → - substitution that loses only a doubled
  underscore at the third and fourth characters, Gmail splits at its dots, and an
  _id-marked name derived from idNode covers everything that refuses.
• Trust — the gateway signs, and that is the model rather than a stage toward
  something else. The cost is stated: a compromised signing key can answer with
  any address. Three keys are kept apart — the DNS credentials that own the
  namespace, the owner key that sets the resolver, and the signer on the gateway
  host.

Two things worth reading closely

Resolution is three steps and the address comes from the third. The revert
carries the endpoint, the gateway returns a signed blob, and a second eth_call
into the resolver's callback turns it into an address. Both calls are eth_call;
no transaction, no gas.

The ENS name follows the DNS domain. A later valid DNSSEC proof overwrites
the owner, so whoever holds the registrar account and the DNSSEC keys holds the
namespace. Section 0 writes out the import: the _ens TXT record and every
argument of proveAndClaimWithResolver.

Still open

Gateway policy when chains disagree; whether _ → - is surfaced in our own UI;
and name depth, which is the first thing to measure after the import because
depth is decided by the client rather than by the specification.