[publiush]

There's a dilemma as the magnet links/hashes aren't easily shareable. One option is to create a DMT directory, but this would be centralized. Handshake is the most mature decentralized domain name project, and I opted for it. It uses coins to limit abuse, since anyone can flood a decentralized system. You don't need coins to browse and use federalist. That said, if there are any other immutable DNS systems that aren't centrally controlled that I could review, I'll definitely take a look!

[chrisco255]

ENS (Ethereum Naming Service) is built on immutable smart contracts on Ethereum. Domain names (ie example.eth) are permissionlessly registered for up to hundreds of years at a time for ~$5 a year.

ENS domains can be resolved to Ethereum wallet addresses, IPFS, Bitcoin addresses or any other public key or string.

[rvz]

ENS seems to be centralized on to one smart contract holding all the domains under the .eth TLD (which already conflicts with the reserved 3 letter TLD for Ethiopia) under the control of a typical 'multisig' and 'DAO' which is based on 'trusting' the keyholders.

Basically ENS boils down to being a subdomain provider with ICANN-like governance, an illusion to 'decentralization'.

[chrisco255]

It's not one smart contract, it's actually many smart contracts and many open-source front-end components: https://github.com/ensdomains

The three letter code is not currently used by Ethiopia (they use .et and .com.et), and the ENS team is in negotiations with Ethiopia for the 3 letter TLD: https://www.olipso.com/en/domain-search/ethiopia https://twitter.com/BrantlyMillegan/status/14632165646149672...

The contracts themselves are immutable. ENS domains are NFTs. You should read the code and understand the actual structure of it before criticizing it.

https://docs.ens.domains/dapp-developer-guide/ens-as-nft

[rvz]

> The three letter code is not currently used by Ethiopia (they use .et and .com.et), and the ENS team is in negotiations with Ethiopia for the 3 letter TLD

Did I say 'used'? I said 'reserved' and the ENS team knows it is 'reserved' FOR Ethiopia, otherwise why are they negotiating specifically with them in the first place?

Relying on 'trusting' a so-called 'DAO' with all .eth domains sitting under the root multisig control is no different to trusting a subdomain provider with ICANN-like governance but this time, they're using a 'blockchain'.

All of the above sounds like a great 'illusion' to decentralization. I expect ENS to be no different to ICANN governance given that they can have full control over any of the domains on the ENS root. [0]

[0] https://docs.ens.domains/frequently-asked-questions#who-owns...

[xwvvvvwx]

My comment was not intended as a criticism of your project (which seems excellent), but rather an observation that crypto may be more useful than the parent had assumed.

[publiush]

Thank you, and no criticism taken! I agree. The problem with projects that incorporate cryptocurrencies these days has been that the cryptocurrencies themselves have been the focus and sometimes these projects have been going out of their way to incorporate them, in addition to a lot of projected hopes of what a system could one day become, not the reality of the utility of the system itself, today.

[saurik]

FWIW, Unstoppable Domains is already supported by both Brave and Opera (which I found interesting), and, from my determination, has a much greater chance of even more widespread adoption (due to it not being such a conflict with ICANN). (It has its own issues, but I frankly feel like all of these projects are still a bit "sketch". That said, I am not really pro- the premise of websites relying on permanent human-mappable identifiers in the first place, as I feel there are a ton of philosophical failings that people mostly just try to pretend don't exist down that road. I would much prefer projects like this just use EVM addresses as their underlying address and then users could potentially allow ENS names to map to those if they absolutely must have names locally, but then the names aren't really the canonical bits: permanent unique names just have too many moral landmines to be acceptable.)

[MayeulC]

> magnet links/hashes aren't easily shareable.

I'm OK with this (and that's more or less what IPFS does), you only need to pin a couple hashes, and one could build a website directory using this project. Or even a recursive DNS with zone delegation to other mutable torrents.

I like the idea of outgoing links being other hashes.

[anchpop]

There’s ENS, which seems on sturdier footing than Handshake to me, but the gas on ethereum is ridiculous

[chrisco255]

