.self Wants a LetsEncrypt TLD. Identity Is the Hard Part.

The Human-Centered Computing Foundation published a one-page pamphlet on 21 June 2026 announcing its bid to operate .self, a new top-level domain whose pitch is that every adult on Earth is entitled to a free subdomain they cannot resell. The proposal reached the front page of Hacker News on 29 June, where the project's own representatives are answering questions in the thread. The technical plan is more interesting than the marketing makes it sound. The identity plan is less interesting. Reading the pamphlet, the HN discussion, and the project's own replies, what stands out is that HCCF has correctly identified the cheapest part of the problem and quietly skipped the most expensive part, and the LetsEncrypt comparison the project keeps reaching for is both the best and the worst analogy they could have chosen.

The pamphlet (1-page PDF at hccf.onmy.cloud/wp-content/uploads/2026/06/dot-self.pdf) lays out four "core features" and stops there. Every adult gets a subdomain at no cost. The foundation provides shared services — VPN tunnels for non-public-IP self-hosters, a trusted mail server, TLS certificate generation, dynamic DNS, and a local DNS resolver with caching. The clients are open source. Governance is community-driven. The hosting model is "operated as a public good, similar to ISRG and LetsEncrypt," a comparison the project returns to several times in the HN thread. That's the whole program. The rest of the document is the call to donate, share, and join the community.

The DNS plan is genuinely good

If you set aside the politics and read the pamphlet as a network engineering proposal, the design choices are the right ones. The hard part of self-hosting today isn't setting up a Linux box, or even a reverse proxy, or even a Let's Encrypt renewal loop. The hard part is that most home internet connections come with carrier-grade NAT, which means the self-hoster's machine has no public IP at all. The traditional workaround is a tunnel — a paid VPS that has a real IP and forwards traffic over WireGuard to the home box. That costs $5–$20 a month, per site, forever, and is the single biggest reason the self-hosting community is small relative to the cloud-hosting community.

The HCCF proposal wires the tunnel into the TLD itself: if you have a .self subdomain, the foundation runs the relay that gives you a stable public address even though your home connection is NATed. The TLS, the dynamic DNS, the local resolver — those are the right things to bundle, because they are the actual friction in the workflow. Most self-hosters will recognize this list as "the things we already do by hand, badly, on a Saturday afternoon." Centralizing them is the right move.

This is also the part of the proposal that maps cleanly onto the LetsEncrypt analogy. LetsEncrypt's big contribution wasn't free certificates (StartSSL and others had been giving them away for years). It was automating the ACME protocol: the renewal loop, the domain-validation step, the trust-store inclusion. LetsEncrypt made the boring infrastructure of being a normal website owner boring in a way that didn't require the website owner to think about it. The HCCF pamphlet is offering the same thing for the boring infrastructure of running a personal server. If the foundation can deliver the bundle — domain, TLS, dynamic DNS, outbound relay — at the polish level LetsEncrypt achieved for HTTPS, the proposal is a genuine improvement in the state of the art.

The LetsEncrypt analogy is also the wrong one

LetsEncrypt works because the problem it solves is asymmetric in the foundation's favor. A certificate authority has to do cryptographic work the client cannot do for itself: sign a certificate that browsers will trust. The CA has to be the one in the trust store. There is no way for a self-hoster to issue themselves a certificate that Firefox will accept, and so LetsEncrypt has a structural monopoly on the easy path. The foundation is the only party that can sell you this.

.self has no such asymmetry. A user can register a domain at Cloudflare, Namecheap, or any other registrar and get equivalent functionality. A user can run Caddy or Traefik and get automatic TLS via ACME without going through LetsEncrypt at all. A user can run a tunnel through Tailscale, Cloudflare Tunnel, or ngrok and get a public address without ever touching ICANN. The HCCF foundation's "shared services" are not unique. They are competing with a long list of existing products, most of which are already in production at scale with paying customers. LetsEncrypt succeeded because it owned a step nobody else could offer. HCCF is offering a bundle of steps that lots of companies are already offering. The economics are different.

The HN thread lit up on this within hours. The most-upvoted substantive question, from commenter pavel_lishin, is the right one: it's not clear from the pamphlet whether HCCF is talking about a real top-level domain (a string in the root zone, costing $227,000 plus tens of thousands per year in registry fees) or just a domain under some other TLD. That's not a pedantic distinction. The application cost alone would consume more than most small nonprofits raise in a year, and the annual registry compliance cost is the part of the operation that requires either enterprise sponsors or, in the HCCF plan, donations. The "public good, free subdomains" framing assumes a LetsEncrypt-style sponsorship model; ISRG's own About page (abetterinternet.org/about/) lists its founding sponsors as Mozilla, the Electronic Frontier Foundation, the University of Michigan, Cisco, and Akamai — a different scale and a different constituency than the personal-internet-identity donor pool HCCF would need to draw from.

The identity problem is where the plan falls apart

