HelloZeroNet / HelloZeroNet/ZeroNet
Feature Proposal: Domainlists (DNS Systems Topic)
- Lenguaje dominante
- JavaScript
- Estrellas
- 18.8k
- Forks
- 2.3k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
Ok, so there's been quite a bit of talk on how Domain Names should be handled by ZeroNet. Some people say to stick with Namecoin blockchain. Some people don't like Namecoin. Some people think we shouldn't be using domains in the first place and that we should stick to addresses only. Some want HTTP(S) DNS systems (and other dns systems) to work and be enabled by default, some don't. And some want to create a new blockchain.
Now... blockchains usually require money to pay for the domain. Then there's the issue of whether you own the domain forever (which could result in lots of domains pointing to expired/outdated sites) or for a limited amount of time (which could result in someone stealing your domain). Then there's the problem of how people access this blockchain... does someone replicate the database of domains to a zite (e.g. ZeroName)? Do we require all users to have the blockchain downloaded? etc.... Personally, I don't like the blockchain system.
Then... there's traditional decentralized (it's really more like federated) DNS. This greatly increases centralization and there's the problem of determining which DNS servers are trustworthy, etc...
There's also ivanq's new Name.Yo which is a centralized solution maintained by ivanq/imachug/gitcenter and is optional by default. Imo, this is the closest to the idea that I have... because anyone can create their own centralized dns "service" and anybody can opt into any one. One problem... people who want to register domains for the maximum amount of users now have to register at a lot of different "services".
The solution that I thought of is not perfect, and it has been thought about before. It is a very simple solution. It relies around the idea that **your own computer is the most trustworthy of clients to yourself.**
By taking this central idea, we already have something that meets this... the relatively new Blocklists feature.
So, I propose a new **Domainlists** feature that will act like blocklists, but instead of blocking zites or users, it will be a list of domain mappings. A person can create their own domainlist for themselves, they can share this domainlist with others, or they can enable somebody else's domainlist (or they can do all three!).
And a zite that would make it easier to handle all of this would be relatively easy to create... it's about 75% the same as what my KxoBlock zite does right now.
#2189 #2049 #2087 #1696 #104
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Línea de trabajo
Start by reviewing the existing Blocklists feature and the related discussions in #2189, #2049, #2087, #1696, and #104. The proposal also points to the KxoBlock zite as a comparison. Done would require an agreed Domainlists design covering domain mappings, sharing, enabling external lists, and DNS-service trust before implementation can be scoped.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Área
- networking
- 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
- 20/100