.self: Eine neue Top-Level-Domain, entwickelt für Self-Hosting

• Vorschlag für .self, eine neue Top-Level-Domain, die Self-Hosting von Grund auf unterstützt, damit jede Person ihre eigenen Daten vollständig besitzen kann
• Versuch einer alternativen Webarchitektur, um die Struktur zu verändern, in der Internet-Infrastruktur zur Datenextraktion und Ausbeutung von Aufmerksamkeit genutzt wurde
• Betrieb als öffentliches Gut (public good) und Einsatz von Open Governance, bei der alle Funktionen, Regeln und Beschränkungen anhand von Community-Feedback festgelegt werden
• Integriertes Angebot: eine kostenlose Subdomain pro Person, Shared Services wie VPN-Tunnel und Mailserver sowie Open-Source-Clients
• Als zugelassener Teilnehmer des Applicant Support Program (ASP) von ICANN unternimmt eine gemeinnützige 501(c)(3)-Organisation den Versuch, eine menschenzentrierte Internet-Infrastruktur aufzubauen

---

Problembewusstsein und Hintergrund

• Das Internet ist das mächtigste Kommunikationswerkzeug der Geschichte, doch die Infrastruktur, die es trägt, wurde von der Tech-Industrie in eine Richtung genutzt, die Nutzerdaten extrahiert und Aufmerksamkeit ausbeutet
• Um diese Dynamik zu verändern, ist der Aufbau einer alternativen Architektur für das Web nötig
• Als zugelassener Teilnehmer des Applicant Support Program (ASP) von ICANN wurde offiziell eine Kampagne gestartet, um eine neue Top-Level-Domain (TLD) zu sichern, die vollständig ethischer und menschenzentrierter Technologie gewidmet ist

Überblick über die .self-Domain

• Eine Top-Level-Domain, die von Grund auf neu aufgebaut wurde, um Self-Hosting zu unterstützen
• Sie wird als öffentliches Gut (public good) betrieben und nach menschenzentrierten Prinzipien entworfen und umgesetzt
  • Unterstützt jede Person dabei, vollständiges Eigentum an den eigenen Daten zu erlangen

Kernfunktionen (Core Features)

• Eine Person, eine Subdomain (One Person, One Subdomain)

  • Jede Nutzerin und jeder Nutzer erhält eine kostenlose Subdomain
  • Parking, Squatting und Weiterverkauf (Reselling) sind verboten

• Shared Services

  • Bereitstellung von VPN-Tunneln für private IP-Adressen
  • Betrieb eines vertrauenswürdigen Mailservers (trusted mail server)

• Open-Source-Software-Clients (Open Source Software Clients)

  • Bereitstellung von Clients für die geteilten Mail- und VPN-Dienste
  • Funktion zur Erstellung von TLS-Zertifikaten
  • Unterstützung für Dynamic DNS
  • Lokaler DNS-Resolver (local DNS resolver) mit Caching-Funktion

• Open Governance

  • Alle Funktionen, Regeln und Beschränkungen werden anhand von Community-Input (community input) festgelegt

Betreiber

• Die Human-Centered Computing Foundation ist eine gemeinnützige 501(c)(3)-Organisation
• Aufbau von Infrastruktur, Standards und Community für eine menschlichere digitale Welt
• Bitte um externe Unterstützung durch Spenden, Teilen, Community-Beteiligung und Feedback

[kaydash]

Ich dachte, es wäre gut und habe reingeschaut, aber es wirkt eher enttäuschend. Puh.

[GN⁺]

Kommentare auf Hacker News

• Erinnert mich daran, als die .tk-TLD vor 20 Jahren kostenlos wurde. Alle Hobbyentwickler haben sich eine geholt, dann kamen die Betrüger in Scharen, und am Ende begannen Facebook und Antivirenprogramme, sie zu blockieren.
  Ich erinnere mich, dass ich eine Website für eine Hausaufgabe auf eine .tk-Domain gestellt hatte und fast durchgefallen wäre, weil der Lehrer sie nicht öffnen konnte.

  • Diese Erinnerung kommt wieder hoch. .tk war wirklich überall, und ich erinnere mich auch an die Urban Legend, dass .tk-Domains ein paar Prozent des BIP ausmachten.
  • Weil ich mir von meinem Taschengeld keine .com-Domain leisten konnte, habe ich mich in den ersten Jahren beim Self-Hosting mit freenom / tk + Cloudflare durchgeschlagen.
  • Trotzdem leitet https://tcl.tk auf https://www.tcl-lang.org/ weiter.
  • tk und cc waren früher Domains, die man für PHP-Reverse-Shells genutzt hat; das weckt Erinnerungen.

