[HN Gopher] Handshake - A Namespace for the Decentralized Web
___________________________________________________________________
Handshake - A Namespace for the Decentralized Web
Author : rasengan
Score : 107 points
Date : 2020-09-24 15:05 UTC (7 hours ago)
(HTM) web link (meowis.ms)
(TXT) w3m dump (meowis.ms)
| lucasmullens wrote:
| What's the path to actually make these domains usable? Does a
| browser just have to start supporting Handshake?
|
| Too many blockchain pitches say things like it "would be great"
| if everyone used it. Yeah, it'd be great if we all moved to a
| decentralized everything, but users don't care enough.
|
| Could a browser like Brave or Firefox decide to start supporting
| this? Then some websites would only work on Brave/Firefox,
| eventually forcing Chrome and Safari to support it too.
| yupyup54133 wrote:
| Skynet leverages HNS names to shorten its skylink hashes. So
| path to usage here would be in the form of a shortened URL. IE:
| https://[traditional TLD]/hns/[HNS domain]
| 0df8dkdf wrote:
| Handhake is one of those service that is not over hyped. Check
| out their sponsors: https://handshake.org/grant-sponsors/
|
| Also a decentralised DNS is exactly what we need.
| DenseComet wrote:
| This is the biggest issue I have with Handshake. I have a
| couple Handshake TLDs, but I can't really use them at all. What
| Handshake is trying to achieve is in essence similar to trying
| to establish a new set of root servers. And just like that
| idea, it will never realistically happen.
|
| Infrastructure changes on this scale are basically impossible,
| as evidenced by the IPv4 to IPv6 transition. The only reason
| that even has a chance of succeeding is economic incentives
| caused by rising IPv4 prices, however, Handshake does not have
| that type of incentive.
|
| In my opinion, Handshake will lead to positive changes in our
| current DNS system. However, I don't see Handshake ever
| replacing our current system.
| johnnywu wrote:
| Here are some use cases! https://learn.namebase.io/starting-
| from-zero/how-to-use-hand...
| pwdisswordfish4 wrote:
| > _What Handshake is trying to achieve is in essence similar
| to trying to establish a new set of root servers. And just
| like that idea, it will never realistically happen._
|
| Yes, it will need to find a foothold in a parallel domain (no
| pun intended). IPC is one example. Combine something like in-
| process REST with the ability for any app to trivially bind
| to a name, and we'd be getting somewhere interesting.
| rasengan wrote:
| You can browse Handshake sites with Firefox by using the
| NextDNS [1] resolver (it's an option in Firefox's Settings).
| You can also use hnsd [2] or hsd [3] as your resolver.
|
| There are a lot of sites and you can see who has claimed their
| names and/or put up resolvable names on DNS Live [4].
|
| [1] https://nextdns.io/
|
| [2] https://github.com/handshake-org/hnsd
|
| [3] https://github.com/handshake-org/hsd
|
| [4] https://dns.live/ </shameless>
| StavrosK wrote:
| Don't you need to enable handshake resolution if you use the
| NextDNS resolver?
| rasengan wrote:
| You're absolutely right! You also need to activate the
| Handshake support in NextDNS' settings!
| johnnywu wrote:
| There are actually multiple paths already! In addition to
| NextDNS, there is:
|
| HNS.to (No DNS configuration or downloading needed), LinkFrame
| (Chrome extension), Resolvr (Firefox add-on)
| rektide wrote:
| The web navigator (browser) has had
| "registerProtocolHandler"[1] api, which has been around since
| at least 2008[2]. The history has been a little complicated,
| but it lets one write a page that can handle addresses of this
| sort. That could be a handshake relay page, that loads the
| handshake content, then renders a page with it.
|
| There is also similar work in WebExtensions to allow this to
| happen in the extension layer. Here's[3] a list of p2p-related
| handlers which were whitelisted (similar was done in Chrome),
| but "web+handshake" would work without whitelisting. These
| extensions would obviously be more useful if any mobile
| browsers had extension support. Firefox seems to have just shut
| the door on most extensions![4] What the hack?!
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/Navigator/r...
|
| [2] https://caniuse.com/mdn-
| api_navigator_registerprotocolhandle...
|
| [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1428446
|
| [4] https://www.androidpolice.com/2020/09/03/firefox-update-
| face...
| rektide wrote:
| I love the discussion & effort.
|
| On the other hand, relying on proof of work & creating an economy
| just to have distributed naming, to me, seems unnecessary &
| limiting. Users ought to be able to generate & use names heavily
| if they so desire, without having to do meaningless work to do
| so.
|
| Systems like wireguard and HIP aren't name systems but they are
| connective systems, built around cryptographic identity. They
| assume a system of plenty, where folks & systems can be
| generating & using new identities regularly. To me, i'd much
| rather create a name system build around identity & assumptions
| of plenty, than a more name oriented systems built around
| restricting/controlling/limiting/funnelling distributed naming,
| through a Proof of Work pipeline.
| AgentME wrote:
| Wireguard and HIP don't allow people to reserve human-chosen
| names in a single namespace and then resolve conflicts between
| users trying to reserve the same name. Solving that problem in
| a trustless decentralized way takes a blockchain-type system.
| (The problem is sometimes called "Zooko's Triangle". There
| weren't any known good solutions to it before Bitcoin
| happened.)
| Taek wrote:
| Most proponents of Proof of Work don't celebrate the use of
| energy. They celebrate the use cases that PoW enables. I don't
| know of any other way to trustlessly establish a consensus
| ordering, and I believe that being able to trustlessly
| establish a consensus ordering is very valuable, therefore I
| believe PoW is worth the expense.
|
| These decisions get made on an open market, it's not like
| anybody is forced to put money into a wasteful system if they
| aren't getting value out of that system.
| rektide wrote:
| I personally don't feel like identity & naming want or need
| concensus ordering. I cited HIP & Wireguard, which don't
| require that total ordering.
|
| The issues of control & power that come into play when we
| create distributed systems then make them all agree & work in
| the same way seems antithetical, to me, to the very idea of
| distributedness itself. I'm far more interested in systems
| that can range & explore possibility spaces untethered from
| any notion of root consensus. I would have us rely on
| informal weak trust models, friend of a friend, web of trust
| relations, rather than distributed-but-totalizing.
|
| Thank your for your reply. I've talked some about my
| questions & what I want to explore, but I appreciate your
| comment a lot. Talking about what proof of work buys us, that
| it's there for total ordering, is I think a wonderful
| assessment, & even though it's not my priority or desire, I
| do think it buys a lot of interesting technical capabilities
| & assurances we may otherwise not be able to have.
| tedunangst wrote:
| So I install the handshake daemon on my laptop, and I resolve
| paypal.com. Where do I go?
| fmi11 wrote:
| Rob Pike is doing something similar with Upspin. See
| https://upspin.io/
| joosters wrote:
| What happens when the handshake blockchain forks (say, because
| the developers can't agree on a change), which of the two
| 'trustless' forks am I meant to trust from that point on?
| haarts wrote:
| The one with the most hashing power. Just like Bitcoin.
| joosters wrote:
| I mean when contentious changes are made, e.g. bitcoin vs
| bitcoin cash, or ethereum vs etc. Hashing power doesn't come
| into it.
| Taek wrote:
| Ultimately you'd have to decide which one you want to treat as
| the canonical chain. There would be two (or more) parallel
| histories, and users would have to figure out which one they
| wanted to follow.
|
| By default, all users would go along with the original chain.
| To follow the chain with the updated rules (whatever rules the
| developers couldn't agree on), a user would have to manually
| opt-in to that updated set of rules.
| sprash wrote:
| How is this better than Namecoin?
|
| Namecoin has the unique advantage that you can do merged mining
| with Bitcoin which would make the network as secure as Bitcoin
| without further waste of resources.
| redsolver wrote:
| If you want to try out an application which is already using
| Handshake, check out my decentralized Android App Store based on
| Domain Names: https://skydroid.app
| evmar wrote:
| From the site:
|
| "Stop paying for new domains"
|
| Also from the site:
|
| "Buy Handshake coins"
|
| :(
| masukomi wrote:
| to be clear, you don't have to buy coins. you can still mine
| them and a boatload were given away to open source devs.
| capableweb wrote:
| Bit simplified. More accurate (at least from my understanding
| of the article):
|
| From the site:
|
| "Stop buying domains that are owned by third-party for-profit
| companies who control the market"
|
| Also from the site:
|
| "Use the Handshake currency to participate in auctions hosted
| by no one in particular, in a market controlled by code"
| themihai wrote:
| >> Use the Handshake currency to participate in auctions
| hosted by no one in particular
|
| Well, it looks like the short/good tlds were either reserved
| or already bought. To me it's just another failed
| distribution model/project. How many active handshake
| websites are there? 99% of the domains sold seem inactive,
| purchased for speculative resale value.
|
| Guess what? I'm working on my own fork with a more value-
| based distribution(IMO).
| masukomi wrote:
| actually... the tlds are gradually being parceled out via a
| seemingly random algorithm to prevent exactly the type of
| squatting you're complaining about. a LOT of TLDs still
| aren't available for purchase yet. the ones that are
| already in the top Alexa results were reserved for the
| people/companies that already owned the names in existing
| TLDs... again, to prevent squatting.
| capableweb wrote:
| > Well, it looks like the short/good tlds were either
| reserved or already bought
|
| That's up to debate I guess :) I'm sure people say the same
| about the web/internet today, but still good domains are
| being created every minute, because someone is more
| creative than the ones before.
| themihai wrote:
| The whole point(or at least most of it) of handshake was
| to have a fair distribution model. It's not like
| handshake is the first blockchain DNS system.
| joosters wrote:
| Remember, all of the talk about 'distributed' and 'trustless' for
| just about any blockchain is a lie. Just take a look at the
| mining pool statistics to see how many organisations are really
| in control.
|
| e.g. for Handshake, the largest two mining pools control about
| 60% of the hashrate, meaning that only two groups (possibly both
| run by the same person) control the whole chain. So much for
| decentralized!
|
| Even bitcoin suffers from the same centralization - the top 4
| pools have over 50% hashrate (and so effectively control the
| blockchain).
|
| Where did the 'distributed' blockchains go?
| 627467 wrote:
| Whether something is really distributed or not is not only
| debatable but more importantly transient. Maybe it is today and
| not tomorrow.
|
| Yes, you may consider that HS is not fully distributed because
| of the reasons you stated (many may disagree with you, hence
| debatable) but if you REALLY wanted to do something about lack
| of decentralization, you could: just start another mining pool.
| This is the other aspect of public blockchains that normally
| goes unmentioned when calling them distributed and trustless:
| they are permissionless.
| olah_1 wrote:
| > Even bitcoin suffers from the same centralization - the top 4
| pools have over 50% hashrate (and so effectively control the
| blockchain).
|
| In my limited understanding, this is not an issue because it is
| in the miners' best interest to actually do their job
| correctly. They wouldn't have an incentive to muck around.
|
| For the other cases like smart contracts and such maybe it's a
| little different. And perhaps that is why Ethereum is moving to
| Proof of Stake instead?
| companyhen wrote:
| https://www.youtube.com/watch?v=CjyJhKpLUBU
|
| This might help explain things. (2 min)
| colordrops wrote:
| Except they don't "control" the blockchain. They just have a
| bit more leverage about which transactions are included in
| future blocks. That's not optimal, but still a far cry from
| complete control.
| rektide wrote:
| Also on Hacker News right now is Escaping the Dark Web[1],
| about a coordinated effort to mint & publish some blocks
| without front-runners stealing all the work & claiming a big
| contract for themselves.
|
| Leverage, control. There's some play for what term we use to
| define the imbalance of these systems. But it sure seems like
| large, amassed forces have enormous sway over many of these
| systems, to the point where they can act as they want & are
| incentivized to do so with other large malfeasants.
|
| [1] https://samczsun.com/escaping-the-dark-forest/
| tuxxy wrote:
| > about a coordinated effort to mint & publish some blocks
| without front-runners stealing all the work & claiming a
| big contract for themselves.
|
| Wow, I have no idea how you read that really awesome
| article and concluded with such a response as this.
|
| The article demonstrates how the authors were able to
| collaborate with miners to safely secure $9M worth of
| tokens due to a security vulnerability in a smart contract
| on a public blockchain where anyone could figure out the
| vulnerability and execute it before they could secure the
| funds.
|
| Being upset that a miner is able to pick transactions that
| they want to include in their block demonstrates a clear
| lack of knowledge in how these distributed databases
| (blockchains) work and any critique similar to this can be
| disregarded.
| rektide wrote:
| > Being upset that a miner is able to pick transactions
| that they want to include in their block demonstrates a
| clear lack of knowledge in how these distributed
| databases (blockchains) work and any critique similar to
| this can be disregarded.
|
| I think me & the author both identified exactly how
| dangerous it is that large powerful forces in these pools
| can pick & choose which transactions they want to win.
|
| The author had to go peer with others to make their own
| large coordinated/centralized pool to try to make sure
| they had some chance of winning.
|
| Agreed that this was a public contract, & they managed to
| save the bacon via this coordination. But it's amazing
| how user-hostile it is trying to get anything done in
| these distributed environments. The power is enormously
| shifted to the hands of the large players. In many ways,
| a centrally managed but observable is a higher trust,
| higher security, more user-supporting system than these
| distributed systems.
| 411111111111111 wrote:
| Aren't most (including bitcoin) cryptocurrencies ledger
| confirmed by the continued confirmation of current hashing
| powers?
|
| That's at least what I understood the 51% attack to be.
|
| Basically have >50% quorum and you can just add any
| transaction to the shared ledger
|
| If this is actually done, the currency's with would be
| basically done for, so unlikely that anyone would do that
| colordrops wrote:
| It wouldn't necessarily be done for because you can't steal
| coins with a 51% attack. You can double spend and block
| transactions, which is not the end of the world.
| WorldMaker wrote:
| The distinction between "steal coins" and "double spend"
| is academic at best, though. In practice, in a double
| spend you are either lucky to be getting "free coins"
| stolen from deflation/inflation or the double spend is
| caught, unwound, and someone is designated the "loser"
| that lost money in the transaction. Either way meets many
| practical user definitions of "stolen coins".
| Taek wrote:
| You don't have the power to cause inflation. There is a
| material difference between stealing coins and double
| spending. Stealing coins implies you can rewrite anyone's
| balance to be your own balance.
|
| Double spending requires having counterparty, confirming
| a transaction with that counterparty, and then re-writing
| history to eliminate the transaction that the
| counterparty accepted. Coins that aren't in motion during
| the 51% attack can't be stolen, and coins that are in
| motion but aren't being sent from the attacker also can't
| be stolen.
| asutekku wrote:
| If someone can double spend or block transactions, that's
| pretty much the end of the network if no-one can do
| anything to it.
| viraptor wrote:
| But you can do something against it - wait. Basically a
| double-spend in 2 concurrent latest blocks is doable. N
| blocks down significantly harder. So the more valuable
| the transaction, the longer you want to wait to make sure
| it's not going to be a double-spend.
| tuxxy wrote:
| Additionally, we can also detect deep double-spends very
| easily!
|
| When a double-spend occurs, usually it's from a deep
| chain reorg. This is what people usually refer to as a
| double-spend attack, not the kind of reorg where it only
| affects a few of the top blocks (which isn't uncommon).
| The latter occur relatively frequently due to the nature
| of Proof-of-Work being essentially a race.
|
| Consensus mechanisms can detect when a sudden "deep"
| reorg occurs, e.g. a sudden reorg of 200 blocks that we
| didn't previously expect to be reordered. When this
| happens, it's relatively safe to say that this is a
| double-spend attack and we can disregard the attacker's
| chain. There's variations of this that additionally add
| things like "checkpointing" wherein reorgs beyond a
| certain block depth (the "checkpoint") are impossible at
| the consensus level.
|
| There's a lot to critique about blockchain tech, but
| miner centralization is a relatively dated concern. Yes,
| it's a concern for many blockchains, but for the major
| Proof-of-Work chains (Bitcoin, Ethereum), it's not an
| issue anymore.
| Taek wrote:
| You can't 'just add any transaction', the transaction has
| to follow the rules of the protocol (such as respecting
| prior owners of coins, respecting the total number of coins
| in circulation, etc) otherwise the block will be ignored
| (no matter how much work it has attached).
|
| The general technical audience tends to greatly
| overestimate the amount of power that a 51% attack has. A
| 51% attack can only do two basic things:
|
| 1. prevent certain transactions from making it onto the
| chain (somewhat expensive) 2. re-write history so that
| previously confirmed transactions are no longer on the
| chain (quite expensive - increasingly expensive the further
| back in time you rewind)
|
| You can't change the rules of the system, you can't
| arbitrarily steal funds from users, you can't change the
| inflation rate, etc.
| dfischer wrote:
| I don't think we need anything besides a hash and del.icio.us
| decentralized.
| intotheabyss wrote:
| How is this any better than ENS? I can currently visit .eth
| domains that are hosted on IPFS using Metamask.
| noworriesnate wrote:
| Are those static sites only, or can they resolve to an actual
| server IP address that does computation without sharing the
| code?
| llimos wrote:
| Sometimes there are advantages to centralized DNS. Wouldn't this
| make taking down botnets' c&c servers that much harder?
|
| I suppose there could be a blacklist that gets periodically
| downloaded by the OS. But then you're back where you started -
| who maintains the blacklist?
| 0df8dkdf wrote:
| Maybe don't think it as a DSN, but rather how the Root Files
| are hosted. Currently there are national security issues with
| the way how Root Files are hosted. It is ONLY fair since the
| Internet is for the world that the Root Files are decentralised
| in that fashion as well.
|
| Although I'm not entirely sold on BlockChain, there are other
| more energy saving gossip based Byzantine fault tolerant
| protocol to consider for use. However, everyone is just
| prototyping in this space. So for one I'm big supporter for the
| Root Files to be stored in this fashion, even if it is on a
| blockchain.
| MrXOR wrote:
| Similar question: based on Zooko's triangle, decentralization
| will reduce the security of DNS. How secure are blockchain
| based naming systems like Handshake, ENS, Unstoppable,
| Blockstack, etc?
| rini17 wrote:
| If you can't live without blacklists, then maintain them
| yourself. No protocol will do it for you, if DNS or IRC gets
| inconvenient, then botnets move to reddit or twitter (some
| already did).
| warkdarrior wrote:
| Decentralized DNS is fantastic for botnets that use Domain Name
| Generation (DGA).
| https://en.wikipedia.org/wiki/Domain_generation_algorithm
|
| You can easily control the domains, schedule their use, and not
| worry about takedowns.
| rini17 wrote:
| But are handshake domains free? Who pays the ETH blockchain
| fees?
| Taek wrote:
| Handshake is not Eth based it runs on its own blockchain.
| There are still fees but they are quite small. Less than a
| penny per update currently.
| cedricdahl wrote:
| If you're looking to easily play with Handshake, checkout
| https://namebase.io
|
| Recently chatted with the co-founder, Tieshun. He does a good job
| of making the case for Handshake and why it's so important for
| the internet. https://youtu.be/YRU0DE6zj5o
| [deleted]
| playcache wrote:
| This decries domain registrars as bein evil and pitches that
| with this platform you can become the same as them:
|
| -----
|
| Earn money selling subdomains off your TLD. Get paid recurring
| income for every subdomain you sell.
|
| Distribution -- Plug into Namebase's network of registrars,
| like gateway.io, to supercharge distribution for your TLD.
|
| Peace of mind -- We've got you covered. Namebase handles domain
| registration, revenue collection, and renewals. Sit back and
| collect your profits!
|
| ----
| lazzlazzlazz wrote:
| How is "a few people controlling top domains" the same as
| "many people controlling top domains"?
| playcache wrote:
| Because its still centralising control. If I want to use
| myrealname.tld, I need to pay someone sitting on that TLD
| while they 'sit back and collect the profits`. Its like a
| tech pyramid scheme.
| [deleted]
| lazzlazzlazz wrote:
| So decentralizing control among potentially thousands of
| TLD owners is... centralizing control?
|
| If you have a point you're not making it very clearly.
| arkitaip wrote:
| Yes. And his point is perfectly easy to understand.
| playcache wrote:
| I don't get why this is so hard to understand. You keep
| putting forward a strawman of it being less entities, but
| that's missing the point entirely that it's still
| centralised, it being to a lesser extent does not negate
| that simple fact.
| bleeding wrote:
| While I do agree that this is a significant departure from
| the current system, is there some mechanism other than
| individual domain owners refusing to sell that prevents
| this from re-centralizing? As in entities with sufficient
| capital coming in and buying up huge amounts of domains and
| rent-seeking on those and effectively re-creating the
| existing system?
___________________________________________________________________
(page generated 2020-09-24 23:01 UTC)