HelloZeroNet / HelloZeroNet/ZeroNet

Static Public Key Across Zites

Abierto
#2,217 6 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
JavaScript
Estrellas
18.8k
Forks
2.3k
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

**Is your feature request related to a problem? Please describe.**
What is the purpose of making a user's `public key` UNIQUE on every zite, but the `auth_address` _(aka Bitcoin address)_ the SAME on every zite?

**Describe the solution you'd like**
A STATIC `public key` (across all zites) that is derived from the user's `master key`, same as their `auth_address` _(aka Bitcoin address)_.

**Describe alternatives you've considered**
1. Could utilize the deprecated `auth_key`. (btw, why was this deprecated?)
2. Create a NEW plugin to derive a STATIC `public key` from the `master key`.

**Additional context**

## So Why Is This A Problem?

Dynamic zites work very well today, by allowing users to write data to their own folder/namespace within the zite's sqlite data storage.

But what if you're NOT using Zeronet's sqlite data storage. It makes using "legacy" client/server features within zites cumbersome; since you have to rely on "legacy" authorization techniques for the user. Rather, a Zeronet-enhanced APP SERVER "should" be able to retrieve a user's `public key` from a registry (based on their cert id) and then send a challenge that can ONLY be solved by the `private key` holder. This would be AUTOMATIC, upon arriving at a ANY zite, making user authorization __BUILT-IN__ for ALL developers.

eg. It should appeal to developers wanting to bridge an existing Clearnet application over to Zeronet. In which case, it would be ideal to utilize current backend systems while making the migration to a fully decentralized solution.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

No files, tests, or entry points are named. Start by tracing ZeroNet's current public-key and auth_address handling, then review the deprecated auth_key mentioned in the issue. Done should include a defined approach for deriving a static key from the master key and clarifying how it supports authorization across zites.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Área
authentication, cryptography, security
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.