• In den letzten zehn Jahren habe ich ein wenig daran gearbeitet, menschenzentrierte Identitätsziele im Internet zu definieren. Microsoft Vega könnte interessant sein: https://www.microsoft.com/en-us/research/blog/vega-zero-know...
  Es scheint darauf abzuzielen, die zentralen Anforderungen von Diensten, die online Identitätsprüfung benötigen, möglichst datenschutzfreundlich zu lösen. Zum Beispiel wäre es gut, wenn .self jeder Person weltweit eine einzelne, identitätsverschleierte Domain geben würde. Man könnte sich zwei Bereiche vorstellen: xxx.v.self als verifiziert, xxx.u.self als unverifiziert.
  In beiden Fällen würde per Zero-Knowledge-Proof geprüft, dass noch keine Domain registriert wurde; bei verifizierten Domains würden bei Bedarf PII zur Verifizierung und Überprüfung bei der Registrierungsstelle oder einem Datenbroker hinterlegt, während unverifizierte Domains das Versprechen „eine Domain = eine Person“ aufrechterhalten, ohne dass die TLD oder Registrierungsstelle offenlegen kann, wer die reale Person ist. Solche Anwendungsfälle könnte man zuerst auch mit normalen Domains erproben und dann passend zum TLD-Einführungsprozess oder den Auktionen der ICANN vorschlagen.

  • Es wäre gut, wenn du das über das Kontaktformular einreichst. Es braucht viel Community-Feedback: https://hccf.onmy.cloud/get-involved/
  • Es ist gut, dass Microsoft Vega Zero-Knowledge-basierte Identitätsnachweise populärer macht, aber schade ist, dass sie das auf recht starre Weise tun.
    Ich hätte mir gewünscht, dass das Vega-Team nicht anwendungsspezifische Zero-Knowledge-Schaltkreise, sondern eine universelle zkVM in den Mittelpunkt gestellt hätte. Ersteres bringt einen kurzfristigen Effizienzgewinn, Letzteres einen dauerhaften Flexibilitätsvorteil. Da sich die Performance von zkVMs in den letzten Jahren um mehrere Größenordnungen verbessert hat, müssen sich Befürworter von Zero-Knowledge-Privacy nicht übermäßig an die aktuelle Beweis-Performance der bestehenden Systeme klammern.
    Anders gesagt: Was das Vega-Team mit Nova macht, ist sehr clever, aber durch die Leistungssteigerungen bei universeller Berechnung in gewisser Weise unnötig geworden. Dinge wie RISC Zero ermöglichen es, beliebigen Rust-Code ohne großen Aufwand innerhalb von Zero Knowledge in einigen Hundert Millisekunden auszuführen. Identitätsprüfung ist nur eine von vielen nützlichen Anwendungen, die eine breit angenommene Zero-Knowledge-Computing-Plattform ermöglichen würde.

• Mich interessiert die Stelle „Recht jeder Person auf eine kostenlose Subdomain“ in https://hccf.onmy.cloud/wp-content/uploads/2026/06/dot-self....
  Ich weiß nicht, wie sie die Betriebskosten der TLD ohne Einnahmen aus Registrierungsgebühren decken wollen. Ist das ein Lockangebot für andere Dienste oder ein zu 100 % spendenfinanziertes Modell?
  Außerdem steht dort „kein Parking, keine Vorratsregistrierung, kein Weiterverkauf“, aber es ist unklar, wie sie legitime Nutzung ohne öffentlichen Dienst von Parking oder Vorratsregistrierung unterscheiden wollen.

  • Diese Domain soll als öffentliches Gut betrieben werden, und man sucht aktiv nach Förderern, die bei der Finanzierung helfen. Man kann sich das ähnlich wie bei ISRG und Let’s Encrypt vorstellen.
    Die Regel „eine Subdomain pro Person“ soll hoffentlich massenhafte Vorratsregistrierungen verhindern, aber ich gebe zu, dass es schwieriger ist, einzelne Domains genau zu untersuchen. Vielleicht muss man eine Art Heartbeat implementieren, bei dem der Eigentümer innerhalb einer bestimmten Zeit reagieren muss.
  • Ich frage mich, ob der Betrieb einer TLD tatsächlich so teuer ist. Die TLD selbst muss nur Nameserver-Records veröffentlichen, und der TTL liegt normalerweise bei etwa einem Tag. DNS-Antworten sind nur ein paar Hundert Byte groß.
    Große DNS-Anbieter wie Google oder Cloudflare werden für alle aktiv genutzten Domains täglich Anfragen stellen, aber sie cachen sie. Kleinere Anbieter cachen vielleicht weniger gut, fragen aber auch nicht täglich alle Domains ab. Bei einer Million persönlicher Domains wirkt das grob wie ein paar TB Traffic pro Monat; das mag etwas über den Kosten eines privaten Hobbyprojekts liegen, ist für eine kleine gemeinnützige Organisation aber nicht absurd hoch.
    Vorratsregistrierte Domains zu erkennen ist eher einfach. Vorratskäufer kaufen Domains, um sie zu verkaufen, also müssen sie potenziellen Käufern öffentlich mitteilen, dass sie zum Verkauf stehen. Wenn jemand die Domain irgendwo zum Verkauf listet, fordert man einen Eigentumsnachweis an; echte Käufer würden denselben Nachweis verlangen, um Betrug zu vermeiden. Sobald der Nachweis erbracht wird, zieht man die Domain ein. Es ist fast schade, dass solche Regeln nicht für alle Domains gelten.
  • Es ist hier nicht klar, ob wirklich von Domains oder von Subdomains die Rede ist; aus Sicht einer potenziellen Registrierungsstelle ist das ein Warnsignal.
  • Ich weiß nicht, ob der Betrieb einer TLD wirklich so teuer ist. Nameserver sind dafür bekannt, selbst auf Servern mit alten Spezifikationen sehr lange stabil zu laufen.
    Mit gutem Design sollte auch der Registrierungsprozess auf schlanker Infrastruktur laufen können. Ohne die Arbeitszeit könnten die Gesamtkosten vielleicht bei 1.000 bis 5.000 Dollar pro Jahr liegen, was für ein interessantes Hobbyprojekt durchaus im Rahmen wäre.
  • Es könnte auch ein öffentlicher Dienst sein. Viele Länder betreiben seit Jahrhunderten öffentliche Dienste, deren Betriebskosten um mehrere Größenordnungen höher sind als die einer solchen TLD.

