.self: un nuevo dominio de nivel superior diseñado para admitir self-hosting

• Propuesta de .self, un nuevo dominio de nivel superior que admite el self-hosting desde sus bases, para que cualquier persona pueda ser dueña por completo de sus propios datos
• Un intento de arquitectura web alternativa para cambiar la estructura en la que la infraestructura de Internet se ha usado para extraer datos y explotar la atención
• Operado como un bien público (public good), con gobernanza abierta en la que todas las funciones, reglas y restricciones se deciden según la opinión de la comunidad
• Integra la provisión gratuita de un subdominio por persona, servicios compartidos como túneles VPN y servidores de correo, y clientes open source
• Como participante aprobado del Applicant Support Program (ASP) de ICANN, es un intento de construir infraestructura de Internet centrada en las personas impulsado por una organización sin fines de lucro 501(c)(3)

---

Reconocimiento del problema y contexto de la iniciativa

• Internet es la herramienta de comunicación más poderosa de la historia, pero la infraestructura que lo sostiene ha sido utilizada por la industria tecnológica para extraer datos de los usuarios y explotar su atención
• Para cambiar esta dinámica, es necesario construir una arquitectura alternativa para la web
• Como participante aprobado del Applicant Support Program (ASP) de ICANN, se lanza oficialmente una campaña para obtener un nuevo dominio de nivel superior (TLD) plenamente dedicado a tecnología ética y centrada en las personas

Descripción del dominio .self

• Un dominio de nivel superior construido desde cero para admitir el self-hosting
• Operado como un bien público (public good), diseñado e implementado según principios centrados en las personas
  • Ayuda a que cualquier persona tenga propiedad total sobre sus datos

Funciones principales (Core Features)

• Un subdominio por persona (One Person, One Subdomain)

  • Se otorga un subdominio gratuito a todos los usuarios
  • Prohibidos el parking, el squatting y la reventa (reselling)

• Servicios compartidos (Shared Services)

  • Provisión de túneles VPN para direcciones IP privadas
  • Operación de un servidor de correo confiable (trusted mail server)

• Clientes de software open source (Open Source Software Clients)

  • Provisión de clientes para los servicios compartidos de correo y VPN
  • Función de generación de certificados TLS
  • Soporte para DNS dinámico (Dynamic DNS)
  • Resolver DNS local (local DNS resolver) con función de caché

• Gobernanza abierta (Open Governance)

  • Todas las funciones, reglas y restricciones se deciden según el aporte de la comunidad (community input)

Entidad operadora

• Human-Centered Computing Foundation es una organización sin fines de lucro 501(c)(3)
• Construye infraestructura, estándares y comunidad para un mundo digital más humano
• Solicita apoyo externo como donaciones, difusión, participación de la comunidad y feedback

[kaydash]

Entré pensando que estaba bueno, pero no me parece gran cosa, uf.

[GN⁺]

Opiniones en Hacker News

• Me recuerda a cuando el TLD .tk se volvió gratuito hace 20 años. Todos los desarrolladores aficionados se llevaron uno, luego llegaron los estafadores y al final Facebook y los antivirus empezaron a bloquearlo.
  Recuerdo que subí a un dominio .tk un sitio web que hice para una tarea de clase, pero la profesora no pudo abrirlo y casi repruebo.

  • Se me revivió ese recuerdo. .tk estaba literalmente por todas partes, y también recuerdo la leyenda urbana de que los dominios .tk representaban un % del PIB.
  • Como no podía comprar un dominio .com con mi mesada, durante mis primeros años de self-hosting sobreviví con freenom / tk + Cloudflare.
  • Aun así, https://tcl.tk redirige a https://www.tcl-lang.org/.
  • tk y cc me traen recuerdos porque eran dominios que antes usaba para reverse shells en PHP.

