Metamask and your browser most certainly cannot resolve a .eth name directly; as you obviously know, it will rely on a company called ConsenSys that rents resources from Amazon to operate an API, the same way it does any other interaction with the ethereum blockchain.
This is misleading, metamask by default talks to infura, which is a hosted instance of a fullnode but not amazon (but still not good default behavior). But it is trivial to run your own node, im doing it now. Metamask talks to the eth nodes via a json rpc. You can change the endpoint in the setting to your local node. So yes metamask can absolutely resolve a .eth name directly without a third-party!
I’m tempted to actually try it, but, in any case, I’m pretty certain that even with a local geth metamask would still be relying on other 3rd party APIs for lots of other functionality.
Feel free to hit me up on matrix if you need any help setting it up. There are some trade off to light-clients. Im happy to talk about them if you are interested. I have some experience with the Light Ethereum Subprotocol (LES) It does not use any third parties, nor does geth in general. Why would you think that? Is this the story is being told? (There is a list of bootstrap nodes I would not qualify them as third party since they just introduce peers for the network)
I still think having some representative of the ENS DAO actually buy .eth as a gTLD would make the most sense.
sure I would agree.
In conclusion: nullradix.eth is not a domain name, because .eth does not currently exist in the Domain Name System
Yeah I mean we can argue about the definition of things, but what I mean is when type nullradix.eth in to my address bar it resolve it resolve the ipfs hash associated with my ENS name from the current state of ethereum which is synced local by geth (in light client mode), then ipfs loads the blog. So yay I can read my own blog with out any third-parties! and you can too. Then we can have a p2p party, they are way better then third-parties. I have an ipfs node running on my home machine which pins the hash. It maybe slow to load if no-one has visited it in awhile but its been pretty reliable.
This is misleading, metamask by default talks to infura, which is a hosted instance of a fullnode but not amazon (but still not good default behavior). But it is trivial to run your own node, im doing it now. Metamask talks to the eth nodes via a json rpc. You can change the endpoint in the setting to your local node. So yes metamask can absolutely resolve a .eth name directly without a third-party!
Feel free to hit me up on matrix if you need any help setting it up. There are some trade off to light-clients. Im happy to talk about them if you are interested. I have some experience with the Light Ethereum Subprotocol (LES) It does not use any third parties, nor does geth in general. Why would you think that? Is this the story is being told? (There is a list of bootstrap nodes I would not qualify them as third party since they just introduce peers for the network)
sure I would agree.
Yeah I mean we can argue about the definition of things, but what I mean is when type
nullradix.ethin to my address bar it resolve it resolve the ipfs hash associated with my ENS name from the current state of ethereum which is synced local by geth (in light client mode), then ipfs loads the blog. So yay I can read my own blog with out any third-parties! and you can too. Then we can have a p2p party, they are way better then third-parties. I have an ipfs node running on my home machine which pins the hash. It maybe slow to load if no-one has visited it in awhile but its been pretty reliable.