I'm a bit sceptical about @IPFS and @ensdomains. Based on my limited understanding, in practice, IPFS resolves ENS content using DNS. This is OK as an interim solution, but if this is the case, the whole flow is again using a centralised service. 1/ // @vrypan→
So, if someone wanted to resolve .eth domains without relying on an external EthDNS, would you eventually have to use a full ETH node? This sounds like an overkill. 2/ // @vrypan→
Of course there are a lot of people that could deploy a full ETH node + EthDNS, so a user could choose to host their own, use a popular one, or even use on set up by their local hackerspace. But in every case you have to trust this third party blindly. 3/ // @vrypan→
I'm trying to understand (with my limited technical knowledge on this) if ENS contracts should be implemented on a smaller side chain. Or have a smaller, lighter, more robust side chain that can answer ENS queries. 4/ // @vrypan→
Please feel free to jump in if you are more knowledgeable on this field than I am. I would appreciate some expert opinion. Is there a roadmap towards something better? 5/5 // @vrypan→
