Domain capsule: offer names like you.pc2.net peer to peer, invite-only, each pointing at the person's Home, site or app

Ouverte
  • Quelque chose ne va pas ?
#562 6 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
docker, rust
Domaine
backend, networking, security

Piste de recherche

Read the existing tunnel-provider proof of concept in capsules/tunnel-provider/src/main.rs, especially lines 143 and 316, then review the referenced service offers, grants, Carrier, and site binding flows. The issue describes a multi-part design involving public routing, DNS credentials, privacy, invites, and Home security switches; it does not define a bounded first implementation or acceptance criteria.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Idea and decisions from Anders (8 Nov). The old PC2 gave free ela.city names. Now:

Decided

  • A generic domain capsule. Any owner can add a domain to it, the way an owner adds an API key for hosted AI (#85): the domain plus a DNS credential for that domain stay in the owner's Home.
  • Offered peer to peer. The owner runs it on their own Home, manages it, and offers it as a service (elastos.service.offer/v1) to people over Carrier. Anders will offer pc2.net this way; anyone else can offer their own domain.
  • Invite-only. An invite is a grant from the offering Home to a person's DID. Each person who has a name can pass on 3 invites (the owner sets the number).
  • The person chooses what their name shows. Default: their Home. Or a published site (localhost://MyWebSite, e.g. a blog), a specific app or capsule (e.g. a shop), or a redirect to a URL. They can change it at any time in Home.
  • Privacy (option B). Traffic for anders.pc2.net is passed through by TLS SNI to that person's Home over Carrier without being decrypted. The Home holds its own certificate (issued with a DNS challenge the domain capsule answers). The offering Home and no third party can read the traffic. Fits #217 and "the Runtime is the only authority". Cloudflare tunnels (option A, the tunnel-provider proof of concept) are not the product.

One constraint to plan for

The Home that offers the domain must be reachable from the internet on port 443, because DNS for *.pc2.net points at it. A Mac at home behind a router usually is not. So the offering Home runs on a small server (a cloud VM running ElastOS, managed by Anders, separate from the release seed), while the people's Homes, including Anders's Mac, only keep an outbound Carrier connection to it. This is the same shape as ela.city becoming an ElastOS node (#388).

Starting point that exists

  • tunnel-provider capsule: cloudflared tunnel --url <target>, random *.trycloudflare.com address (capsules/tunnel-provider/src/main.rs:143, :316). Proof of concept only.
  • Sites (localhost://MyWebSite, signed site heads, elastos site bind-domain, docs/SITES.md), service offers and grants (hosted model offers), Carrier.

Security decisions before any code (Irzhy)

  • Reaching a Home from the internet is new attack surface: the Runtime exposes nothing unless the owner turns it on (#183, #173). One explicit switch per Home, off by default, shown in System, revocable.
  • Passkeys: Home derives its passkey relying party from the request host (derive_rp(headers), used in auth_gateway.rs:753), so a passkey made at localhost does not work at anders.pc2.net; the person adds a passkey for the new address, or Home learns related origins.
  • Home's front door must accept the name (gateway_allowed_hosts, gateway_frontdoor.rs:26) and rate-limit sign-in from the public side.
  • The offering Home holds a DNS credential for the whole domain: scope it to one zone, keep it in the capsule's sealed storage, never show it to apps.
  • Abuse: withdrawing a name, the invite tree, and a block list (as in #525).

Open questions

  • pc2.net DNS (Google Cloud DNS, ns-cloud-a1..a3.googledomains.com; apex 8.219.176.228; https://pc2.net does not answer): Rong Chen controls it, Anders may have access.
  • Which server hosts the offering Home; pricing for always-on hosting and custom names later.

Related: #85, #525, #388, #183, #173, #217, #518.

Acceptance record

  • Candidate: local feat/562-domain-capsule at 454077cb8, based on 30b166b05. The branch remains local.
  • Exercised checks: six focused Carrier and domain tests pass at the current head, including the real two-Home TLS journey and the restored default Carrier discovery case. At the preceding candidate, domain-provider passed 8 tests, site-provider passed 3, behaviour passed 2,202, product-data passed 106, and formatting, Clippy and the source gate passed. The source gate skipped two Linux pidfd ownership checks on macOS. The first full server lib run had 3,317 passes, one mDNS scope failure and 27 existing ignored tests; that failure is fixed and its focused test passes. The current full lib rerun and queued checks were stopped at the required disk reserve. The server bin suite remains unrun.
  • Review links: independent development and adversarial source PASS at ecb061f94. The final Carrier scope correction still needs a current-head review.
  • Installed release evidence: current evidence comes from isolated test Homes and a test certificate. Installed release acceptance is pending.
  • Remaining gate: confirm the transient test-space budget, then finish current-head full server lib/bin tests, repeat the fast, formatting and Clippy gates, and obtain current-head reviews. Main owns the later full Linux check and CI/publication. DNS activation, holder ACME HTTP-01 with issuance pacing, System controls, new-origin passkeys and installed user journeys remain the next slices in the design.
  • Next owner: Anders/Main for the resource review and resumed local verification; Main for later publication through the queue.
Langage dominant
Rust
Étoiles
6
Forks
2
Merge moyen
1 j 3 h
PR mergées (30 j)
42

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de elastos/elastos-runtime

Toutes les issues de elastos/elastos-runtime

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.