ENS names aren’t really “domain names” until they buy a gTLD from ICANN and make them work for the masses.
If you have metamask installed your browser will resolve .eth domain directly. If you dont have metamask installed you can use .link prefix, for example here is my blog. if you have ipfs and metamaks installed you can visit https://nullradix.eth and it resolve the ipfs hash from ethereum then resolve the hash from ipfs. If you are worried about metamask using Infura you can install geth and run geth --syncmode "light" --v5disc--http--rpc.evmtimeout0--cache4096. It should take about 30 mins to sync and then you are using no thirdparty.
tldr: ENS names aren’t really domain names.
ENS aren’t just domain names, there can be used to name public keys, hashes or resolve arbitrary text. They can also have sub-names that are each represented by a NFT. Which can be used to delegate authority over them.
If you have metamask installed your browser will resolve .eth domain directly
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. The ubiquity of metamask and other things like it make a mockery of the ideals that make blockchains interesting. I am skeptical of your assertion that syncing geth in lightmode from scratch can happen in 30 minutes, and 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.
But ignoring the abomination that is Metamask, lets talk about why ENS names really aren’t domain names: As wikipedia puts it, domain names are formed by the rules and procedures of the Domain Name System (DNS). (emphasis mine)
I totally see the appeal of defining a namespace of memorable names on a blockchain, with cryptographically-defined instead of legally-defined name ownership. However ENS names (and .bit NameCoin names, etc) are not domain names until a registry1 makes it so by purchasing a gTLD from ICANN. (And even then, their domain name-ness would not have the censorship resistant properties of the underlying blockchain, because legal action could make a specific ENS name stop working as a domain name despite it continuing to exist on ENS. But, I think it’s still worth doing.)
1: Actually, there is another possible way: The operation of the DNS is specified by the IETF, who has delegated control of the namespace itself to the ICANN. RFC 6761 (Special-Use Domain Names) in 2013 defined a process whereby the IETF can define “pseudo-TLDs” separately from ICANN. This process was used in RFC 7686 (The “.onion” Special-Use Domain Name), and as a result, .onion names are technically domain names despite not being resolvable through the normal DNS root. Prior to RFC 7686, therewereattempts to similarly standardize .gnu, .zkey, .onion, .exit, .i2p, and .bit as pseudo-TLDs (.eth was not included because it did not exist yet then). If there was an RFC defining .eth as a pTLD, following RFC 6761 like RFC 7686 did, then .eth names would technically be domain names. However, that still wouldn’t make them resolve for users without additional software installed, so, I still think having some representative of the ENS DAO actually buy .eth as a gTLD would make the most sense.
In conclusion: nullradix.eth is not a domain name, because .eth does not currently exist in the Domain Name System. nullradix.eth.linkis a domain name, which is ultimately controlled by (ICANN and) whoever owns and operates eth.link. The fact that the eth.link operator currently chooses to delegate nullradix.eth.link to the holder of the ENS name nullradix.eth is convenient and certainly useful, but it does not mean that nullradix.eth is itself a domain name.
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.
If you have metamask installed your browser will resolve .eth domain directly. If you dont have metamask installed you can use .link prefix, for example here is my blog. if you have ipfs and metamaks installed you can visit https://nullradix.eth and it resolve the ipfs hash from ethereum then resolve the hash from ipfs. If you are worried about metamask using Infura you can install geth and run
geth --syncmode "light" --v5disc --http --rpc.evmtimeout 0 --cache 4096. It should take about 30 mins to sync and then you are using no thirdparty.ENS aren’t just domain names, there can be used to name public keys, hashes or resolve arbitrary text. They can also have sub-names that are each represented by a NFT. Which can be used to delegate authority over them.
Metamask and your browser most certainly cannot resolve a
.ethname 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. The ubiquity of metamask and other things like it make a mockery of the ideals that make blockchains interesting. I am skeptical of your assertion that syncing geth in lightmode from scratch can happen in 30 minutes, and 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.But ignoring the abomination that is Metamask, lets talk about why ENS names really aren’t domain names: As wikipedia puts it, domain names are formed by the rules and procedures of the Domain Name System (DNS). (emphasis mine)
I totally see the appeal of defining a namespace of memorable names on a blockchain, with cryptographically-defined instead of legally-defined name ownership. However ENS names (and .bit NameCoin names, etc) are not domain names until a registry1 makes it so by purchasing a gTLD from ICANN. (And even then, their domain name-ness would not have the censorship resistant properties of the underlying blockchain, because legal action could make a specific ENS name stop working as a domain name despite it continuing to exist on ENS. But, I think it’s still worth doing.)
1: Actually, there is another possible way: The operation of the DNS is specified by the IETF, who has delegated control of the namespace itself to the ICANN. RFC 6761 (Special-Use Domain Names) in 2013 defined a process whereby the IETF can define “pseudo-TLDs” separately from ICANN. This process was used in RFC 7686 (The “.onion” Special-Use Domain Name), and as a result,
.onionnames are technically domain names despite not being resolvable through the normal DNS root. Prior to RFC 7686, there were attempts to similarly standardize.gnu,.zkey,.onion,.exit,.i2p, and.bitas pseudo-TLDs (.ethwas not included because it did not exist yet then). If there was an RFC defining.ethas a pTLD, following RFC 6761 like RFC 7686 did, then.ethnames would technically be domain names. However, that still wouldn’t make them resolve for users without additional software installed, so, I still think having some representative of the ENS DAO actually buy.ethas a gTLD would make the most sense.In conclusion:
nullradix.ethis not a domain name, because.ethdoes not currently exist in the Domain Name System.nullradix.eth.linkis a domain name, which is ultimately controlled by (ICANN and) whoever owns and operateseth.link. The fact that theeth.linkoperator currently chooses to delegatenullradix.eth.linkto the holder of the ENS namenullradix.ethis convenient and certainly useful, but it does not mean thatnullradix.ethis itself a domain name.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.This tech of adding additional TLDs to your browser is decades old, lmao. Why would it need a blockchain btw?
b/c you don’t need to trust a third-party to store it correctly and its censorship resistant.