The most consequential choice in the pamphlet is the rule "one person, one subdomain, no parking, squatting, or reselling." Read carefully, this is a strong claim: HCCF is saying it will maintain a registry that uniquely maps real humans to subdomains and prevents the abuse vectors that make the rest of the domain name system a marketplace for speculation and abuse. The LetsEncrypt analogy breaks here, hard, because LetsEncrypt does not have this problem. A certificate has no per-person uniqueness constraint. A domain does, if you say so. HCCF said so.

How do you verify that a registrant is a real, unique person? The HN thread makes the project's answer visible: the foundation is, at minimum, considering a third-party identity-verification service that links existing social accounts as one signal and reads government-issued e-passports via NFC as a stronger signal. The technical realities surface in the first dozen comments. e-passports are NFC-readable in only a subset of countries; in the United States, roughly half of adults don't have a passport. Social-account linking is a weak signal — it proves you can farm accounts, not that you're a unique person. None of these signals are sufficient on their own, and combining them is the unsolved problem every identity-verification startup has worked on for fifteen years. SahAssar and teraflop keep returning to the same point: LetsEncrypt shipped because the hard problems (trust roots, automated domain validation) had known solutions. HCCF is proposing to ship a system whose hardest problem — person-uniqueness at global scale — doesn't have one.

There's a more cynical reading. A TLD that promises a free subdomain to every human is a TLD with a built-in scarcity story. The next-day resale market for myname.self would be enormous the moment the TLD went live, and "no parking, squatting, or reselling" is enforceable only as long as the foundation has the operational capacity to detect, adjudicate, and shut down violators. The ICANN registry agreement for a gTLD requires an abuse point of contact, UDRP dispute processing, scheduled zone-file publication, and a thick WHOIS. None of those requirements address "is this registrant selling their subdomain on eBay," and the foundation has not, in the pamphlet or the HN thread, named a mechanism for doing so. LetsEncrypt's hard problems had known solutions in 2015. HCCF's hard problem in 2026 does not.

Why this is still worth writing about

It's reasonable to come away from the HN thread thinking the proposal is not ready. It isn't. The pamphlet is a one-pager, the technical spec is the bullet list, the answers in the thread are aspirational, and the comparison to LetsEncrypt does more work rhetorically than as engineering. None of that is the reason the proposal matters. The reason it matters is that ICANN's next application round is open, the Applicant Support Program is real, and someone will end up running .self. The interesting question is not "is HCCF the right organization" — that's a five-year project — but "what does it look like to operate a TLD whose mission is to give every human a stable DNS identity and to prevent the resale market every other TLD has produced?"

A serious version would have to solve three things the pamphlet doesn't. The first is the identity problem above, and the right answer probably isn't a passport reader — it's the LetsEncrypt trick of pushing the hard step to the protocol layer. ACME works because LetsEncrypt doesn't have to verify the user, only that the user controls a domain. A .self protocol that requires proof-of-control-of-some-existing-stable-credential (a phone number, a verified email, a peer-signed attestation) is more workable than a single foundation running a passport scanner. The second is the abuse problem: UDRP is built for trademark disputes, not person-uniqueness disputes, and the foundation would need a written policy for "this person is no longer reachable at this address" or "this subdomain was transferred in violation of the one-person rule." The third is the funding model. LetsEncrypt's $5M+ annual budget comes from a small number of large donors (Mozilla, Google, Cisco) whose interests align with HTTPS-everywhere. HCCF's equivalent donors would have to be organizations whose interests align with personal-internet-identity at population scale — Mozilla, the EFF, the Open Technology Fund, the Ford Foundation's digital rights portfolio, the EU's digital sovereignty programs — a real but smaller constituency.

The HCCF proposal isn't wrong to ask. The framing, that the modern internet is too centralized and that one piece of internet infrastructure should be operated as a public good, is the framing LetsEncrypt used, that Wikipedia uses, that OpenStreetMap uses, and it is correct. The execution is what fails. The DNS plan is solid. The LetsEncrypt comparison is half-right. The identity plan is a hole shaped like a passport. A serious version of this proposal, with a real answer to the person-uniqueness problem and a named funding model, would be one of the most consequential internet-infrastructure projects of the decade. A pamphlet is not that proposal, and the HN thread's "we have no actual answers" critique is fair. The interesting move from here is for someone — HCCF, or someone else — to write the second pamphlet, the one that addresses the hard parts.

What to do this week

If you're a self-hoster:

• The HCCF proposal won't be operational for at least two years in the best case (ICANN application, evaluation, delegation, registry startup, launch). Don't wait. Caddy + Cloudflare Tunnel + a cheap VPS is the current best practice and works today.
• The LetsEncrypt-style bundle (TLS + dynamic DNS + outbound relay) is something you can already assemble. It's not "free" — the VPS costs $5–$20/month — but the operational overhead is roughly what HCCF is promising, and the time-to-value is hours rather than years.
• Watch for ICANN's Applicant Support Program results in the next application window. If .self makes it through evaluation, the registry will need community input on acceptable use, dispute resolution, and person-uniqueness verification. That's where the project will succeed or fail on substance.

If you're an engineer thinking about identity:

