RFC: Add .rings self-authenticating service names over Chord

[rings-auto-reviewer]

Context

We want Rings to support a Chord-backed name system under .rings, with semantics closer to .onion than public DNS. The .rings suffix should be a Rings overlay pseudo-TLD intercepted by Rings resolvers, not a dependency on the public DNS root.

The repository already has the substrate pieces:

• DHT storage can store and fetch topic-addressed EntryKind::Data values.
• registerService / lookupService currently provide a weak name -> Vec<DID string> mapping.
• online_nodes and onion_exits already demonstrate signed descriptor registries with heartbeat and expiry.
• Onion route construction can select live relays and exits, but it does not yet resolve a hidden service name into an authenticated service descriptor.

The missing layer is an authenticated Rings name protocol.

Goal

Add an RFC and implementation plan for .rings self-authenticating service names over Chord.

The MVP should treat .rings as an overlay namespace:

<self-authenticating-label>.rings
  -> DHT fetch signed RingsNameRecord
  -> verify owner/signature/expiry/sequence/network
  -> resolve target service descriptor
  -> build route/connect through the Rings onion/overlay data plane

Proposed MVP scope

• Define .rings as a pseudo-TLD handled only by Rings resolver code.
• Define canonicalization and validation for .rings names.
• Prefer self-authenticating labels for the first version, derived from the service owner key or service key material.
• Add a signed RingsNameRecordV1 schema with at least:
  • schema version
  • canonical .rings name
  • owner verification public key
  • target DID and/or hidden-service introduction points
  • session public key or service encryption key material needed by route setup
  • service name and transport metadata
  • network_id
  • monotonic seq
  • ttl / expires_at_ms
  • signature over the canonical record body
• Store records under a domain-separated DHT key, for example:

rings-name:v1:<network_id>:<canonical .rings name>

• Avoid global registry scans for name resolution. A resolver should fetch the DHT key for the requested name directly.
• Add resolver APIs for publish and resolve, separate from the current weak registerService / lookupService interface.
• Add cache and negative-cache behavior bounded by record TTL.
• Integrate .rings resolution with onion route construction so a client can connect to the resolved service without treating it as a public Internet exit target.
• Add browser/native API surfaces so *.rings can be intercepted by the local resolver or proxy path.

Security and correctness requirements

• A DHT storage owner must not be trusted as the authority for a name.
• A resolver must reject records with invalid signatures, wrong network_id, expired timestamps, stale sequence numbers, or names that do not bind to the advertised owner key.
• Record updates must be monotonic per owner/name via seq or an equivalent conflict rule.
• Tombstone/revocation semantics must be explicit.
• Multiple replicas returned from Chord storage must converge to a deterministic accepted record set.
• The design should document privacy limitations of direct DHT name lookup and leave room for blinded descriptor keys or onion-routed lookup later.

Non-goals for the first issue

• Public DNS integration or ICANN TLD registration.
• Human-readable name allocation such as alice.rings.
• Auctions, registrars, transfer markets, or global uniqueness policy for human names.
• Reusing registerService / lookupService as-is for trusted name resolution.
• Requiring a full Tor-compatible hidden-service protocol in the first patch.

Human-readable aliases can be a later layer, for example:

alice.rings -> <self-authenticating-label>.rings

That requires separate ownership, conflict, renewal, and recovery rules and should not block the self-authenticating MVP.

Acceptance criteria

• There is a concrete .rings RFC/design document or issue-linked design section covering name grammar, record schema, DHT keying, verification, updates, expiry, revocation, resolver API, and onion integration.
• The implementation plan identifies the repo surfaces that need changes, including DHT storage API usage, node processor APIs, RPC/browser/native interfaces, and onion route construction.
• The MVP explicitly distinguishes self-authenticating .rings names from future human-readable aliases.
• Tests are planned for canonicalization, signature verification, expired/stale records, wrong-network records, conflicting replicas, and resolver cache behavior.