Not really, the DNS data is stored in a new data structure called an "Urkel Tree" that offers small proofs and fast lookup times. Full nodes (that archive and process the entire blockchain) can serve these proofs to light clients that use the data to recursively resolve DNS.
The closest thing there is right now would be ENS - the E stands for Ethereum.
ENS domain names can mainly be used for payment for now, so I'd be sending crypto to [domain].eth where the advantage is having a readable address instead of a random-looking string.
You can also host web pages on it (which I believe is helped by their IPFS) but that has seen limited use as of yet.
I work at Namebase. Handshake is compatible with ENS actually because Handshake has reserved .eth for ENS names. Since Handshake decentralizes the top-level namespace, Handshake can serve as a gateway to other naming systems like ENS and Namecoin.
It can do that or it does do that? Also, ENS doesn't typically resolve to an IP but instead a swarm hash or a block address, what would end up resolving in those cases?
The way the the ENS integration would work is the DNS request for vitalik.eth would end up at a Handshake Authoritative Name Server and then there are certain blacklisted top level domains (.onion, .tor, .i2p, .bit and a few others) where a client for that protocol is instantiated and then a request is sent out to the appropriate system and then the response would be formatted into a DNS query by the Handshake Name Server and sent back to the client.
Totally agree. Another great thing about Handshake is the fact that this removes the need to rely on SSL CAs which have seen compromises time and time again.
Not really. One problem is most of the good names got taken by squatters right out of the gate, like hundreds of thousands of them - irl trademarks, all the nouns in the dictionary bought by one guy, etc. Mainstream business will never adopt it for that reason, so its growth is inherently capped and most crypto natives ignore it.
I work at Namebase, which is a domain registrar and on-ramp for Handshake. That’s what makes Handshake so compelling imo. There are a lot of mechanisms that prevent squatting: bids are locked up until auctions finish, so squatters need to pick and choose where they allocate coins. Furthermore, names are rolled out over a 52 week period (hash of the name mod 52), which means that there will still be a lot of good names available 6 months into launch. And the Alexa top 100k domains have been pre-registered, in addition to the blacklisted ICANN TLDs, so that only facebook.com can register .facebook. Finally, 70% of the coins are being airdropped to developers so the bidding power will be evenly distributed from the start — it’ll be difficult for a whale to buy up $10mm of Handshake coins and outbid everyone.
Yeah, because I want to have to mine a token every time I update my DNS settings. -_-
I get the "global, transparent, append only log" appeal, but for the reality of most people, I don't want to rely on a blockchain converging, or processing my update in a certain amount of time.
And that doesn't even cover companies (I don't agree with this, but it is a reality), that consider DNS entries private, and don't want to expose an easily scannable list of DNS entries .
You don’t need to store the zone on chain - you can actually simply include NS records and have your authoritative server elsewhere - just like DNS today!
The DNS ROOT becomes controlled by the people instead of ICANN - it’s the end of ceased and censored domains.
Additionally, HNS also fixes the problems the CA system has today. CAs can generate certificates for any domain - even if the domain owner didn’t request it. This has led to countless occurrences of abuse.
> The DNS ROOT becomes controlled by the people instead of ICANN - it’s the end of ceased and censored domains.
Good luck with that. If there is no way to have a US court take ownership of a domain (or force someone to handover a bad faith registration), someone will either end up in jail for contempt, or it will just be banned.
> Additionally, HNS also fixes the problems the CA system has today. CAs can generate certificates for any domain - even if the domain owner didn’t request it. This has led to countless occurrences of abuse.
It fixes the non EV cert situation (kind of - CAA records also help this, and work on the standard internet), but doesn't fix EV certs (i.e. amzon.tld is actually Amazon LLC and not Scammers R Us Ltd.)
It also ignores the reality of most major companies in the world MITM'ing all outbound traffic from offices to ensure sensitive content is not exfilled from the company - there is 0 chance of them allowing traffic out that they could not MITM.
> Good luck with that. If there is no way to have a US court take ownership of a domain (or force someone to handover a bad faith registration), someone will either end up in jail for contempt, or it will just be banned.
This same argument applies to bitcoin and it has not (yet) been banned in much of the free world.
We don't see them trying to change anything on the chain with bitcoin - just trace people (and law enforcement has gotten pretty good at that to be fair). They seize wallets from people they arrest, like normal cash / assets, or get a court order to get companies holding the coin to hand them over, if the accused used a hosted wallet.
But you first have to figure out who to put in jail for contempt and in order to ban it you'll have to take down the entire block chain.
I'm not totally sure how this one works but with ENS there are key holders that theoretically have the ability to do operations on any entry but it takes a certain number of them to all coordinate and agree.
Right, so you threaten all of them with jail until they hand over the keys to a US Court to continue to do the takedowns for copyright enforcement / ISIS website / scam site pretending to be Amazon / the new Silk Road / $reason.
We have seen this before, where people who run these services are personally held in contempt until they comply with the order.
This is exactly the reason that peer-to-peer services never work. Tor, BitTorrent, cryptocurrency: Failures, all. Each of their users threatened individually by US law enforcement until the service died.
There are no "people who run these services" in the case of blockchain name resolution, though. There is (usually) a single person who possesses the private key necessary to update the records for a domain - if they find out who that is, they're welcome to use legal compulsion to force them to act.
* I say "usually" because more complex permissions schemes are possible with Bitcoin Script. m-of-n in particular I could see being very useful; it could allow individuals to update some parts of the record but not all - for instance, make it mathematically impossible to abandon the domain or move where it's pointed, but still possible to update contact information.
There’s no one to threaten. You may be able to find one or two people running the fullnode but it’d be immensely difficult to find everyone running a fullnode around the world and threaten them.
ENS has only 6 root key holders which not that many from a security perspective. Handshake has no root key holders — it’s secured by every fullnode supporting the blockchain. That’s what makes bitcoin so difficult to shut down.
If this gains traction, you will be able to pay a service provider a fee to update DNS entries for you. This is like the current system used by registrars. You don't need to care if it is powered by a blockchain in the background if you don't want to.
I think it is great to have an alternative DNS system that is more censorship resistant.
> you will be able to pay a service provider a fee to update DNS entries for you.
So every time I add a new LB, or cycle out an environment I have to pay someone? And then wait for them to process the chain to publish the result?
Remind me, what did etherium get to for transactons to clear? 20 something hours? That is not something I want when I am trying to redirect traffic from either a set of NS records that are broken, or if I host the full zone in the chain, a broken AWS / Azure region.
Combine the time to wait for caches to refresh on the internets (better these days, but still longer than people would like), with waiting for a blockchain to publish my new records, and you have ops people in pain.
DNS is already one of the largest fault tolerant, eventually consistent, cachable, federated, and globally distributed key value databases ever to exist - we don't need to add blockchain to the mix.
Handshake is for top level domains. You can do quick updates using traditional DNS infrastructure at a domain underneath a Handshake top level domain. The benefit is that you have a cryptographic asset representing the top level domain, the root of trust comes from you, value can accrue in the asset itself, its tradable with non interactive atomic swaps and is censorship resistant.
Isn't this middlebrow dismissal? Like, I get that you don't want to have to "mine a token" if "mining a token" means "waiting half an hour", but if it means "waiting 100ms or paying $0.00001", I'd take that tradeoff to own my DNS.
I wouldn't - it means that I am reliant on a blockchain transaction clearing, and as the chain gets bigger, that time has potential to increase. etherium was really quick and cheap when it launched, and it is not now ...
> as the chain gets bigger, that time has potential to increase
I don't see how this follows at all.
The slowing transaction incorporation times for major cryptocurrencies is related to transaction volume, not to the total size of the chain to date. Presumably a system restricted to updated HNS entries would not encounter anywhere near the same transaction volume.
I get the "global, transparent, append only log" appeal, but for the reality of most people, I don't want to rely on a blockchain converging, or processing my update in a certain amount of time.
From what I've heard, the "Layer 2" networks for even the most venerable of blockchains have the potential to reduce transaction times a couple of orders of magnitude.
You don't do the mining, you pay a small fee to have others do the mining. By small I mean it costs me about $0.004 USD worth of eth to update my ENS domains.
A pretty small price to pay for the superior features.
For private info perhaps DNS will continue to work just fine for companies. Theoretically you can also host private block-chains and use that if you really wanted to.
> A pretty small price to pay for the superior features.
I am still trying to figure out what superior features these are, even for me as a small sites.
For certs, I can have Lets Encrypt, and set a CAA record of letsencypt.org. For DNS, I can host my own, or use one of the myriad of providers out there.
I am not likely to have my domain taken away from me (and neither are most people), so the DNS ROOT switch is not a draw.
DNS has always been decentralized. I mean, first sentence on wikipedia:
> The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network.
> While DNS is already fairly decentralized, the centralization exists because of ICANN’s gatekeeper control .... ICANN ultimately has control over what internet names are acceptable – and serves as a singular point of failure.
Nothing stops you or anyone from running your own DNS root. The "hard part" of making a global DNS deployment operational isn't developing the technology; it's getting everyone to agree on all the particulars of the deployment.
> Nothing stops you or anyone from running your own DNS root
That is what this is doing.
> Handshake is a decentralized, permissionless naming protocol compatible with DNS where every peer is validating and in charge of managing the root zone with the goal of creating an alternative to existing Certificate Authorities. Its purpose is not to replace the DNS protocol, but to replace the root zone file and the root servers with a public commons.
Decentralization can occur across many axes -- our public DNS infrastructure, for example, does not have decentralized registration or governance, which is what matters for things like privacy or censorship resistance.
I work at Namebase. This 100%. Importantly, the root of trust for SSL is not decentralized. Any one of the 600 CAs your computer trusts can compromise your HTTPS requests. The most interesting thing about Handshake from a security angle is it shifts the root of trust from the CA hierarchy to a decentralized blockchain system, which can significantly improve the security of SSL.
The article and Namebase faq go into some details, but just so I understand, what are the practical effects of this beyond decentralization?
- If I buy a TLD, will I own it in perpetuity, even after I die?
- If we're encouraging people to register their own TLDs, won't we run into the same limited-name/squatter problems as normal domains? I get that names are being released at a trickle, but that seems like it would just put off the problem a bit.
- Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue?
- Is Brave the only browser looking into this, or are we also seeing buy-in from browsers like Firefox and Chrome?
I'll read through whitepaper and learn the details, but if possible I'd like to know if it's worth my time to do so.
I'm not necessarily feeling great about the idea of having separate TLDs for every site, but I'll admit there is something attractive about being able to register 1 TLD as a namespace, one time, and then using subdomains for every other site I ever make. It's just not clear to me how that system would scale.
- Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction.
- Yes, names are rolled out over 52 weeks based on the hash of the name (modulo 52), which was designed to prevent squatting. The auction & renewals processes should help as well.
- Yes, Handshake uses proof-of-work. It's a different algorithm (Blake2b keyed with KMAC256) than Bitcoin but still essentially relies on energy consumption for security.
- I'm not aware of any other major integrations. But it is easy for users to run their OWN local light client and use it as the DNS resolver for their OS: https://github.com/handshake-org/hnsd
> Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction.
Yes! Another comment mentioned that you’ll need to keep keys online to do this, which is not completely true. You can also create a key that can only be used renew your names that’s separate from your master key.
I work at Namebase.The other comments address most of your questions, but just to add on: the 52 week rollout will help significantly with preventing squatters. Handshake has designed some other mechanisms that prevent squatting. The first is that the Alexa top 100k domains have been pre-registered (only facebook.com can register .facebook on Handshake). This ensures that existing domain stakeholders can transition to Handshake without worrying about their name being squatted on.
Second, Handshake is airdropping 70% of the mainnet coins to open-source developers. If you have over 15 followers on GitHub, you can claim around $400-800 of Handshake coins (HNS) with no strings attached. Not only will this give developers an incentive to check Handshake out, but also this ensures that the bidding power is spread out at launch. Without this mechanism, a whale could spend $10mm on HNS at launch and outbid everyone.
You should have received a seed phrase as part of that airdrop. You'll be able to use that seed phrase to claim your tokens on the testnet and mainnet. Ping me at tieshun at namebase.io if you want to try things out on testnet — I'm happy to walk you through it.
Is there a way to be included if we have fewer than 15 followers? I've open sourced some personal projects, and I'm interested in claiming my domain (already did this on ENS), but after visiting handshake.org I did not see a way to participate without being included in the automated airdrop. Thanks!
I have only skimmed the whitepaper, but I did not notice any mention of handling of the loss of the private key.
Sooner or later, any servers get hacked, and attackers can get the private data stored there. If this happens, is there any way to recover the TLD? Or are we going to end up with a network where many names point to ransomware pages?
To update DNS records, you need to submit a valid transaction to the network. People generally do not keep their keys connected to the internet to prevent this type of problem. It is possible to use Bitcoin Script to describe policies regarding updating the DNS records, ie a 2 of 3 multisig to update.
There’s a mechanism that prevents this. If your key is stolen you can submit a transaction that opens your key for public auction again, so an attacker would have to outbid you in the auction to win the name. This will prevent most ransom attacks.
If something is worth stealing, then it would be. The majority of code isn’t infrastructure quality (equivalent to setting cement and leaving it there for a hundred years with minor maintenance). Until then, the technical flaws must be balanced with collective governance.
(Incidentally, cement with such long lifespans were widely used during the Roman Empire)
As an FYI for HN, many of y'all are probably eligible for $400-800 of Handshake coins (HNS). Handshake is airdropping coins to open-source developers to incentivize them to check out the project. If you have over 15 followers on GitHub you can use this tool to claim coins. This is a no-strings-attached giveaway so if you want to you can also sell your coins but it'd be worth it to bid on your name before you do. You can also reach out to me at tieshun at namebase.io if you have questions about the airdrop or Handshake itself.
I thought about it for a minute, then quickly skipped it when I saw the instructions. If you are hoping that free software devs will help bootstrap this by using it then you'll need to make that process much easier.
Also ENS (Ethereum Name Service) on the ethereum block chain is really cool, though its more for resolving to swarm hashes or block addresses... which are for decentralized documents and apps.
This all looks and sounds really great but I have one big question. If this requires a proof of work chain, why not just build it on top of Bitcoin?
Then you wouldn't have to convince people to spin up a new node for a separate chain. This seems like an obvious choice to take advantage of Bitcoin's network effects and inherent chain security.
You could even lock up some bitcoin and issue bitcoin-backed Handshake tokens and continue operations as normal.
74 comments
[ 3.5 ms ] story [ 135 ms ] threadENS domain names can mainly be used for payment for now, so I'd be sending crypto to [domain].eth where the advantage is having a readable address instead of a random-looking string.
You can also host web pages on it (which I believe is helped by their IPFS) but that has seen limited use as of yet.
It can do that or it does do that? Also, ENS doesn't typically resolve to an IP but instead a swarm hash or a block address, what would end up resolving in those cases?
Not implemented yet, but this is where one would implement it https://github.com/handshake-org/hsd/blob/master/lib/dns/ser... https://github.com/handshake-org/hnsd/blob/master/src/ns.c#L...
No more rogue SSL certificates!
I get the "global, transparent, append only log" appeal, but for the reality of most people, I don't want to rely on a blockchain converging, or processing my update in a certain amount of time.
And that doesn't even cover companies (I don't agree with this, but it is a reality), that consider DNS entries private, and don't want to expose an easily scannable list of DNS entries .
Additionally, HNS also fixes the problems the CA system has today. CAs can generate certificates for any domain - even if the domain owner didn’t request it. This has led to countless occurrences of abuse.
Good luck with that. If there is no way to have a US court take ownership of a domain (or force someone to handover a bad faith registration), someone will either end up in jail for contempt, or it will just be banned.
> Additionally, HNS also fixes the problems the CA system has today. CAs can generate certificates for any domain - even if the domain owner didn’t request it. This has led to countless occurrences of abuse.
It fixes the non EV cert situation (kind of - CAA records also help this, and work on the standard internet), but doesn't fix EV certs (i.e. amzon.tld is actually Amazon LLC and not Scammers R Us Ltd.)
It also ignores the reality of most major companies in the world MITM'ing all outbound traffic from offices to ensure sensitive content is not exfilled from the company - there is 0 chance of them allowing traffic out that they could not MITM.
This same argument applies to bitcoin and it has not (yet) been banned in much of the free world.
I'm not totally sure how this one works but with ENS there are key holders that theoretically have the ability to do operations on any entry but it takes a certain number of them to all coordinate and agree.
We have seen this before, where people who run these services are personally held in contempt until they comply with the order.
* I say "usually" because more complex permissions schemes are possible with Bitcoin Script. m-of-n in particular I could see being very useful; it could allow individuals to update some parts of the record but not all - for instance, make it mathematically impossible to abandon the domain or move where it's pointed, but still possible to update contact information.
I think it is great to have an alternative DNS system that is more censorship resistant.
So every time I add a new LB, or cycle out an environment I have to pay someone? And then wait for them to process the chain to publish the result?
Remind me, what did etherium get to for transactons to clear? 20 something hours? That is not something I want when I am trying to redirect traffic from either a set of NS records that are broken, or if I host the full zone in the chain, a broken AWS / Azure region.
Combine the time to wait for caches to refresh on the internets (better these days, but still longer than people would like), with waiting for a blockchain to publish my new records, and you have ops people in pain.
DNS is already one of the largest fault tolerant, eventually consistent, cachable, federated, and globally distributed key value databases ever to exist - we don't need to add blockchain to the mix.
I don't see how this follows at all.
The slowing transaction incorporation times for major cryptocurrencies is related to transaction volume, not to the total size of the chain to date. Presumably a system restricted to updated HNS entries would not encounter anywhere near the same transaction volume.
From what I've heard, the "Layer 2" networks for even the most venerable of blockchains have the potential to reduce transaction times a couple of orders of magnitude.
A pretty small price to pay for the superior features.
For private info perhaps DNS will continue to work just fine for companies. Theoretically you can also host private block-chains and use that if you really wanted to.
I am still trying to figure out what superior features these are, even for me as a small sites.
For certs, I can have Lets Encrypt, and set a CAA record of letsencypt.org. For DNS, I can host my own, or use one of the myriad of providers out there.
I am not likely to have my domain taken away from me (and neither are most people), so the DNS ROOT switch is not a draw.
Why would I move to a DNS ROOT with no one on it?
> The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network.
> While DNS is already fairly decentralized, the centralization exists because of ICANN’s gatekeeper control .... ICANN ultimately has control over what internet names are acceptable – and serves as a singular point of failure.
That is what this is doing.
> Handshake is a decentralized, permissionless naming protocol compatible with DNS where every peer is validating and in charge of managing the root zone with the goal of creating an alternative to existing Certificate Authorities. Its purpose is not to replace the DNS protocol, but to replace the root zone file and the root servers with a public commons.
- https://handshake.org/
- If I buy a TLD, will I own it in perpetuity, even after I die?
- If we're encouraging people to register their own TLDs, won't we run into the same limited-name/squatter problems as normal domains? I get that names are being released at a trickle, but that seems like it would just put off the problem a bit.
- Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue?
- Is Brave the only browser looking into this, or are we also seeing buy-in from browsers like Firefox and Chrome?
I'll read through whitepaper and learn the details, but if possible I'd like to know if it's worth my time to do so.
I'm not necessarily feeling great about the idea of having separate TLDs for every site, but I'll admit there is something attractive about being able to register 1 TLD as a namespace, one time, and then using subdomains for every other site I ever make. It's just not clear to me how that system would scale.
No, if you don't send a renewal transaction, the name goes up for auction again.
> - Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue?
Yes, it's proof of work
> I'm not necessarily feeling great about the idea of having separate TLDs for every site
TLD owners manage the namespace as they see fit. that includes issuing/selling/giving away sub-domains. <subdomain>.<TLD namespace>
- Yes, names are rolled out over 52 weeks based on the hash of the name (modulo 52), which was designed to prevent squatting. The auction & renewals processes should help as well.
- Yes, Handshake uses proof-of-work. It's a different algorithm (Blake2b keyed with KMAC256) than Bitcoin but still essentially relies on energy consumption for security.
- I'm not aware of any other major integrations. But it is easy for users to run their OWN local light client and use it as the DNS resolver for their OS: https://github.com/handshake-org/hnsd
Can't this just be automated?
Second, Handshake is airdropping 70% of the mainnet coins to open-source developers. If you have over 15 followers on GitHub, you can claim around $400-800 of Handshake coins (HNS) with no strings attached. Not only will this give developers an incentive to check Handshake out, but also this ensures that the bidding power is spread out at launch. Without this mechanism, a whale could spend $10mm on HNS at launch and outbid everyone.
Compiled hnsd and tried to run it on local machine and an ec2 spot instance but it keeps failing to connect to it's (hardcoded?) peers.
I keep seeing this,
peer 354 (172.104.177.177:13038): failed connecting: connection refused peer 354 (172.104.177.177:13038): closing peer peer 354 (172.104.177.177:13038): closed peer peer 355 (139.162.183.168:13038): failed connecting: connection refused peer 355 (139.162.183.168:13038): closing peer peer 355 (139.162.183.168:13038): closed peer peer 353 (172.104.214.189:13038): failed connecting: connection refused peer 353 (172.104.214.189:13038): closing peer peer 353 (172.104.214.189:13038): closed peer peer 352 (173.255.209.126:13038): failed connecting: connection refused peer 352 (173.255.209.126:13038): closing peer peer 352 (173.255.209.126:13038): closed peer peer 357 (172.104.177.177:13038): failed connecting: connection refused peer 357 (172.104.177.177:13038): closing peer peer 357 (172.104.177.177:13038): closed peer peer 359 (139.162.183.168:13038): failed connecting: connection refused peer 359 (139.162.183.168:13038): closing peer peer 359 (139.162.183.168:13038): closed peer peer 358 (172.104.214.189:13038): failed connecting: connection refused peer 358 (172.104.214.189:13038): closing peer peer 358 (172.104.214.189:13038): closed peer peer 356 (173.255.209.126:13038): failed connecting: connection refused peer 356 (173.255.209.126:13038): closing peer peer 356 (173.255.209.126:13038): closed peer peer 363 (172.104.177.177:13038): failed connecting: connection refused peer 363 (172.104.177.177:13038): closing peer peer 363 (172.104.177.177:13038): closed peer peer 361 (139.162.183.168:13038): failed connecting: connection refused peer 361 (139.162.183.168:13038): closing peer peer 361 (139.162.183.168:13038): closed peer peer 362 (172.104.214.189:13038): failed connecting: connection refused peer 362 (172.104.214.189:13038): closing peer peer 362 (172.104.214.189:13038): closed peer peer 360 (173.255.209.126:13038): failed connecting: connection refused peer 360 (173.255.209.126:13038): closing peer peer 360 (173.255.209.126:13038): closed peer
Also, These IP address are either blocking ICMP ping messages or outright unreachable because ping fails to talk to them.
https://hnscan.com/peers
Try this command, It contains a list of peers that were working few hours back. Maybe they are still online.
How will one go about this? I'm interested, if only for the purpose of claiming a few domains that I have a personal interest in.
If you want an easier way to claim and use your coins I can also add you to our private beta for Namebase.io. Just ping me at tieshun at namebase.io.
Do you know if these users will still receive the tokens they signed up for? Should these tokens show up on testnet?
Sooner or later, any servers get hacked, and attackers can get the private data stored there. If this happens, is there any way to recover the TLD? Or are we going to end up with a network where many names point to ransomware pages?
(Incidentally, cement with such long lifespans were widely used during the Roman Empire)
https://github.com/handshake-org/hs-airdrop
https://github.com/handshake-org/hsd
The existing TLDs will continue to be held by the existing TLD holders. So, as an example, news.ycombinator.com will still work!
This is truly a drop-in replacement of the DNS ROOT giving power back to the people.
Also ENS (Ethereum Name Service) on the ethereum block chain is really cool, though its more for resolving to swarm hashes or block addresses... which are for decentralized documents and apps.
https://manager.ens.domains/
Then you wouldn't have to convince people to spin up a new node for a separate chain. This seems like an obvious choice to take advantage of Bitcoin's network effects and inherent chain security.
You could even lock up some bitcoin and issue bitcoin-backed Handshake tokens and continue operations as normal.