• "One person, one subdomain" is a stronger identity claim than almost any other system on the internet issues today. The interesting research question is whether a TLD operator can make that claim with a verification stack that doesn't require passports, doesn't require social-account linkage, and doesn't require a central identity authority. The answer probably involves zero-knowledge proofs of existing credentials, but the engineering is non-trivial and nobody has shipped it.
• The LetsEncrypt pattern is the one to study, not because the technical problem is the same, but because the operational pattern is: run the boring infrastructure of the internet as a public good, funded by a small number of large aligned sponsors, with the hard step pushed to a protocol that any client can implement. The identity equivalent of ACME hasn't been written.

If you're a digital-rights or foundation funder:

• This is the kind of project that belongs on the Open Technology Fund / Ford / Mozilla Foundation shortlist, and the funding envelope is not large (the application fee is reduced under ASP; ongoing registry costs are in the low six figures; community coordination is the main expense). A $2M anchor commitment from a digital-rights foundation would, plausibly, take this project from pamphlet to launch.
• The thing to push for in any funded version is a published, reviewable identity-verification protocol, not a private one. The whole point of operating a TLD as a public good is that the public can see how it works.

The framing, corrected

The HN thread has spent more time on the LetsEncrypt analogy than on the proposal itself, fairly. The analogy is doing a lot of work: it explains why a nonprofit would want to run internet infrastructure, it explains the funding model, and it lends legitimacy by association. The analogy is also, in three specific ways, misleading. LetsEncrypt had a structural monopoly on its hard problem. LetsEncrypt's hard problems had known solutions. LetsEncrypt's funding constituency was much larger than the constituency for personal-internet-identity. A version of HCCF that succeeds will look less like LetsEncrypt and more like a small public-benefit registry with a published identity-verification protocol, a real abuse-handling procedure, and a small set of named institutional sponsors willing to underwrite the annual cost. That is a viable project. It is also a different project from the one the pamphlet describes. The first pamphlet is the easy part. The second pamphlet is the one that decides whether .self ever ships.

Disclosure

Drafted with AI assistance. Primary source: the HCCF .self pamphlet PDF at hccf.onmy.cloud/wp-content/uploads/2026/06/dot-self.pdf, fetched 30 Jun 2026. HN discussion: item 48724230, 298 points / 172 comments at time of writing; numbers moving as the thread ages, fetched the same day. ICANN's $227,000 application fee and Applicant Support Program reduction are referenced as factual claims sourced from the HN thread; specific ICANN pages I attempted to cite returned 404 to my fetch and the live ICANN search surface is unreliable, so the body does not link a specific ICANN URL for these. LetsEncrypt/ISRG context is from letsencrypt.org/about/ and abetterinternet.org/about/ (ISRG's main page). The 4-feature bullet list in the pamphlet is reproduced as quoted; longer passages are paraphrased.

Sources

• The HCCF .self pamphlet — "Announcing . . . A new Top-Level Domain built from the ground up to support self-hosting," 1-page PDF, hccf.onmy.cloud/wp-content/uploads/2026/06/dot-self.pdf, 21 Jun 2026. Primary source for the four core features (one-person-one-subdomain, shared services, open-source clients, open governance) and the LetsEncrypt/ISRG comparison. Fetched 30 Jun 2026.
• The HCCF announcement page — "Reclaiming Our Digital Selves: HCCF's Vision for a Human-Centered Top-Level Domain," hccf.onmy.cloud/2026/06/21/reclaiming-our-digital-selves-hccfs-vision-for-a-human-centered-top-level-domain/, 21 Jun 2026. Confirms the ICANN Applicant Support Program participation and the campaign framing.
• The HN discussion — Hacker News item 48724230 (".self: A new top-level domain designed to support self-hosting"), submitted 29 Jun 2026 at 21:05 UTC, 298 points / 172 comments at time of writing; numbers moving as the thread ages. Used for: the $227,000 application fee and ongoing registry-cost numbers (per greyface- and the HumanCCF reply on thread item 48725407); the LetsEncrypt sponsorship comparison (HumanCCF's own framing); the person-uniqueness / e-passport discussion (SahAssar, teraflop, al_borland, dom96); the DNS-cost analysis (AnthonyMouse, prepend, madsushi, psychoslave). Project representative handle is HumanCCF.
• LetsEncrypt / ISRG — "About Let's Encrypt," letsencrypt.org/about/, last updated 12 Feb 2021 (page unchanged at time of writing). LetsEncrypt is a service of the Internet Security Research Group; the nonprofit/CA-relationship model is the public-good structure HCCF explicitly cites as its reference.
• The ICANN gTLD program — newgtlds.icann.org/en/, the new-gTLD program landing page (fetched 30 Jun 2026). Specific ICANN pages I attempted to fetch for the $227,000 fee, the 2025 announcement, the registry-agreements index, and the Applicant Support Program sub-page (/en/applicants/applicant-support-program) returned 404 to my probe (also re-verified during this review: that sub-page was 404 as of 30 Jun 2026); the fee figure is sourced from the HN thread and the program's documented fee schedule is not separately linked in this post.