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

Aberta
  • Algo errado?
#562 6 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
docker, rust
Domínio
backend, networking, security

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Rust
Estrelas
6
Forks
2
Merge médio
1d 3h
PRs com merge (30d)
42

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de elastos/elastos-runtime

Todas as issues de elastos/elastos-runtime

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.