HCCF submits its bid to ICANN for the .self domain, a TLD built for self-hosting
The Human-Centered Computing Foundation has filed its application with ICANN for the .self top-level domain, a namespace designed for self-hosted, human-centered projects. Behind the symbol, the real question is what a domain name can actually guarantee — and whether .self will serve self-hosters or mark them as targets.
April 30, 2026. ICANN opens the application window for its 2026 New gTLD Program, only the second round of generic top-level domains in history. August 12, 2026. The window closes. The week of August 14, 2026. The selfh.st newsletter reports that the Human-Centered Computing Foundation (HCCF) has “officially submitted their application” for one very particular domain: .self, built for self-hosting.
The idea fits in one sentence: give projects that hand users control over their data and identity a namespace that says so, at the lowest layer of a web address. It is ambitious, dated, and — more than anything — a question of governance as much as DNS.
What HCCF is asking for, and what ICANN demands
The Human-Centered Computing Foundation is a non-profit whose argument starts from a diagnosis: large platforms have used web infrastructure to collect data and lock user identity inside closed systems. Its answer begins at the naming layer: build a space where projects can signal commitments around personal data, autonomy and human-centered computing.
To get there, HCCF joined ICANN’s Applicant Support Program (ASP), a scheme aimed at resource-limited applicants. ASP provides counseling, access to volunteer service providers, and — crucially — a 75% to 85% reduction on evaluation fees, plus lower registry-operator fees if delegation succeeds. That support is what makes a bid of this scale thinkable for a non-profit.
But ICANN is explicit on one point: ASP acceptance guarantees nothing. HCCF still has to file a full application, pass evaluation, face possible objections, pick a registry service provider, and prove it can run a namespace with the uptime, abuse response and policy controls ICANN requires. The road is long — a new TLD evaluation is measured in years, not months.
A registry can make rules, not miracles
HCCF’s strongest argument is not the name; it is the registry model. A TLD operator can impose conditions that neither .com nor .org impose: a code of conduct for registrants, published data-use practices, mandatory DNSSEC, data portability, even review processes for projects that abuse the name.
That is what would separate .self from yet another decorative TLD. If HCCF makes those rules binding, the address becomes a trust marker — like a label — rather than a mere suffix. If it does not, .self will carry only slogan value.
The risk is symmetric. “Human-centered technology” covers privacy tools, digital-identity projects, health software and AI products alike. Without public, verifiable criteria, any team could use the ethics language as simple brand polish. The TLD’s credibility will depend entirely on the rigor of its registration rules.
The real debate: does a TLD help self-hosters, or mark them?
The self-hosting community raised a more uncomfortable question, visible in the comments under HCCF’s founding post. A domain dedicated to self-hosting does not just say “this is mine”: it also says “this is self-hosted.” And self-hosting is exactly what many users prefer not to announce. As one commenter put it: “The only thing a top level domain would do is give attackers more confidence that self hosters have a home set up.”
The critique also cuts at verification. The “one person, one domain” concept floated in HCCF’s pamphlet raises the identity problem: how do you verify that a registrant is who they claim to be, without recreating the centralized identity systems the foundation means to bypass? At this stage, HCCF has published no funding amount, no registry partner, and no registration procedure. The answers will decide whether .self becomes infrastructure or a communications exercise.
The 2012 precedent: a TLD does not make a community
The .self filing belongs to a history worth remembering before taking the announcement at face value. The first new-gTLD round, launched in 2012, produced more than 1,200 applications and one simple lesson: winning a suffix creates neither community nor usage. Technical names like .app or .dev ended up in the hands of large companies; others, backed by well-marketed outfits, were delegated and then abandoned for lack of a business model.
Cost is its own filter. A gTLD application has historically run into the hundreds of thousands of dollars — evaluation fees, a deposit, then annual registry fees once delegated. That is exactly what ICANN’s ASP tries to correct for non-profits like HCCF, with a 75% to 85% fee reduction. But the reduction does not fund operations over time: it will still need a registry partner and a revenue stream to survive the years of evaluation.
The consequence is plain: .self is a long-term governance bet, not an available product. Between filing an application and the first delegation, years will pass, and the outcome is not guaranteed. That is a reason to follow the file with interest — and another reason to build nothing on it today.
What guarantees your identity today, regardless of .self
While ICANN’s evaluation runs its course, one technical truth stays fixed: a domain name protects nothing by itself. Surveillance, dark patterns and weak credentials pass straight through any suffix. What actually protects a self-hosted presence is what you control: a domain you own, a signed DNSSEC chain, infrastructure you run, and services exposed with method.
# The real guarantee today is your zone's signature, not its suffix
dig +dnssec SOA yourdomain.com | grep -E "RRSIG|status" That command tells you more about the robustness of your online identity than membership in any TLD. A signed, verifiable DNSSEC record is a cryptographic guarantee; a .self suffix would be, at best, a contractual one — worth only as much as the rules a foundation can make binding, and its ability to enforce them. The contrast is instructive: DNSSEC is a control you can deploy this afternoon, while a governed TLD is a promise measured in years.
For most self-hosters, the honest comparison is also the humbling one: a .me or .dev domain you actually own, or even a free dynamic-DNS subdomain, already does the job of pointing at your server — without waiting years for a new suffix. What .self could add is not reachability but a contract: rules about how registrants treat data and identity. Whether that contract materializes is the entire open question.
Verdict
If you already self-host, change nothing in your infrastructure for .self: the TLD is not delegated, its evaluation will take years, and its real value — binding registration rules — is still a promise. Your priority remains what you control: domain ownership, DNSSEC, backups, disciplined exposure.
If the idea appeals to you, follow the file for what it is: an attempt, novel in its object, to use the naming layer as a governance lever. Its success will be measured by the rigor of its registration criteria and its ability to enforce them — not by the suffix itself.
The bigger signal is that self-hosting now wants to name itself as much as it wants to build itself. That is a sign of a maturing movement — but maturity here will come from verifiable rules and disciplined execution, not from a domain name.
References
- selfh.st — Self-Host Weekly (14 August 2026)
- HCCF — Reclaiming Our Digital Selves: HCCF’s Vision for a Human-Centered Top-Level Domain, June 21, 2026
- LavX News — HCCF pitches .self domain for human-centered technology, June 30, 2026
- ICANN — 2026 New gTLD Program, Round 2
- ICANN — Applicant Support Program