ENS is adding layer 2 support soon. While gas sucks on layer 1, since it's only ~$5 a year for the domain, you can register something for like 10-20 years for not much more than the cost to register for one year (gas considered).

[publiush]

Isn't Ethereum moving to Proof of Stake though?

[rglullis]

Yes, but PoS will not solve the problem of gas fees. Gas fees only come down when network capacity is higher than its demand.

Layer-2 systems (which allow some of the operations to happen off-chain) is how Ethereum developers are trying to scale the network capacity.

[publiush]

My worry with Ethereum is that moving to proof of stake changes the project from a decentralized one to something a little less so.

[rglullis]

Would you like to check how many people are running ETH2.0 validators [0] vs how many people are running Handshake nodes?

[0]: https://launchpad.ethereum.org/en/

[everfree]

Are you not concerned about the decentralization of Handshake's PoW consensus, considering that it uses a custom hashing algo that seems to be dominated in hardware production by a single company, Goldshell?

I believe you may be missing the forest for the trees by worrying about Ethereum's decentralization when compared to Handshake's.

[panick21_]

Have you checkout out the Gnu Name System from GNUNet?

[publiush]

The website for GNUnet seems to be down/404, but it looks like ownership of names is controlled by a central authority (https://manpages.debian.org/unstable/gnunet/gnunet-namestore...).

[summm]

If you want to do anything decentralized, I highly recommend to read all of the scientific papers from the gnunet authors. They theoretically solved a lot of problems a long time ago that modern distributed projects keep repeating. About the name system: It is a bit more complex than that. Everybody can "create" a domain, but others must import it's public key, somewhat compatible to a hosts file. The trick is that each domain can have arbitrary subdomains, also stored in the DHT. Now one can construct arbitrary deep trees. And everyone can choose a list of their trusted TLDs, and use them to resolve names. Say site.alice.bob.gnu (where .gnu is shipped with the client as default) and if I personally decide to trust Alice directly, I put her public key into my config file and from now on I can use site.alice instead without ever touching bob.gnu or .gnu again. Their DHT comes with unusual privacy guarantees due to clever cryptography. Furthermore gnunet already researched filesharing using content addressed blocks to allow for deduplication. Very clever. Unfortunately the implementation is not very usable and kind of stale. Some of these file sharing concepts are also better implemented by Freenet, which is a kind of anonymous decentralized web, even somewhat usable. A pity that those projects seem kind of stuck.

[duskwuff]

> The trick is that each domain can have arbitrary subdomains, also stored in the DHT. Now one can construct arbitrary deep trees. And everyone can choose a list of their trusted TLDs, and use them to resolve names. Say site.alice.bob.gnu (where .gnu is shipped with the client as default) and if I personally decide to trust Alice directly, I put her public key into my config file and from now on I can use site.alice instead without ever touching bob.gnu or .gnu again.

Which is ridiculous -- it makes names unreliable as public identifiers. Sure, you can refer to Alice's site as "site.alice", but nobody else can resolve that name unless they share your configuration. Worse, it means that anyone who has a different key mapped as "alice" might see "site.alice" resolve to something completely different than what you see.

[jancsika]

In practice it'd probably end up like the sources.list in Debian. E.g., an enormous number of users just use whatever pasta is copied in there by default. Then special devs change it or copypaste a Debian spell to magically add repos for whatever special cases they have.

And let's be honest-- if someone on HN were to post, "OMG the security updates repo got DDOS'd in Debian" it's not like the entire comment section is going to be filled with confused responses like, "Wait, do you mean the security updates for the gitlab repo that I added for my gitlab instance, or Debian's security repo for Debian the Universal Operating System?"

[jancsika]

It's fully decentralized from what I remember.

Looks like Christian did a quick 4 minute synopsis here:

https://www.youtube.com/watch?v=bB9SC4kD27Y

If you like the idea of both the decentralized resolution and using the DHT as a PIR, you might look into it.

Also-- if you find it's the case that it's not currently usable (which I'm guessing is the case), it might be worthwhile to mention on your README that you looked at this as an option and then briefly state the reason(s) why you can't use it in practice. If enough prospective users of gnunet do this it may motivate the maintainers to do something about the current state of the documentation and usability...