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!
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.
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'.
The contracts themselves are immutable. ENS domains are NFTs. You should read the code and understand the actual structure of it before criticizing it.
> 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]
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.
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.
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.)
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.
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).
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.
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.
> 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.
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?"
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...
I think the evolution of "decentralized" infrastructure will start to bring out a lot more overlap between "traditional" decentralization communities (building stuff like Beaker browser) and some of the useful bits of crypto.
There is actually a ton of interesting and useful innovation happening in the crypto space that isn’t necessarily crypto-specific. If hacker news wasn’t so die-hard anti-crypto then more people would see that.
At the same time, I think it's a lot to expect of people to wade through the feverish speculative bubble to make sense of what technology is interesting. I think it would be nice if some of this stuff started making its way out of currency associated blockchain projects and into the wider world of decentralized algorithms and protocols.
Yes, I think this is both the biggest opportunity, and the biggest challenge, especially as I think there's been a growing separation between those two communities in the last few months and years. There's so many good ideas and implementations (and investment in harder problems of distributed systems) in the crypto/blockchain/web3 space, and a lot of hard-won experience and genuine applications in, as you say, "traditional" communities. It's just a matter of finding some sort of common ground.
I do think that the https://getdweb.net/ community is a model of how that crossover can work. It's also something I think a lot about at FFDW, which because of IPFS and Filecoin, has its feet in both camps.
Good question, I’m just not satisfied with this answer.
Requiring some form of payment is fine, but I’d like the ‘currency’ to be locked into the network so it doesn’t become something you can trade.
Maybe contribute to the network in exchange for a balance, that you can then exchange for domains after which it’s gone.
Ideally also figure out a way to limit people simply creating many accounts and using that, guess you can require upkeep for all domains, so when you stop contributing they disappear.
How would you accomplish PKI in such a way that would allow people to rotate keys to keep their account secure, but without allowing them to rotate their key into a different person's custody, thus doing a de-facto transaction that would enable someone to integrate the system with an exchange and put a price on account balances?
Also, what kind of consensus mechanism would you use, with the understanding that without a way to transfer/sell balances, Proof of Work degenerates quickly into a 51% attack, and Proof of Stake is infeasible? Or do you have a different idea in mind to decentralize such a system?
I'm asking these questions because knowing what I do about decentralized systems, in the end I can't see any way around a system like this having transferable balances. Either that or you centralize the part of it that keeps track of the network's history, making it basically akin to a big git repository.
> without allowing them to rotate their key into a different person's custody, thus doing a de-facto transaction that would enable someone to integrate the system with an exchange and put a price on account balances?
I don’t think this is possible in the first place. Someone will always be able to go around the system entirely and give someone their entire account. If somone wishes to sell all their names at the same time (or make one account per domain so they can sell it), there’s little to prevent that. I think making it harder is probably more trouble than it is worth for most malicious actors though (especially as they have to work with each individual account to retain the domains).
As to consensus mechanism, I have no idea. I don’t have enough experience with such systems to say one way or another.
Just that one part? Or everything? I’m not quite sure how Handshake is generating balance in the first place, beyond a lot of mentions of coins and exchange tickers.
I know I'm a few days late to this reply, but Handshake is a Proof of Work system like Bitcoin. You generate balances by mining it using a powerful computing device.
Perhaps this is my bias showing but I find it totally unbelievable to suggest that production would not be significantly faster had the vaccines been open sourced from the start.
As someone in a sibling thread pointed out, by necessity these research labs get access to patients' medical history, and releasing all of that all of a sudden seems like a net negative to society, especially when we don't have good policies everyone agrees upon for where e.g. you might be justified to turn someone down for a job because they have fragile bones, among other random reasons.
(Though as another sibling thread points out, it sounds like patient data isn't breached, so...who knows.)
In clinical trials companies only get access to patients' medical history by looking at it wherever it's stored (hospital, doctor's office). It can not be "taken home" or downloaded or whatever, for confidentially reasons. Similarly, if you work in a trial you can not have any direct contact with patients.
A trial involves administering a substance and then recording its efficacy by examining certain parameters (lab results, images, a questionnaire etc). Someone from the pharma company has to look at these results and then check the patient medical data to make sure there's no unrelated conditions that could have influenced that data (this was my job for a few years).
The company will have lab results with numbers instead of names and in a blind study, the treatment they received will be unknown to the company until it's "unblinded" at the end of the trial, which is usually done by an external company.
Have you tried Breez [1] on ios or phoenix [2] on android? Non custodial mobile lightning wallets have come a long way.
Lightning still has some rough edges (async payments) and unsolved issues (spam resistance) but it’s a lot closer to
being a convincing private scalable p2p payment network than many realise.
[1]: https://www.decision-procedures.org/