• Das Namensschema ist unverständlich, und faktisch scheint es gar kein Schema zu geben. Etwas wie UUIDs hätte eher Sinn ergeben.
  Wenn man weltweit 7 Milliarden Menschen jeweils einen gibt, liegt das bei etwas weniger als 33 Bit; mit Reserve für die Zukunft und internem Spielraum auf 40 Bit gebracht, liefe es darauf hinaus, aus einer Liste von 256 Wörtern 5 Wörter auszuwählen. Bei einem leicht missbrauchbaren .self wirkt das deutlich vernünftiger als „wer zuerst kommt, mahlt zuerst“.
  Wichtiger noch: Ich verstehe nicht, warum das eine TLD und den damit verbundenen aufwendigen Prozess braucht. Man könnte dasselbe an eine passende, erreichbare Domain hängen, etwa onmy.cloud. Diese Frage habe ich bei fast allen TLDs, und ich bin mir nicht einmal sicher, dass ich damit falschliege.
  Wenn man ICANN zumindest Ernsthaftigkeit zeigen will, wäre es gut, das zuerst tatsächlich unter onmy.cloud zu betreiben und zu sagen, dass bestehende onmy.cloud-Domains transparent nach .self umgezogen werden, sobald man .self bekommt. Der beste Weg zu zeigen, dass man etwas „kann“, ist, es wirklich zu tun.

• Moment, ich verstehe nicht, warum .self hier nicht auftaucht: https://www.iana.org/domains/root/db
  Ich frage mich, ob das noch in der Ideenphase ist oder ob es so aufgebaut ist wie „man muss unser DNS verwenden, um .self-Domains auflösen zu können“.

  • Derzeit ist es in der Ideenphase. Die nächste gTLD-Bewerbungsrunde ist geöffnet, und während der Bewerbungsprozess läuft, wird Unterstützung gesammelt.
  • Domainnamen sind nicht zentralisiert, und es gibt keine zentrale Stelle, die die Liste genehmigter Domains kontrolliert.

• Die Site hat Fehler geworfen, und bei jedem Neuladen kamen drei verschiedene Fehlermeldungen. Eine statische Seite scheint völlig auszureichen, aber offenbar läuft sie dynamisch auf irgendetwas mit zu wenig Leistung, das selbst gehostet wird.

  • Stimmt. Die Resonanz war viel größer als erwartet, und wir versuchen gerade, einen Web-Cache einzurichten.

• Für Self-Hosting verwende ich einfach .home.arpa. Es ist kostenlos, und man muss nur noch das Vertrauen in TLS-Root-Zertifikate regeln; wenn das erledigt ist, ist es ziemlich gut.

  • Inzwischen funktioniert auch .internal gut.

• your.self würde ich mir gern zuerst sichern. Da werden vermutlich unglaublich viele coole Second-Level-Subdomains entstehen.

  • Einige offensichtliche Namen werden wahrscheinlich für bestimmte Zwecke reserviert. Zum Beispiel könnte my.self automatisch auf die Startseite im lokalen Netzwerk verweisen.
    Während des gTLD-Evaluierungsprozesses planen wir, aktiv Community-Feedback zu den konkreteren Details einzuholen.

• Das wirkt wie ein Ansatz, mit dem man für Angreifer ein besonders gutes Ziel abgibt.

• Ich verstehe nicht ganz, wie das funktionieren soll. Ich weiß nicht, wer reguliert und definiert, was „Self-Hosting“ ist und was „ethische Technologie“ bedeutet.
  Nur ein neues Domain-Suffix einzuführen, wird die Probleme rund um verteilten Konsens und Governance wohl nicht lösen.