Discussion
Lol why not just use .btc domains at least they're somewhat Bitcoin native.
BTC.us
There, the adoption would be salty but nevertheless impressive without forcing.. Because, it can still make the fight converge! All ‘.eth’ native will frequent ‘Nostr’ & never again, there’ll be no more parts to take or something to envy to ‘Ethereum’..
♻️👏
Handshake is even worse than ENS or even UD. Literally anyone can "mint" a HNS TLD.
From my research, ENS is designed to be extensible & flexible, it doesn’t currently support DNSSEC due to "the lack of support for cryptographic signatures in Ethereum smart contracts".
The ENS system is designed to be extensible, so that it can be used to resolve a wide variety of resources, including blockchain addresses, off-chain web resources & other purposes in the future…
But Resolving an ENS domain's node ID can vary depending on the specific domain & "methods"used by the resolver.
Some suggested methods for resolving an #ENSdomain's node ID include using ENS console or "service that maintains a database of node IDs" such as Infura's ENS resolver…
I don’t fall for ‘Handshake' or 'Unstoppable Domain'.. Moreover, at the prelude to ENS, I ventured into it & even mint an ‘emoji-domain’ to see if ENS was compatible with it or even with the ‘Puny Code’ but Domain names are meant to be human-readable, which means that they can only contain a limited set of characters.
Ensuring that everyone can use ENS remains to limit domain names to the subset of ASCII characters that can be encoded using 'Punycode'. This allows ENS to avoid depending on any particular blockchain's native encoding mechanisms because it’s compatible with the internationalization (i18n) standards..
In the end, ENS isn’t so effective & is full of some disadvantages for the use of deploying an IPFS..
I have experience with ENS and can confirm this ain't even the tip of the iceberg.
It's very centralised. The DAO behind it owns 75% of all tokens in circulation so the "governance" is totally rigged.
They also (without asking anyone or announcing anything) snuck code into the smart contract that allows them to censor specific names at will. So if they blacklist your name it literally stops resolving.
Then you have Vitalik "Eat The Bugs" Buterin pushing for a tax on using ENS as well lmaoooo.
'Harberger taxes’ for months.. The worst thing is that ‘Nick Johnson’ & all the staff have no strength or drive to act on what is shenanigans behind the scenes! Even Vitalik has no strength on Ethereum.
'When the Nazis control something, it’s difficult to take an equal part in it'!
From my research, ENS is designed to be extensible & flexible, it doesn’t currently support DNSSEC due to "the lack of support for cryptographic signatures in Ethereum smart contracts".
The ENS system is designed to be extensible, so that it can be used to resolve a wide variety of resources, including blockchain addresses, off-chain web resources & other purposes in the future…
But Resolving an ENS domain's node ID can vary depending on the specific domain & "methods"used by the resolver.
Some suggested methods for resolving an #ENSdomain's node ID include using ENS console or "service that maintains a database of node IDs" such as Infura's ENS resolver…
I don’t fall for ‘Handshake' or 'Unstoppable Domain'.. Moreover, at the prelude to ENS, I ventured into it & even mint an ‘emoji-domain’ to see if ENS was compatible with it or even with the ‘Puny Code’ but Domain names are meant to be human-readable, which means that they can only contain a limited set of characters.
Ensuring that everyone can use ENS remains to limit domain names to the subset of ASCII characters that can be encoded using 'Punycode'. This allows ENS to avoid depending on any particular blockchain's native encoding mechanisms because it’s compatible with the internationalization (i18n) standards..
In the end, ENS isn’t so effective & is full of some disadvantages for the use of deploying an IPFS..