• Durante la última década he trabajado un poco en definir objetivos de identidad centrados en las personas en Internet. También podría valer la pena ver Microsoft Vega: https://www.microsoft.com/en-us/research/blog/vega-zero-know...
  Parece apuntar a resolver, de la forma más respetuosa posible con la privacidad, las necesidades centrales de los servicios que requieren verificación de identidad en línea. Por ejemplo, sería bueno que .self ofreciera a todas las personas del mundo un único dominio con la identidad ocultada. Se podrían imaginar dos zonas: xxx.v.self como verificado y xxx.u.self como no verificado.
  En ambos casos se usarían pruebas de conocimiento cero para confirmar que la persona no registró ya un dominio; en los dominios verificados, si hiciera falta, se dejaría información personal identificable en manos del registrador o de un data broker para verificación y confirmación; y en los dominios no verificados se mantendría la promesa de “un dominio = una persona”, pero sin que el TLD ni el registrador puedan revelar quién es la persona real. Este tipo de caso de uso podría probarse primero con dominios normales y luego proponerse conforme al proceso de lanzamiento de TLD de ICANN o a sus subastas.

  • Sería bueno que enviaran esto por el formulario de contacto. Hace falta mucha opinión de la comunidad: https://hccf.onmy.cloud/get-involved/.
  • Me parece bien que Microsoft Vega popularice las pruebas de identidad basadas en conocimiento cero, pero es una lástima que lo haga de una forma bastante rígida.
    Me habría gustado que el equipo de Vega pusiera en el centro una zkVM de propósito general, en lugar de circuitos de conocimiento cero específicos para cada aplicación. Lo primero es una ganancia de eficiencia momentánea; lo segundo es una ventaja permanente en flexibilidad. En los últimos años el rendimiento de las zkVM ha mejorado por varios órdenes de magnitud, así que quienes defienden la privacidad con conocimiento cero no necesitan obsesionarse tanto con el rendimiento de prueba de los sistemas actuales.
    Es decir, lo que hace el equipo de Vega con Nova es muy ingenioso, pero en parte se volvió innecesario por las mejoras de rendimiento en cómputo de propósito general. Algo como RISC Zero permite ejecutar código Rust arbitrario dentro de conocimiento cero en cientos de milisegundos y sin demasiadas complicaciones. La verificación de identidad es solo una de las muchas aplicaciones útiles que habilita una plataforma de cómputo de conocimiento cero ampliamente adoptada.

• Me da curiosidad la parte de https://hccf.onmy.cloud/wp-content/uploads/2026/06/dot-self.... que dice “todas las personas tienen derecho a recibir un subdominio gratis”.
  No sé cómo piensan cubrir los costos de operar un TLD sin ingresos por tarifas de registro. Me pregunto si es un producto gancho para otros servicios o si es un modelo 100% basado en donaciones.
  También dice “sin parking, acaparamiento ni reventa”, pero no queda claro cómo piensan distinguir entre usos legítimos que no ofrecen un servicio público y el parking o acaparamiento.

  • La idea es operar este dominio como un bien público, y estamos buscando activamente patrocinadores que ayuden con el financiamiento. Se puede pensar en un modelo similar al de ISRG y Let’s Encrypt.
    Esperamos que la regla de “un subdominio por persona” evite el acaparamiento a gran escala, aunque admito que investigar dominios específicos de cerca es más difícil. Tal vez haya que implementar algún tipo de heartbeat que obligue al propietario a responder dentro de cierto tiempo.
  • Dudo que operar un TLD sea realmente tan caro. El TLD en sí solo tiene que publicar registros de nameserver, y normalmente el TTL es de alrededor de un día. Las respuestas DNS son de unos pocos cientos de bytes.
    Los grandes proveedores de DNS como Google o Cloudflare harán solicitudes a diario para todos los dominios usados activamente, pero las cachean. Los proveedores pequeños cachearán peor, pero tampoco van a consultar todos los dominios todos los días. Para 1 millón de dominios personales, parece algo del orden de unos pocos TB de tráfico al mes; quizá un poco por encima del costo de un proyecto personal de hobby, pero nada absurdo para una pequeña organización sin fines de lucro.
    Distinguir dominios acaparados es relativamente fácil. Los acaparadores compran dominios para venderlos, así que necesitan informar públicamente a los compradores que están en venta. Si alguien publica el dominio en venta en cualquier lado, se le exige prueba de propiedad; y los compradores reales también deberían pedir la misma prueba para evitar estafas, así que en cuanto se demuestre, se confisca el dominio. Da pena que no se apliquen reglas así a todos los dominios.
  • No queda claro si aquí se refieren realmente a dominios o a subdominios, y como posible registrador eso me parece una señal preocupante.
  • No sé si operar un TLD sea realmente tan caro. Los nameservers son famosos por funcionar de forma muy estable durante muchísimo tiempo incluso en servidores con especificaciones viejas.
    Con un buen diseño, el proceso de registro también podría correr sobre infraestructura liviana. Sin contar el tiempo, quizá el total anual esté entre 1.000 y 5.000 dólares, una escala suficiente para un proyecto de hobby interesante.
  • También podría ser un servicio público. Muchos países ya llevan siglos operando servicios públicos cuyos costos son varios órdenes de magnitud mayores que los de un TLD como este.

