Can you name some examples?

> attempting to sell the Brooklyn Bridge

Handshake reserved the top 100,000 Alexa domains and allowed all trademark name holders to claim theirs.

Not to mention the ten million in FOSS grants for developers to build tooling

Sadly the ideologues will somehow decry their attempts for an alternative while defending the indefensible ICAAN.

What about everyone else after the 100k? What recourse are they left with when their domain is/was taken by another party? Which party should own the domain? How would doubly registered domains be resolved?

They will remain on their original tld, so brand.com will remain brand.com, they just won't automatically receive their own brand tld, unless they manually start the auction themselves.

so those below 100k were not reserved, a squatter bought their brand tld, what recourse do they have? What about new brands that have reached the 100k mark since the great reservation?

if a brand was not significant enough to reach internet search significance why should they be entitled to their own tld? why should be some company "co" from country x be more entitled to their own tld than the company co with the same name from country y? If they feel they are, they can a) manually start and win the auction b) buy the tld c) use an alternative like .brandHQ,.getbrand,.usebrand or whatever c) just keep using their original domain brand.com, which is the most simple and straight forward solution that requires no effort on their part.

By your logic the evolution of the internet would forever stagnate because developers would be stuck reserving an infinite amount of tlds that keep on popping up, it's just unrealistic and not pragmatic. reserving 100k of the most popular domains is a good faith effort and a pragmatic solution.

this is the attitude that makes the handshake community untenable

> By your logic...

Did you mean by your imagination to put words in another's mouth? Your ability to ascertain (assume?) so much from an internet question is impressive

Am I supposed to respond to your half baked thoughts that do not even amount to an actual argument with a counter argument when there is nothing to counter?

Try putting some effort into formulating an argument, this behavior of yours won't cut it.

Was I trying to make an argument?

I'm pretty sure I was asking about edge cases that are hard to deal with so that I might understand how the other party thinks before formulating deeper opinions.

Are you seeing straw men where there are none?

>Was I trying to make an argument?

No and that's exactly the problem, we're not on reddit. You asked me a question and I elaborated in a detailed manner to which you responded in a low quality manner with no substance which was just name calling.

>I'm pretty sure I was asking about edge cases that are hard to deal with so that I might understand how the other party thinks before formulating deeper opinions.

I gave several perfectly valid solutions that are pragmatic and realistic, if you don't like them, then you can point them out and explain your reasoning but resorting to hand-wavy rants won't be constructive or helpful for any serious dialogue.

> why should be some company "co" from country x be more entitled to their own tld than the company co with the same name from country y?

Because in some cases, that is the rule. See Rule #5 https://github.com/handshake-org/hs-names

> if a brand was not significant enough to reach internet search significance why should they be entitled to their own tld?

Why should any brand be entitled to such things?

> but resorting to hand-wavy rants won't be constructive or helpful for any serious dialogue.

Can you quote where I did this? I could for you

> Because in some cases, that is the rule. See Rule #5 https://github.com/handshake-org/hs-names

How does the rule in any shape or form contradict what I have stated? It says: "The domain must not collide with a higher-ranked domain. For example, google.co.uk would lose to google.com. Only the owner of the higher-ranked domain is able to redeem it"

Point is that many developers invested a lot of time and effort into establishing rules for reservation to maximize fairness, so when a domain is not reserved my statement above applies: why would some company co in country x be more entitled to the one in country y? After all the reservation rules have been applied and determined some specific reservation outcome. There are some proposed solutions in that case too, some of which I have outlined before.

>Why should any brand be entitled to such things?

Exactly, but you are the one making a fuss about in the first place.

>Can you quote where I did this? I could for you

I already did, it's your rant directly to my long elaboration to your question. I'm not going to further entertain your flame baits, everybody can see how much effort each of us put into thoughtful responses and can judge accordingly.

>Why should any brand be entitled to such things?

>> Exactly, but you are the one making a fuss about in the first place.

Does this mean you believe there should not have been any reservations?

No, I was merely jestingly pointing out the inconsistency in your thinking.

> No, I was merely jestingly pointing out the inconsistency in your thinking.

How are we to believe anything you have written is in good faith?

Can you explain my thinking and where it is inconsistent?

Oh, that's nice of Handshake. Definitely it makes sense to me now that Handshake should be able to sell the domain namespace! Why not, if they're going to donate to FOSS?

My question to you is: if I donate MAC addresses to FOSS projects, can I tokenize ARP? I promise to be nice about it. The first 10,000 IP addresses can have their ARPCoin for free.

Thomas, I’m not sure what you mean when you say that certificates are free. Self-signed certs are free, but only situationally useful in a business context. Let’s Encrypt certs are free, but not usable in all contexts. GoDaddy, Namecheap, and Verisign will still gladly charge $50-$1500 for certs will various features like $50/SAN, and extended validation. If you want to terminate TLS at an AWS managed edge resource, the happy path is ACM. These are “free”, but arguably you’re paying for the cert with the load balancer or edge resource.

There’s no difference between a blockchain and a cryptographically secure write ahead log, indeed that is how blockchains are defined. Perhaps you assumed that I meant cryptocurrency when I said blockchain? I did not.

(Sorry for the delayed reply.)

Tell me more about the contexts in which you can't use LetsEncrypt certificates.

Older OS. Certbot only supports a limited number of OS (centos 6 not so much). Longer expiry dates.

Certbot isn't the only way to automate Let's Encrypt certificate issuance, and even if it was, you can use hooks to have certbot push certs to other machines.

Sure - for example, when the organization requires an OV or EV certificate.

Yeah, and that happens where?

What’s the use case for OV/EV certs? I thought it was reasonably well established that they herald from the same era as “this site secured by Symantec” icons, and were basically just the same security as DV certs but with the wheels painted chrome and an extra tax for gullible buyers.

It doesn't matter, right? Because anyone who relies on OV/EV certs has chosen to rely on OV/EV certs. If we replaced the whole WebPKI edifice with a blockchain, they'd still make the same decision not to trust the baseline system.

When we talk about the WebPKI being coercively annoying, what we're really talking about are the roots of trust that the browsers have chosen to trust. No browser requires OV/EV.

Yes, a baseline system built on a blockchain could support the validated identity and KYC features of OV/EV certificates. Indeed, this already exists in Sovrin (sovrin.org).

The use case is knowing that a server is owned by who it says it's owned by as validated by a trusted KYC provider. For example, Stripe has an EV cert. Let's Encrypt does not support OV/EV because they cannot automate the KYC checks. Let's Encrypt is focused on the encrypted connection use case.