Direcciones futuras

Hashiverse es un protocolo en marcha, no un protocolo terminado. Varias áreas importantes están parcialmente resueltas o se sabe que necesitan mejoras a medida que la red escala. Esta página describe las direcciones planificadas más significativas.

Recuperación y gestión de claves

La identidad autosoberana tiene una vulnerabilidad fundamental: si pierdes tu clave privada, pierdes tu identidad. No hay «olvidé mi contraseña» en un par de claves criptográficas. Es la mayor barrera de usabilidad para una adopción real de Hashiverse.

El enfoque previsto es el reparto de secreto de Shamir: dividir tu clave privada en N partes de modo que cualquier M de ellas (M ≤ N) puedan reconstruir la clave, pero M-1 partes no revelen nada. Distribuyes las partes a partes de confianza — amigos, familiares, depositarios institucionales — y puedes recuperar tu clave si M de ellos cooperan. La hipótesis de seguridad es que ningún subconjunto de M-1 depositarios conspirará contra ti.

Variaciones sobre el tema incluyen:

• Depositarios de claves de terceros: servicios especializados que conservan una parte y la liberan tras una verificación de identidad (biométrica, código de recuperación, etc.), proporcionando un mecanismo de recuperación familiar sin guardar la clave entera.
• Tokens de hardware: las Yubikeys y dispositivos similares pueden conservar una parte o directamente la clave raíz, aportando el hardware resistencia a manipulaciones y protección por PIN.
• Claves delegadas: ya parcialmente implementadas — una clave raíz puede autorizar claves delegadas para la firma diaria sin exponer la raíz. Perder un dispositivo significa revocar su clave delegada, no perder tu identidad.

Interoperabilidad

Hashiverse no necesita reemplazar las redes sociales existentes para ser útil. Puentes que importan grafos sociales existentes — historial de Twitter/X, feeds de Mastodon/ActivityPub, datos de Bluesky AT Protocol — bajan el coste de cambio para usuarios que ya tienen comunidades en otros sitios. Es una estrategia de crecimiento deliberada: hacer de Hashiverse el lugar donde tu identidad es soberana, y dejar que las redes existentes se vuelquen en él, en lugar de exigir a los usuarios que empiecen de cero.

Esquemas de firma extendidos para la autoría de publicaciones

Actualmente, cada publicación debe firmarse directamente con la clave que genera el client_id del autor. Dos patrones del mundo real importantes requieren más flexibilidad.

Claves efímeras

Un cliente puede no querer desbloquear su clave maestra de firma cada vez que publica — por ejemplo, en un dispositivo móvil donde la clave maestra está almacenada en una enclave de hardware o detrás de una verificación biométrica lenta. Las claves efímeras lo resuelven: el cliente genera un par de claves de corta duración, firma una vez la clave pública efímera con la clave maestra y luego usa la efímera para publicar a diario sin volver a tocar la maestra.

Los servidores aceptarían tales publicaciones realizando una comprobación en tres pasos:

1. Verificar que la firma del cuerpo de la publicación es válida bajo la ephemeral_signature_pub suministrada.
2. Verificar que la propia ephemeral_signature_pub lleva una firma válida bajo la signature_pub suministrada (la clave pública maestra).
3. Verificar que signature_pub hashea al client_id del autor, confirmando que la cadena de confianza vuelve a la identidad declarada.

Las claves efímeras pueden llevar un timestamp de expiración firmado junto a la clave pública, de modo que una clave de dispositivo filtrada o robada quede inválida tras una ventana acotada incluso si la revocación se retrasa.

Delegación organizativa

Una organización puede querer publicar bajo una identidad compartida única a la vez que distribuye la capacidad de publicar entre varias cuentas individuales — un medio de noticias cuyos periodistas tienen cada uno su client_id separado pero todos escriben bajo la identidad del medio, por ejemplo.

El modelo previsto: que la identidad raíz de la organización publique una lista de delegación firmada — un conjunto de client_ids autorizados a publicar en su nombre. Los servidores que acepten una publicación de un autor delegado verificarían que la clave de firma pertenece a un client_id delegado y que el registro de delegación lleva una firma válida de la clave raíz de la organización. Cualquiera de los clientes delegados puede publicar; ninguno necesita la clave maestra de la organización.

Reputación de cliente y atestación del mundo real

La proof-of-work eleva el coste de crear grandes cantidades de identidades falsas, pero no es la única herramienta disponible. Una dirección complementaria es la reputación de cliente: mecanismos que permiten a un cliente demostrar, junto a una publicación o a una pieza de retroalimentación, que es un participante real, antiguo o verificado externamente. Se exploran varios enfoques.

Atestación de identidad externa

Proveedores de identidad de terceros pueden avalar que una clave de Hashiverse pertenece a un humano verificado sin revelar quién es ese humano. Se consideran dos modelos amplios:

• Proveedores OIDC: un flujo OpenID Connect en el que el cliente prueba la posesión de una cuenta en un proveedor reputado (Google, Apple, un esquema nacional de identidad, etc.) y recibe una atestación firmada que vincula esa cuenta a su client_id de Hashiverse. La atestación viaja con las publicaciones como señal anti-Sybil opcional; servidores y lectores pueden elegir cuánto peso darle.
• Identidad emitida por el Estado: esquemas inspirados en Yivi y Digidentity (proveedores neerlandeses de eID) permiten a un gobierno o a una institución regulada atestar atributos específicos — edad, nacionalidad, número único de ciudadano — frente a una clave criptográfica, sin revelar a la red los datos personales subyacentes. Un cliente podría demostrar «humano único verificado en la jurisdicción X» a un servidor sin revelar su nombre ni su número de documento.

Ambos enfoques son estrictamente opt-in: los clientes sin atestación siguen participando con normalidad al nivel base de PoW. Las atestaciones son señales, no guardianes.

PoW acumulada como reputación

Cada vez que un cliente realiza un RPC debe incluir una nueva proof-of-work. Hoy se gasta y se descarta, pero representa una trayectoria observable: un cliente activo durante meses ha realizado, necesariamente, mucha más PoW acumulada que uno creado ayer.

Una extensión planificada almacena la mejor PoW vista de un cliente en un modelo de decaimiento día y mes — el mismo esquema de vida media usado hoy para la reputación de servidores. Un cliente que publica con regularidad acumula una buena puntuación con decaimiento; un bot recién creado que solo lleva horas tiene puntuación casi cero y debe compensar con una PoW por petición más alta para ser aceptado. Esto desplaza la economía en contra de las granjas Sybil: el atacante debe invertir tiempo real significativo precalentando cada identidad o pagar un impuesto en PoW continuamente más alto por petición por cada identidad que se salte el período de calentamiento.

Como la puntuación acumulada decae con el tiempo en lugar de crecer sin límite, una cuenta dormida que vuelve tras una larga ausencia tendría un sobrecoste modesto en PoW hasta restablecer actividad reciente — una molestia menor para usuarios legítimos y una barrera significativa para los bots que se crean, se usan en ráfaga y se descartan.

Mejoras varias

• Traits async: los traits async se soportan nativamente en las nightlies recientes de Rust, pero async_trait sigue siendo necesario para límites Send + Sync correctos a través de objetos de trait. Cuando la biblioteca estándar lo estabilice, la macro podrá retirarse.