• No se entiende el sistema de nombres y, en la práctica, parece que no hubiera ningún sistema. Habría tenido más sentido algo tipo UUID.
  Si se le diera uno a cada una de las 7 mil millones de personas del mundo, sería un poco menos de 33 bits; si se ajusta a 40 bits para dejar margen a futuro y espacio interno, sería como elegir 5 palabras de una lista de 256. En un .self, que es fácil de abusar, eso parece mucho más razonable que el primero que llega.
  Más importante aún: no entiendo por qué esto necesita un TLD y todo el trámite engorroso que conlleva. Se podría hacer exactamente lo mismo colgándolo de un dominio adecuado y accesible, por ejemplo onmy.cloud. Tengo la misma duda con casi todos los TLD, y ni siquiera estoy seguro de estar equivocado.
  Como mínimo, si quieren mostrarle seriedad a ICANN, sería bueno operarlo primero de verdad en onmy.cloud y decir que, si obtienen .self, migrarán de forma transparente los dominios existentes de onmy.cloud a .self. La mejor forma de demostrar que “se puede hacer” es haciéndolo de verdad.

• Un momento, no entiendo por qué .self no aparece aquí: https://www.iana.org/domains/root/db
  Me pregunto si todavía está en etapa de idea, o si la estructura es algo como “tienes que usar nuestro DNS para poder resolver dominios .self”.

  • Por ahora está en etapa de idea. La próxima ronda de solicitudes de gTLD está abierta, y están reuniendo apoyo mientras avanzan con el proceso de solicitud.
  • Los nombres de dominio no son centralizados, y no existe una autoridad central que controle la lista de dominios aprobados.

• El sitio tiró error y, cada vez que actualizaba, aparecían 3 mensajes de error distintos. Parece que una página estática bastaría, pero da la impresión de que lo están corriendo dinámicamente, con self-hosting, sobre algo que no tiene suficiente rendimiento.

  • Sí. La respuesta fue mucho mayor de lo esperado y ahora estoy tratando de configurar una caché web.

• Para self-hosting simplemente uso .home.arpa. Es gratis y solo hay que encargarse de la confianza de los certificados raíz TLS; una vez hecho eso, funciona bastante bien.

  • Ahora .internal también funciona bien.

• Quiero apartar your.self antes que nadie. Van a salir muchísimos subdominios de segundo nivel geniales.

  • Es probable que algunos nombres obvios se reserven para usos específicos. Por ejemplo, my.self podría conectarse automáticamente a la página de inicio de la red local.
    A medida que avancemos por el proceso de evaluación del gTLD, planeamos recibir activamente comentarios de la comunidad sobre los detalles más concretos.

• Parece una forma que facilitaría mucho que los atacantes te pongan en la mira.

• No termino de entender cómo funciona esto. No sé quién regula y define qué es “self-hosting” y qué es “tecnología ética”.
  No creo que introducir un nuevo sufijo de dominio vaya a resolver los problemas de consenso distribuido y gobernanza.