HN Debrief

.self: A new top-level domain designed to support self-hosting

  • Infrastructure
  • Privacy
  • Security
  • Open Source
  • Developer Tools

The post is a vision document for .self, a proposed generic top-level domain that would be run as a public good for self-hosters. The pitch is simple on paper: one person gets one free subdomain under .self, no parking or resale, and supporting services around it like easier DNS, TLS certificates, maybe shared mail, and client software that makes homelab publishing less painful. The operator says .self does not exist yet. They are applying in the current ICANN round and qualified for fee relief through the Applicant Support Program.

If you care about user-owned identity or self-hosting, the interesting part is not the branding but the policy and operations stack: proof-of-personhood, abuse handling, mail reputation, and ICANN costs. Treat this as an early concept until it ships on an existing domain or shows concrete answers on funding, verification, and deliverability.

Discussion mood

Interested but skeptical. People like the broad goal of easier self-hosting and person-owned identity, but they think the proposal is undercooked on verification, abuse prevention, funding, email reputation, and the basic question of why this must be a new TLD.

Key insights

  1. 01

    Registry compliance dominates the cost

    The expensive part is not serving DNS records. It is becoming and staying a real registry. ICANN application fees, contractual obligations, EPP and RDAP infrastructure, and outsourced registry service provider costs can push this into hundreds of thousands per year. Qualifying for ICANN's Applicant Support Program helps with the application fee, but it does not erase the ongoing compliance and operations burden.

    Do not model this like a cheap DNS hobby project. If you are evaluating similar ideas, budget for governance and compliance first, then treat the technical stack as the easier half.

      Attribution:
    • greyface- #1
    • madsushi #1
    • HumanCCF #1
  2. 02

    Proof of personhood is the actual product

    The viability of .self hangs on identity verification, not on domain plumbing. Comments pointed out that passport or NFC-based schemes miss large parts of the world and can quietly become trust-me black boxes if users cannot independently verify the government signatures the system claims to check. The organizer saying they may start with credit cards underscored that the central mechanism is still undecided.

    If you want one-human-one-name systems, test inclusion and auditability before you talk about scale. A weak verification method will either lock out legitimate users or fail to stop abuse, and both outcomes poison the namespace.

      Attribution:
    • SahAssar #1
    • teraflop #1
    • HumanCCF #1
  3. 03

    Build the service before chasing the root

    Several readers argued that the useful parts of the idea already fit inside a normal domain. Free subdomains, automatic DNS, tunnels, TLS setup, and even migration later are all possible without winning a TLD. Going after ICANN first makes the project look like it chose the hardest dependency before proving user demand or operational competence. The organizer's timing argument is real, but it does not answer the product-risk objection.

    For infrastructure startups, a pilot on existing rails buys credibility fast. If a future regulatory window matters, apply anyway, but ship the user-facing service in parallel and make that the thing people can judge.

      Attribution:
    • quotemstr #1
    • akerl_ #1 #2
    • HumanCCF #1
  4. 04

    Cheap namespaces inherit a trust problem

    The warning from .tk was concrete. Once a free namespace becomes known for scams and throwaway sites, schools, security tools, and big platforms start blocking it wholesale. A one-person rule does not solve that on its own because scammers can obtain more identities than honest users expect, especially if the reward is a memorable free domain. Reputation loss at the TLD level can become irreversible.

    If you run a low-cost or free namespace, abuse controls have to be aggressive from day one. Recovery after the suffix gets a bad reputation is far harder than preventing that reputation in the first place.

      Attribution:
    • goldenarm #1
    • HumanCCF #1
    • applfanboysbgon #1
    • hananova #1
  5. 05

    Privacy-preserving identity could widen the appeal

    One constructive path was to separate verified and unverified registrations while still enforcing one-person-one-domain with zero-knowledge proofs. The Microsoft Vega example and the follow-up on general-purpose zero-knowledge virtual machines framed identity as something that can gate uniqueness without forcing the registry to know exactly who a person is. That moves the project from crude KYC toward a more credible privacy story.

    If this space interests you, watch for designs that prove uniqueness without centralizing personal data. A privacy-preserving registration flow would make a personal namespace far easier to defend to security-minded users.

      Attribution:
    • vessenes #1
    • quotemstr #1

Against the grain

  1. 01

    The DNS side is not the scary part

    The back-of-the-envelope case here is that authoritative DNS traffic for a million mostly personal domains is manageable. Recursive resolvers cache aggressively, record sizes are tiny, and the monthly bandwidth is not outrageous for a small nonprofit. That does not solve ICANN bureaucracy or abuse, but it does cut against the idea that the serving infrastructure itself is prohibitively expensive.

    Separate technical hosting costs from registry-business costs when assessing projects like this. The bandwidth and nameserver footprint may be modest even when the surrounding institution is not.

      Attribution:
    • AnthonyMouse #1
  2. 02

    Owning the suffix can simplify the stack

    The organizer's defense of the TLD is that self-hosting is easier when the project controls the whole trust boundary. A root-level namespace avoids extra labels, avoids dependence on another registrar's policies, and makes bundled services like certificates, mail, and client integrations cleaner to reason about. If the goal is a full ecosystem and not just free subdomains, that architectural preference is at least coherent.

    If you are designing a tightly integrated identity or hosting system, namespace control can reduce long-term coupling. Just be honest that this is an architectural convenience, not yet proof of user value.

In plain english

DNS
Domain Name System, the internet service that translates human-readable names into network addresses and related records.
EPP
Extensible Provisioning Protocol, the standard protocol registries and registrars use to create and manage domain registrations.
ICANN
Internet Corporation for Assigned Names and Numbers, the organization that coordinates the global domain name system and approves new top-level domains.
KYC
Know Your Customer, identity verification processes commonly used by financial and online service providers.
Microsoft Vega
A Microsoft Research identity project discussed in the comments that uses privacy-preserving cryptography for digital identity attestations.
NFC
Near Field Communication, a short-range wireless technology used by phones and modern identity documents for chip-based reading.
RDAP
Registration Data Access Protocol, a standard way to query information about domain registrations and related internet resources.
TLD
Top-level domain, the last part of a domain name such as .com or .org.
TLS
Transport Layer Security, the standard protocol used to encrypt web traffic such as HTTPS.

Reference links

Identity and zero-knowledge systems

ICANN and registry operations

Identity verification tools

  • Passport Reader
    Mentioned as an example of NFC passport and ID verification infrastructure.
  • Passport Reader coverage map
    Used to argue that NFC document verification has limited global coverage.
  • Only Human Hub
    Raised as an example of a service trying to verify that a registrant is a real person.

Private and local namespace references

Related services and examples

  • NetBird
    Suggested as a practical current tool for reaching homelab devices without manual firewall work.
  • Neocities
    Mentioned as the modern equivalent of Geocities for personal sites.

Background and side references