>The evaluation fee is US$185,000. Applicants will be required to pay a US$5,000 deposit fee per requested application slot when registering. The deposit will be credited against the evaluation fee. Other fees may apply depending on the specific application path. See the section 1.5 of the Applicant Guidebook for details about the methods of payment, additional fees and refund schedules.
There's a nonzero chance that the investment could be a dud if people simply don't like the TLD, the same way how no one (except a few people [1]) like the .bike TLD.
It literally happened to me yesterday, setting up a VM and aliasing it to a .dev domain for local testing. Took me an hour to figure out what was wrong =/
This seems like one of those anti-patterns that has been passed down by blog posts and from engineer-to-engineer. I've seen this in almost every single developer team I've been apart of.
Either way, like you said, people should be using .test so you don't have to worry about future collisions.
Most likely the registry won’t let you buy trademarked domains if you can’t prove you have the trademark. There is a period set aside for tm holders.
I would stay far away from any brand or tm domains at any time. You will eventually lose the domain through a udrp. And you could likely get sued as well.
Besides the usual disregard decency let's HSTS preload a TLD people have been using for local development for decades...
This is terrible gatekeeping and I hope Google perishes soon. Wow. I can't get over how fucking dumb this is.
This is the mark of a corporation filled with people that thinks putting a price tag on supposedly scarce good early will deter bad actors. Clearly everyone who thought this up has way too much money in their account.
Yes, this, though I really am disappointed in ICANN here. ICANN should not have sold a TLD known to be in heavy use already. Their desire for cash from this process seems to have overwhelmed their good sense in managing the domain system.
Yeah, well. That's got nothing to do with .dev. All the new TLDs are fucking dumb. Just a cash grab for the ICANN. Might as well get rid of TLDs altogether.
Honestly I don’t think it’s a cash grab for icann. There are plenty of registries that are making plenty of money, as well as domain owners selling the domains in the aftermarket.
The reason the new tlds were needed is the lack of options for buying a new domain. I know plenty of smaller biz and startups who couldn’t get the dot com they wanted and ended up choosing a really good keyword rich new tld.
Is steampowered.com sketchy? Even incredibly large companies often can't get the domains they want because they were bought twenty years ago by some Joe Schmo.
If you've been using .dev for local development, that means you've either been setting it in your hosts or using your own DNS server until now, which you can continue to do with a .dev TLD.
if you have the technical savvy to be using .dev before the Google deployment, you have the technical savvy to install an additional root cert for use with Chrome.
Sorry but this is pure malice by Google. I can invert this argument by saying if you're buying a .dev domain you have the technical savvy to get on an HSTS preload list, except you haven't broken anyone's workflow.
EDIT: And I mean... have you USED openssl's x509 toolchain? That's a few steps up from editing the hostsfile.
Editing the hosts file isn't a solution for internal use in organizations.
If it's just you, editing your hosts file, switch to .local or whatever. There was always a chance when using a "local" domain (which isn't actually some sort of standard) that such a TLD could be created in the future. If it's for an organization, create the root cert, and have that be one of the steps users need to take in order to access the dev site. Or just switch to .local or .test or .whatever.
I've been using .dev as a local test environment for years too, but I'd prefer to have more TLD options available and just switch to .local or .test because I'm not averse to change.
.local is reserved for multicast DNS/zeroconf, by the standard. You literally can’t use it on macos because it will always try to look it up in with mDNS first, and only fall back on /etc/hosts once that fails.
If you use .local for fake DNS for a dev setup, you’ll probably notice lookups are slow; that’s why.
(This is why I’ve always used .dev actually, although this may make me switch to .fuckgoogle or something instead)
Maybe you've never been in an environment where having to change internal domains is near impossible.
I work at the intersection of 3 corporations within our group. We provide a sort of "internal Heroku" using Kubernetes for anyone in the group that needs it. We recently ran into the 63 character limit on domain name labels (we have to use a wildcard cert because nothing else is approved by legal). You wouldn't believe the time developers would've had to spend on fixing the domain schema across hundreds of services if we hadn't found a way out of that dilemma. We're talking thousands of internal names, some of them given our to external partners (we use a partially publicly resolvable name, but we could've exposed our DNS as well) and some used in systems long forgotten.
That is such specious logic it’s kind of sickening.
I use TLDs like .dev exactly because it’s convenient. Not because I’m “savvy”, and even if that were true, it doesn’t follow that it would be just as convenient to set up a local CA.
Using `echo ip >/etc/resolver/dev` to have a custom dns server for everything in the .dev domain is trivial. It’s one command. Getting a custom CA for all of that is not.
What's sickening is devs pretending their broken workflow is important (or should matter) to anyone else, and then getting fussy when it turns out that no, their non-standardized workflow is, in fact, not a standard.
Using .dev for local development is a bug, not a feature. The only reason it was used is because it wasn't yet a TLD . Not because it had some sort of special status as a "Local TLD".
One man's "convenient" is another man's "savvy." If you've got the technical ability (you are 'savvy') to use this TLD, you've got the technical ability ('savvy') to use your own CA.
And I didn't say it would be convenient. The world doesn't revolve around your convenience. I said you've got the ability to use a CA.
Except that both Firefox and Chrome ship with the ENTIRETY of .dev on HSTS preload lists, so it'll be impossible to use those domains without clients either installing a CA or owning the domain and getting a cert.
Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?
Yeah sure takes one minute, one minute of wondering if you really wanna bash your head against a wall getting openssl to spit out an X509 cert and then some.
You mean wait six to eight months for the IT security department in another division of the company in another state to -maybe- approve my cert request.
Not all web development is three guys on Linux laptops at WeWork.
If you're a big org, presumably you could just get your org to just buy the TLD if it's that much trouble.
Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
> The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host.
Plus "DNS related code" can be stretched pretty far to "code that uses DNS." so it's the one I prefer.
The only thing I wish was easier was having a TLD for network local names but not link-local names. I typically just buy a name for that but it seems clunky since any in-use name that uses public DNS TLDs I feel ought to be DNS server independent.
An internal network might not be a LAN - for example, it might be a company's entire internal infrastructure spread over three offices and a datacenter with VPN.
If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services.
You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.
Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.
.test also works, but I like .dev more, so I have and continue to use .dev via hosts file (edit: hearing Firefox is doing the .dev HSTS preload as well, that's very disappointing to hear.)
I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.
If you like .dev so much instead of .test, why not use something like subdomain.[public-domain].dev.com for all of your dev use?
It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
Who bought it is irrelevant. It could have been released to the public in a similar way to .com and the same issue would remain.
The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow.
Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
One company I worked at thought it would be a good idea to use .local for their global internal network.
Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.
Google weren't supposed to make it generally available. From their application[0]:
> .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.
"Our ML predictor calculated with 95% confidence that in the next 3 years your software will become our competitor, damaging our projected profits. We decided to terminate your domain ownership and auctioned it off to PigsDoAds Inc., effectively immediately.
Our ensemble of customer support chatbots wishes you a wonderful day!
"
Good question. Nobody seems to know the answer here.
HN seems to be generally knowledgeable, but in this case nobody seems to be able to provide answers with good references, just guesswork. Google operates the domain. How much regulatory power it has? What is the agreement with ICANN. What is the dispute solution mechanism?
----
edit
after looking around, operator agreement with ICANN seems include public interest commitments etc. Operator can't do whatever they want and their policy should be transparent.
> Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies.
It's a nice way to earn a bit of cash from larger companies who do not want "company.dev" associated with porn or malicious content. Imagine if "unity.dev" or "disney.dev" pointed to a cesspool of viruses.
There are icann rules for launching a tld. There is a period for tm holders. Most companies are going to get their company.dev during the tm period. If they don’t, three is always the udrp process.
So big companies with big money won't have to shell out cash because there's a TM period for them but smaller one got to buck out 10,000 bucks to prevent cyber squatting ?
A domain just for developers! Until it abruptly shuts down Feb 19, 2021. Why would anyone trust Google with something with any kind of long-term requirements as important as a name? They should have registered ".chump" instead, because that is really what users of a Google-managed TLD are declaring
"Dear VALUED developer, thanks so much for being a part of the .dev experiment! After a long hard period of staring at our shoes, we realized we cannot extract sufficient value from our users in this manner. As of midnight, your name will automatically be migrated to our newer, better, faster TLD, .plus, the future of the open web"
A TLD "with benefits" from Google is a money-printing press. While Google has a certain track record, this makes it rather unlikely for them to discontinue it in the near future.
I mean, I get your point, but I think this is a meme exclusive to HN. Other than Google Reader, there really isn't much Google has shut down without having a newer, better product you can transition to.
When it comes to something like this (AKA not a consumer product, makes money, relatively easy to run, etc), I genuinely can't see them shutting down a TLD like this.
If anything, the complaint should be the lack of official support you should probably expect for it.
Also, can I add Google Code Search? That thing was such an incredibly valuable resource for figuring out how to work around inane edge cases in eg GTK. Just search for the function that's giving you issues, and find a dozen projects with extensive comments describing their workarounds.
This is an amazing list. It might not be 100% fair since a few products got replaced with something better, but I think most didn't.
Fundamentally, Google is just an advertising company that happens to employ very smart people. If you go to work for Google, you have to understand from the outset that you're working for an advertising company and you're not going to change the world. You might be allowed to work on a fun project, but if it doesn't directly serve the needs of advertising it will be shut down. But hey, it'll look good on your resume.
The 'Google Graveyard' meme is known far and wide beyond HN - I'm a long time member on a [n ostensibly] design-focused forum where it's been a long time running gag (of the acerbic kind) too.
Somebody makes this post on every HN thread involving Google now. But the three big public deprecations I'm aware of are Reader, Inbox, and G+. All consumer products. All the other stuff on that killed by Google site is stuff I've barely even heard of, and all consumer products.
To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN meme at this point.
It hosted repos, and broke links to those repos and links within them. It also broke processes that relied on the repo, e.g. automatic issue creation in CI, but that's less serious.
Setting up a redirect works if you are the administrator of the project...and are still alive. Migrating a project was simple if it didn't have a wiki. There are a lot of details that caused some real headaches. I remember it being like a mini Y2k at the time, and there's no telling how much we just collectively lost from it.
This is simply incorrect. As the person who (led? handled?) the shutdown/archiving, the vast majority of the 'developer' web had gone to github. The handful of active projects were given white glove treatment once we decided to shutter the site.
> the vast majority of the 'developer' web had gone to github
I see hundreds of thousands of repositories on Github responding to the search "Automatically exported from code.google.com", which means they only transferred _after_ the shutdown was announced (when the export tool went live). Any wikis would have had to be hand-converted to not be broken, since the markup between the two systems was not compatible. I mean, thank you for handling it as well as it was handled, and thank you for (if you were part of that) the export tool, but let's not pretend that it wasn't disruptive.
The famous app engine pricing increase happened when app engine left preview. People still mention it often, but it was never meant for production usage while at the preview price.
> To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN meme at this point.
It's not like these complainers actually read articles they're commenting on. You could see this in the Chromecast DNS rantfest - the path is "Google in title => rant about your pet peeve" not "Read article => complain about topical thing".
I don't think this is a huge concern - at least ICANN has the power to designate a successor registry, and I guarantee someone will break down the doors trying to get that particular gtld.
I recently found out that the sidebar menus on pages within https://developers.google.com/web don't work with JS off (usually a trivial thing: show sub-items by default and hide them with JS). Almost every Alphabet website has something like that.
So yes, minor anecdote, and I genuinely appreciate the hundreds of Google employees who really help the Web and share useful knowledge (and don't lead developers into using techniques best suited for billion-user websites, as FB often does) but I'll reserve to right to side-eye anything Google says.
There's nothing about Safari that makes it "the new IE8". Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.
Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.
HN is quite diverse and I'm pretty sure those are two disjoint sets of users. (I'm in the former group myself --- not a fan of presenting information in such a way as to decrease its accessibility while also increasing resource usage.)
I bet I could make those accordion sections work in all browsers going back to IE5 without much effort, and use nothing near 120KB of JS to do it... but no, most "modern web devs" would rather pile on the bloat of their libraries and "best practices" to make something that works only in the very latest version of the one browser they personally use.
Your post shows the big difference in mentality that's partly responsible for why we see so many broken sites --- I haven't ever used those tags before and would just go for plain old DOM style manipulation with JS (which has been around for a very long time), whereas you started with something much newer and took backwards-compatibility as an afterthought to be added on. Your solution requires less initial effort (providing you knew about the new tags) but then additional effort to work on older browsers --- that might not even be done --- whereas my solution may take a little more effort initially, but then naturally doesn't need any further considerations for backwards-compatibility.
Why would anyone use an older browser? (Other than IE in old firms - but this is probably becoming rarer and rarer) I guess everyone should upgrade their browser regularly, at least to get security upgrades
My mentality is to make the website usable without JS for most people (with the reasonable effort of installing FF or Chrome at most), then use as simple and compatible JS as possible if needed. Thus, old-style DOM fiddling isn't the first choice - and if we're talking very old browsers, it was also tricky to get right due to all the incompatibilities.
Why you think something would be broken when a polyfill is used as fallback, I don't know.
It's support for video codecs is pretty limited, and has been for a long time, but I think you're right about most of the other things being very new "standards".
Also the site claims to about “web fundamentals”, but the content pushed out are all articles about cutting edge, experimental features in Chrome. There’s nothing wrong with documenting new features in your browser, but calling it fundamental is fundamentally misleading.
Also, the navigation and some other parts aren't usable with ad blocker enabled, since there are no non-JS links/anchors. Embarrassing for an entity that once tried to position itself as a supporter of usability and user-friendly web pages.
<SUPPORT_PERSON>12:53 PM
Thank you for contacting Google Domains. My name is <SUPPORT_PERSON> and I'll be happy to assist you. Let me quickly read your notes here.
<SUPPORT_PERSON>12:54 PM
Hi there
<SUPPORT_PERSON>12:54 PM
How are you?
<ME>12:54 PM
Hi. I'm trying to read your website but it's broken in one of the dominant web browsers in the world.
It works great in Edge, Firefox, and Chrome on my PC. I think he's too high up on his horse to realize that the problem may be on his beloved religion/platform.
Seeing the organisation name next to the lock icon definitely gives me an extra layer of warm and fuzzy feelings. I’d say it has some value for those that can pay for it.
You are talking about EV certificates. OV-validated certificates require (the best case) the user to click on the padlock icon to reveal more information about the certificate.
It might sound useless for those who doesn't know what it is.
However, for those who does it is very useful and getting more useful.
Browsers might (if not yet, coming soon to you) raise red flags if you try to use a website whose certificate was signed by a rogue CA that, according to DNS instructions, shouldn't be able to do so for that domain.
Browsers might demand OV from high profile websites in theory.
> Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.
I buy them. I don't like paying for them, but I want a certificate I know will just work for years without having to run certbot or one of its clones on my server. Well, that and LE didn't yet allow wildcard certs when I bought mine. They've already dropped their maximum validity from three to two years though, so I'll probably throw in the towel when they further reduce their validity to less than six months.
A certificate that last for years... That's exactly how you end up with a certificate that expired and no one realized. An automated process is a way more reliable.
ACME is an open protocol (and very soon it will be an IETF Internet Standard too). There are many alternative implementations. Just find one you trust.
We actually did our own DNS-based implementation for our infrastructure.
I don't want to run someone else's code on my server just for this (the default certbot wants root access too, yikes), nor do I want to analyze someone else's implementation before running their code, and I sure as heck don't have the time, patience, or interest to write my own implementation of ACME just for the one service that uses it.
I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.
Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
ACME protocol is fairly straight forward to implement, and you can easily write your own implementation with existing code (OpenSSL, Apache/nginx, etc).
With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.
I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.
Most likely the domains like tmp.dev, staging.dev, and production.dev are premium domains that will never be released by the registry.
Many premium domains are held back by the registry, which are a part of icann rules. Those domains are typically not able to be registered and used by anyone.
I'm not familiar with ICANN rules, but I wonder if a company can do whatever they want to a gTLD once it's accepted, even if it's not within the intended usage in the gTLD application? As far as I know, Google said they registered .dev for internal use and for Google-related products and it will be completely closed to Google, according to their application[1]:
> The mission of this gTLD, .dev, is to provide a dedicated domain space in which Google can enact second-level domains specific to its projects in development. Specifically, the new gTLD will provide Google with greater ability to create a custom portal for employees to manage products and services in development.
> Charleston Road Registry intends to operate the proposed gTLD as a closed registry with Google as the sole registrar and registrant. The goal of the proposed gTLD is to allow Google to manage the domain name space for its projects in development. The proposed gTLD will provide Google with the ability to customize its domain and website names for its projects and signal to users that .dev websites are managed by Google
> Charleston Road Registry believes that given its intended use by Google, the .dev gTLD will best add value to the gTLD space by remaining completely closed for the sole use of Google.
…and now they're opening it up to the public... :\
I always thought gTLD has the same restriction as sTLD (for example, .aero is strictly for airline-related domains, or .mobi that must be optimized for mobile, which TBL strongly disagrees[1], etc.) but in reality I guess it's more like ccTLD where they're free to do whatever they want with the domain.
It's not a TLD, it's either a single-label hostname or a fully-qualified subdomain (both will resolve internally, the former obviously won't resolve externally but the latter will, you'll just get an auth error).
Having used "sudo vi /etc/hosts" to add .dev domains, this gets no <3 from me.
I'm going to avoid buying one, but if there are any popular .dev domains I hope I will forget about it before long. I don't want negative feelings from this so often. On the other hand there are plenty of reminders of negative things in politics and the environment, so I guess I've gotten used to it and developed outrage fatigue.
At least you aren't directly accusing me of failing to RTFM!
I've been vaguely aware of what's in that RFC, but I don't think reserving those TLDs for local stuff means that other TLDs are off limits. I certainly don't use example.com for all example emails. Developer happiness comes first.
I got burned by going with domains outside that doc, but I think the blame goes on Google, not on those who decided to use .dev without making it an official standard. I think if it was an official standard Google might still have muscled their way into getting .dev, and I wouldn't be surprised if they do the same with .test in the future.
I'm a developer too, I always use example.com because accidentally triggering bogus outbound mail from corporate IP addresses can make a mess for Operations.
And Google gets baseless accusations because you feel entitled to something. Enjoy the feeling, you're entitled to it.
We have RFCs for a reason, so people follow predictable behavior everywhere. And so you don’t build up a ton of work/customization and then suddenly have a surprise like this. Worse, you embed that custom design into a system and then leave and someone else needs to fix that mess.
.test is what you should have been using, precisely for this reason.
Nope. Testing is a meaningful term in software development, and what I was using it for doesn't entirely fit into my concept of testing. Much of it was just development.
.dev domains will be available from many dozens of registrars, including most likely the one(s) you're already using. You'll for sure be able to get one.
I don't know how this stuff works, what gives google the ability to sell these domains early? Also why is everyone cursing google for taking their local .dev? Google is not the only place you can buy these. Namecheap has .dev in the works, and GoDaddy is taking pre-orders as well (I didn't keep searching but I'm sure it's available at many other registrars), but nobody is cursing and shaking their fist in the air at those services. So what does google have to do with it? Why are we all holding them responsible?
I reserved unix.dev for the regular domain reservation price, not the crazy "premium domain" price because unix.dev was not part of the premium domain list.
However, Google determined that no, unix.dev should be a premium domain, and "stole" the reservation from me (after I have already paid for it). They later added it to the premium domain list, and they asked me for $11k to keep the reservation.
TBH, I expected to lose the domain because of trademarks or whatever, but apparently it was simple highway robbery.
Btw, I didn't even get my money back, just "store credit".
It's just ironic that a domain squatter trying to profiteer, would complain that Google are profiteering. Yes, of course they do. The whole domain-registration "business" is like that, including OP above.
Hey, I just want to correct some misunderstandings here.
"Reservations" mean nothing. Google Domains is merely one of many registrars that have customers all vying for domains in the same namespace. A "reservation" just means that the registrar will make their best effort to attempt to get that domain for you at the specified price; it doesn't mean that some other registrar won't get it first, or that some other customer isn't willing to spend more and will get it on an earlier day of EAP.
Until the domain is actually created with you as the registrant, it isn't yours in any sense of the word. There are even registrars out there that will, upon acquiring a domain, auction it off amongst all of their customers who pre-registered it.
Does anyone know how the “premium” renewal prices are set and governed? I’m going through this right now with .app domains (also owned by Google). Apparently domains categorized as “premium” have a much higher yearly pricing, and how it’s priced is not specified anywhere on the registry website. I called a few registrars and they said that the premium pricing is set by the registry. What’s concerning is that the registrars admitted that there really isn’t anything stopping the registry from increasing the premium pricing at will.
Anyone have anymore info about this? Seems concerning that a registry has no restrictions on what they can do with pricing after an individual has invested into an expensive domain.
Are you saying the registry can arbitrarily change the .app domain renewal price without control, or that they can charge a different renewal price for different .app domains?
I've experienced weird price fluctuations with .io domain renewals in the past, but haven't owned one in a few years.
According to registrars, yes. So for example, let's say I paid $1000 for a premium .app last year when they were released. Renewal price is marked for something like $280/yr, which I didn't expect, because I thought the premium pricing was an initial purchase price only. I thought the renewal price was standard .app renewal rates.
When I called to clarify with a few registrars, they said that this premium price ($280) is specified by the registry (Google), and that there's no guarantee that pricing will stay at $280. I used a hypothetical, and asked them if it were possible for Google to raise the price to something like $1000/yr or $10k/yr, and they confirmed that there is technically nothing stopping the registry from doing so.
Yikes! My one was and still is $63.70/year. I wonder what makes a domain "premium" anyway, and what makes it more or less premium? Never even seen a live .app domain anyway so that sort of makes them not premium at all.
One criteria I've seen used to price domains as "premium" is shorter names and popular dictionary words. Not sure if this is consistent across registrars, but I would think "premium-ness" is established at the registry level.
It's unclear to me if premium-ness is a function of time, and/or if there's an objective formulaic criteria here.
What registrar did you use? They should have made it very clear during the checkout flow what the annually recurring charge was. Can you try it again now with persona.app (another premium) and post a screenshot of what exactly they're displaying?
AFAIU, the ICANN New gTLD registry agreement means you can't have "premium" prices for renewals:
"Registry Operator must have uniform pricing for renewals of domain name registrations (“Renewal Pricing”). For the purposes of determining Renewal Pricing, the price for each domain registration renewal must be identical to the price of all other domain name registration renewals in place at the time of such renewal, and such price must take into account universal application of any refunds, rebates, discounts, product tying or other programs in place at the time of renewal."
Hmm, this definitely isn't the case for .app. There are numerous tiers of pricing as of right now. Google categorized specific names as "Premium", which you can see when searching for a lot of .app domains. These Premium domains vary in both initial purchase price AND the yearly renewal. One of my examples is in this thread. Purchase price was around $1000, yearly renewal is $280. Other names are even higher...
Ah, yes, the (c) clause says they can charge you more if you agreed to it "at the time of the initial registration", but not after you have invested in the domain.
But I suggest people read the whole article themselves, I have no industry expertise.
Premium names are common across the domain industry. Different registries handle them differently (some have an up-front cost whereas others like us use annually recurring), but the registrar you're using should be making it very clear what costs you're signing up for during the registration flow.
I'm unsure how it is determined but when I asked my .app registrar they said it should be $120/year for each renewal, which was less than I paid to register it. Guess I'll find out.
I believe in the original .app launch thread on HN they stated that premium domain pricing was based on machine learning. So...who knows.
There are also Indian (male) names that are just “Dev” or that end in “dev”. The word means deity or god. There could be many Indians buying these when early access ends on February 27.
Shows up for me on firefox and chrome on windows. Also, safari (and maybe chrome on macos as well) doesn't show scrollbars unless you're actively scrolling, so it's easy to think there's no scrollbars.
Are you on a mac? 99% of times it's because of an external mouse connected.
edit: the css for the element that overflows has: `grid-template-columns: 50vw 50vw;` and based on the spec: https://www.w3.org/TR/css3-values/#viewport-relative-lengths, scrollbars are not taken into account, therefore as long as you have a _forced_ scrollbar, the content WILL overflow regardless of your screen size.
By forced I mean a scrollbar you cannot remove and that's not enforced by your systems settings, you can clearly see this behaviour on mac if you toggle the "Show scroll bars" setting to "Always".
Safari and webkit based browsers can avoid this issues with `::-webkit-scrollbar{ display: none}` but it's not a cross browser solution nor a wise decision to hide scrollbars overall.
- Cloudflare 1.1.1.1 doesn't prevent you from using 1.1.1.1 as a development IP, it just prevents you from accessing their service if you are. Google preloading everything to the HSTS list prevents you from using it without jumping through loops.
- The IP address 1.1.1.1 as a public DNS has clear value to the public, DNS IP addresses needing to be for 0-255 values that are memorable. .dev has no real public value considering the plethora of other tlds.
> - The IP address 1.1.1.1 as a public DNS has clear value to the public, DNS IP addresses needing to be for 0-255 values that are memorable. .dev has no real public value considering the plethora of other tlds.
Of course it has, TLDs that describes itself are valuable for some business, and this is exactly what this seems to be about.
Dutch auctions are incentive-compatible - they allocate the resource to the person that gains the highest utility for having it. Maybe Google got some of the people working on ads auctions to design this pricing structure.
Yeah, there are domain names out there that are so valuable that they've sold for eight figures USD. There definitely are domains that buyers (typically companies) are willing to spend well over $10k on acquiring. It's with this in mind that the EAP prices are set.
I remember people calling that a bit of a fiasco... was there anything theoretically wrong with the application of a Dutch auction for that purpose, or was it just that the underwriting community and their clients had every reason to make the situation look bad?
The price basically ended up being set by the underwriters because they big players bought most of the shares and bid at the price they underwriters told them to bid at. It wasn't really a fiasco, it just didn't accomplish what they wanted.
I’m, that’s an icann rule for launching new tlds. The early access period is always higher, then there are several other periods that happen before a tld gets to General availability.
This pricing structure is not just for .dev domains.
FYI, there is no ICANN requirement that any sort of auction be involved in launching a new TLD. We used to use a standard auction (called the landrush phase in TLD parlance), but have since switched over to a descending price Dutch auction because it's significantly less operational burden for us.
It's generally a good idea to have some kind of auction for the reasons the parent comment mentions, as it is a more economically efficient way to allocate the limited namespace to those who want it the most.
This assumes bidders have similar amounts of money to spend on domains, which may or may not true for any particular domain.
We can say that, when bidders do have similar bankrolls, whoever wants the domain the most is likely to buy it first. If they don't, whoever has the bigger bankroll will probably be able to buy it first.
> they allocate the resource to the person that gains the highest utility for having it
I don’t think that’s necessarily true. Any large company is able to drop a ton of money on something that has marginal utility for them, whereas a small business that would gain much more utility from it may be outbid just by virtue of having the wrong opponents.
474 comments
[ 175 ms ] story [ 1498 ms ] threadSection 2.2 https://newgtlds.icann.org/en/applicants/global-support/faqs...
[1] http://poop.bike
Last time I considered a new tld you are looking at about $500k in total costs, such as application, atty fees, and marketing fees.
That’s if it doesn’t end up in auction. Google paid $25m for .app, I believe.
https://security.stackexchange.com/questions/14802/if-someon...
But generally speaking a subdomain on a domain you really own seems like a better idea.
https://serverfault.com/questions/17255/top-level-domain-dom...
I’ve literally never ever seen any .home until now.
.test is the TLD you want, specified by RFC2606.
Either way, like you said, people should be using .test so you don't have to worry about future collisions.
I would stay far away from any brand or tm domains at any time. You will eventually lose the domain through a udrp. And you could likely get sued as well.
Despite Microsoft having a presence in the country, they still can't get .ba thanks to an incompetent registry in charge of .ba TLDs.
That sounds like one fee per domain to me
This is terrible gatekeeping and I hope Google perishes soon. Wow. I can't get over how fucking dumb this is.
This is the mark of a corporation filled with people that thinks putting a price tag on supposedly scarce good early will deter bad actors. Clearly everyone who thought this up has way too much money in their account.
The reason the new tlds were needed is the lack of options for buying a new domain. I know plenty of smaller biz and startups who couldn’t get the dot com they wanted and ended up choosing a really good keyword rich new tld.
Like if an app tried to register apppowered.com it would definitely hurt its image. Obviously massive players are above the rules somewhat.
Wasn't it $10k upfront to have your application for a new gTLD considered? This times ~1200 ... works out quiet good.
Sorry but this is pure malice by Google. I can invert this argument by saying if you're buying a .dev domain you have the technical savvy to get on an HSTS preload list, except you haven't broken anyone's workflow.
EDIT: And I mean... have you USED openssl's x509 toolchain? That's a few steps up from editing the hostsfile.
If it's just you, editing your hosts file, switch to .local or whatever. There was always a chance when using a "local" domain (which isn't actually some sort of standard) that such a TLD could be created in the future. If it's for an organization, create the root cert, and have that be one of the steps users need to take in order to access the dev site. Or just switch to .local or .test or .whatever.
I've been using .dev as a local test environment for years too, but I'd prefer to have more TLD options available and just switch to .local or .test because I'm not averse to change.
If you use .local for fake DNS for a dev setup, you’ll probably notice lookups are slow; that’s why.
(This is why I’ve always used .dev actually, although this may make me switch to .fuckgoogle or something instead)
Why not .fuckapple? Really, .local is defined for local address, if Apple is using it in a fucked up way this is an Apple problem.
.dev was never destined for local address, it was just because it wasn't registered in ICANN yet.
I work at the intersection of 3 corporations within our group. We provide a sort of "internal Heroku" using Kubernetes for anyone in the group that needs it. We recently ran into the 63 character limit on domain name labels (we have to use a wildcard cert because nothing else is approved by legal). You wouldn't believe the time developers would've had to spend on fixing the domain schema across hundreds of services if we hadn't found a way out of that dilemma. We're talking thousands of internal names, some of them given our to external partners (we use a partially publicly resolvable name, but we could've exposed our DNS as well) and some used in systems long forgotten.
I use TLDs like .dev exactly because it’s convenient. Not because I’m “savvy”, and even if that were true, it doesn’t follow that it would be just as convenient to set up a local CA.
Using `echo ip >/etc/resolver/dev` to have a custom dns server for everything in the .dev domain is trivial. It’s one command. Getting a custom CA for all of that is not.
Using .dev for local development is a bug, not a feature. The only reason it was used is because it wasn't yet a TLD . Not because it had some sort of special status as a "Local TLD".
And I didn't say it would be convenient. The world doesn't revolve around your convenience. I said you've got the ability to use a CA.
5 years ago no one would ever have considered .dev for anything public-facing.
I don't get what Google thinks they'll get out of sponsoring putting sites under development online.
Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?
mkcert is one.
Not all web development is three guys on Linux laptops at WeWork.
I'm trying to imagine a webdev workflow where you couldn't get a machine-local CA working.
https://docs.microsoft.com/en-us/windows/desktop/seccrypto/s...
Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
I believe .localhost is the "official" recommended TLD for local development.
> The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host.
[1]: https://tools.ietf.org/html/rfc2606
This one looks the safest and least prone to confusion.
> ".example" is recommended for use in documentation or as examples.
> ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.
Both of these look problematic from a terminology standpoint, not a technical one.
The only thing I wish was easier was having a TLD for network local names but not link-local names. I typically just buy a name for that but it seems clunky since any in-use name that uses public DNS TLDs I feel ought to be DNS server independent.
There is a draft RFC to reserve .internal for this purpose, which I think makes a lot of sense.
https://github.com/wkumari/draft-wkumari-dnsop-internal
1: https://tools.ietf.org/html/rfc2606#page-2
If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services.
You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.
I’m not the OP, but I’m in the same boat.
Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.
I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.
It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow.
Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
https://twitter.com/byuu_san/status/1096885634923294720
Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.
> .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.
[0]: https://gtldresult.icann.org/applicationstatus/applicationde...
I don’t think they will, but buying a domain from a company that’s so involved in politics doesn’t seem wise.
Our ensemble of customer support chatbots wishes you a wonderful day! "
HN seems to be generally knowledgeable, but in this case nobody seems to be able to provide answers with good references, just guesswork. Google operates the domain. How much regulatory power it has? What is the agreement with ICANN. What is the dispute solution mechanism?
----
edit
after looking around, operator agreement with ICANN seems include public interest commitments etc. Operator can't do whatever they want and their policy should be transparent.
> Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies.
https://newgtlds.icann.org/sites/default/files/agreements/ag...
> $11,500 for 9 days early access
Makes video games early access look like childs play.
> Can I buy a .dev domain even if I'm not a developer?
> Yes! From tools to platforms, programming languages to blogs, .dev is a home for all the interesting things that you build.
"Dear VALUED developer, thanks so much for being a part of the .dev experiment! After a long hard period of staring at our shoes, we realized we cannot extract sufficient value from our users in this manner. As of midnight, your name will automatically be migrated to our newer, better, faster TLD, .plus, the future of the open web"
When it comes to something like this (AKA not a consumer product, makes money, relatively easy to run, etc), I genuinely can't see them shutting down a TLD like this.
If anything, the complaint should be the lack of official support you should probably expect for it.
Google code shut down without a replacement google service. [1]
Google plus is shutting down too. [2]
[0] https://support.google.com/answer/1083134?hl=en
[1] https://opensource.googleblog.com/2015/03/farewell-to-google...
[2] https://support.google.com/plus/answer/9195133?hl=en
Some folks make a hobby out of the stuff Google spins up and then abandons: https://killedbygoogle.com
Fundamentally, Google is just an advertising company that happens to employ very smart people. If you go to work for Google, you have to understand from the outset that you're working for an advertising company and you're not going to change the world. You might be allowed to work on a fun project, but if it doesn't directly serve the needs of advertising it will be shut down. But hey, it'll look good on your resume.
To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN meme at this point.
Google Code. Also Wave and half a dozen chat apps, but Code was a serious one that broke a lot of the developer web.
What did it break?
URLs that change without good reason are a PITA.
https://code.google.com/archive/about
I see hundreds of thousands of repositories on Github responding to the search "Automatically exported from code.google.com", which means they only transferred _after_ the shutdown was announced (when the export tool went live). Any wikis would have had to be hand-converted to not be broken, since the markup between the two systems was not compatible. I mean, thank you for handling it as well as it was handled, and thank you for (if you were part of that) the export tool, but let's not pretend that it wasn't disruptive.
https://www.informationweek.com/cloud/platform-as-a-service/...
It's not like these complainers actually read articles they're commenting on. You could see this in the Chromecast DNS rantfest - the path is "Google in title => rant about your pet peeve" not "Read article => complain about topical thing".
$8k for a domain is actually cheap compared to other premiums in other new gtlds.
So yes, minor anecdote, and I genuinely appreciate the hundreds of Google employees who really help the Web and share useful knowledge (and don't lead developers into using techniques best suited for billion-user websites, as FB often does) but I'll reserve to right to side-eye anything Google says.
Every web dev I know bitches about it.
There's nothing about Safari that makes it "the new IE8". Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.
Google was really carrying a big part of the webkit development.
Define "accepted". Hastily implemented and shoved down everyone's throat by Chrome doesn't mean "accepted".
> Google was really carrying a big part of the webkit development.
Nope. Google is dominating the development space with utter disregard for public/dev opinion.
HN is quite diverse and I'm pretty sure those are two disjoint sets of users. (I'm in the former group myself --- not a fan of presenting information in such a way as to decrease its accessibility while also increasing resource usage.)
I bet I could make those accordion sections work in all browsers going back to IE5 without much effort, and use nothing near 120KB of JS to do it... but no, most "modern web devs" would rather pile on the bloat of their libraries and "best practices" to make something that works only in the very latest version of the one browser they personally use.
<summary>/<details> tags with JS polyfill is all you'd need.
https://caniuse.com/#search=summary
Why you think something would be broken when a polyfill is used as fallback, I don't know.
Google Support
<SUPPORT_PERSON>12:53 PM Thank you for contacting Google Domains. My name is <SUPPORT_PERSON> and I'll be happy to assist you. Let me quickly read your notes here.
<SUPPORT_PERSON>12:54 PM Hi there
<SUPPORT_PERSON>12:54 PM How are you?
<ME>12:54 PM Hi. I'm trying to read your website but it's broken in one of the dominant web browsers in the world.
<SUPPORT_PERSON>12:54 PM Hi you said that the link https://domains.google/tld/dev/ doesn't work on Safari?
<ME>12:55 PM The accordion links are broken.
<SUPPORT_PERSON>12:55 PM Have you tried in Chrome already though or maybe a private window in Safari already?
<ME>12:55 PM "Is this a one-time payment? Will I still need to pay $12 every year to keep my domain?" click (nothing happens)
<SUPPORT_PERSON>12:55 PM It's just maybe a cache
<ME>12:56 PM It's not just a cache
<SUPPORT_PERSON>12:57 PM Alright but have you tried other browsers maybe?
<SUPPORT_PERSON>12:57 PM I've checked it here and the link you sent works just fine
<ME>12:57 PM Did you test in the latest Safari on the latest macOS? Because it doesn't work fine.
<SUPPORT_PERSON>12:57 PM Sorry, not using Mac
<SUPPORT_PERSON>12:58 PM But we'll look into it if we get feed backs similarly
<SUPPORT_PERSON>12:59 PM We apologize for the inconvenience but please take a look into it on a different browser like Chrome for the time being
<ME>12:59 PM here are other reports https://news.ycombinator.com/item?id=19178833
<SUPPORT_PERSON>12:59 PM Oh alright thank you
<SUPPORT_PERSON>1:00 PM Let me check that
<SUPPORT_PERSON>1:04 PM We are already looking into it <ME>
Don't we all hate reports like this one. "Yeah I know what information you need but my high horse told me to write this crap instead."
Where exactly do you think that came from? Kindly note the words "you said".
It's almost as if there was a "please tell us what you're asking about" field that you fill in before being connected to a chat agent or something.
Really? No mention of Lets Encrypt? Does anyone still buy certificates nowadays, especially for dev sites?
Which is interesting, I would expect Google to promote Lets Encrypt... Or do they assume devs already know about it?
Let's Encrypt provides DV (Domain Validation). Not OV (Organization Validation).
Obviously .dev is intended for software development and most domains there would probably be using DV only so this might not apply to it, though.
It might sound useless for those who doesn't know what it is.
However, for those who does it is very useful and getting more useful.
Browsers might (if not yet, coming soon to you) raise red flags if you try to use a website whose certificate was signed by a rogue CA that, according to DNS instructions, shouldn't be able to do so for that domain.
Browsers might demand OV from high profile websites in theory.
etc, etc, etc.
Maybe we are
> Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.
There are 2 reasons: 1. To limit damage from key compromise and mis-issuance 2. To encourage automation.
What is the issue with running the certbot on your server? It's not like you have to run it manually.
Here are official reasons: https://letsencrypt.org/2015/11/09/why-90-days.html
P.S. Wildcard certs are available for almost a year now: https://community.letsencrypt.org/t/acme-v2-production-envir...
I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.
Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.
I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.
edit: just a reminder that .local is the reserved one https://en.wikipedia.org/wiki/.local
Many premium domains are held back by the registry, which are a part of icann rules. Those domains are typically not able to be registered and used by anyone.
> The mission of this gTLD, .dev, is to provide a dedicated domain space in which Google can enact second-level domains specific to its projects in development. Specifically, the new gTLD will provide Google with greater ability to create a custom portal for employees to manage products and services in development.
> Charleston Road Registry intends to operate the proposed gTLD as a closed registry with Google as the sole registrar and registrant. The goal of the proposed gTLD is to allow Google to manage the domain name space for its projects in development. The proposed gTLD will provide Google with the ability to customize its domain and website names for its projects and signal to users that .dev websites are managed by Google
> Charleston Road Registry believes that given its intended use by Google, the .dev gTLD will best add value to the gTLD space by remaining completely closed for the sole use of Google.
…and now they're opening it up to the public... :\
[1]: https://gtldresult.icann.org/applicationstatus/applicationde...
[1]: https://www.w3.org/DesignIssues/TLD
I don't think they use any domains beyond the few used for the registry page either.
I'm going to avoid buying one, but if there are any popular .dev domains I hope I will forget about it before long. I don't want negative feelings from this so often. On the other hand there are plenty of reminders of negative things in politics and the environment, so I guess I've gotten used to it and developed outrage fatigue.
https://tools.ietf.org/html/rfc2606
.test is only one more letter.
.test doesn't convey the meaning I intended.
I've been vaguely aware of what's in that RFC, but I don't think reserving those TLDs for local stuff means that other TLDs are off limits. I certainly don't use example.com for all example emails. Developer happiness comes first.
I got burned by going with domains outside that doc, but I think the blame goes on Google, not on those who decided to use .dev without making it an official standard. I think if it was an official standard Google might still have muscled their way into getting .dev, and I wouldn't be surprised if they do the same with .test in the future.
And Google gets baseless accusations because you feel entitled to something. Enjoy the feeling, you're entitled to it.
.test is what you should have been using, precisely for this reason.
.test is not as nice
Would .dev domain be available from other countries?
However, Google determined that no, unix.dev should be a premium domain, and "stole" the reservation from me (after I have already paid for it). They later added it to the premium domain list, and they asked me for $11k to keep the reservation.
TBH, I expected to lose the domain because of trademarks or whatever, but apparently it was simple highway robbery.
Btw, I didn't even get my money back, just "store credit".
It is fair to claim it legally under copyright etc like the OP mentioned, but otherwise, he paid for it and gets to do whatever with it.
"Reservations" mean nothing. Google Domains is merely one of many registrars that have customers all vying for domains in the same namespace. A "reservation" just means that the registrar will make their best effort to attempt to get that domain for you at the specified price; it doesn't mean that some other registrar won't get it first, or that some other customer isn't willing to spend more and will get it on an earlier day of EAP.
Until the domain is actually created with you as the registrant, it isn't yours in any sense of the word. There are even registrars out there that will, upon acquiring a domain, auction it off amongst all of their customers who pre-registered it.
Anyone have anymore info about this? Seems concerning that a registry has no restrictions on what they can do with pricing after an individual has invested into an expensive domain.
I've experienced weird price fluctuations with .io domain renewals in the past, but haven't owned one in a few years.
When I called to clarify with a few registrars, they said that this premium price ($280) is specified by the registry (Google), and that there's no guarantee that pricing will stay at $280. I used a hypothetical, and asked them if it were possible for Google to raise the price to something like $1000/yr or $10k/yr, and they confirmed that there is technically nothing stopping the registry from doing so.
It's unclear to me if premium-ness is a function of time, and/or if there's an objective formulaic criteria here.
"Registry Operator must have uniform pricing for renewals of domain name registrations (“Renewal Pricing”). For the purposes of determining Renewal Pricing, the price for each domain registration renewal must be identical to the price of all other domain name registration renewals in place at the time of such renewal, and such price must take into account universal application of any refunds, rebates, discounts, product tying or other programs in place at the time of renewal."
REGISTRY AGREEMENT - 2.10 (b)
https://newgtlds.icann.org/sites/default/files/agreements/ag...
But I suggest people read the whole article themselves, I have no industry expertise.
I believe in the original .app launch thread on HN they stated that premium domain pricing was based on machine learning. So...who knows.
edit: the css for the element that overflows has: `grid-template-columns: 50vw 50vw;` and based on the spec: https://www.w3.org/TR/css3-values/#viewport-relative-lengths, scrollbars are not taken into account, therefore as long as you have a _forced_ scrollbar, the content WILL overflow regardless of your screen size.
By forced I mean a scrollbar you cannot remove and that's not enforced by your systems settings, you can clearly see this behaviour on mac if you toggle the "Show scroll bars" setting to "Always".
Safari and webkit based browsers can avoid this issues with `::-webkit-scrollbar{ display: none}` but it's not a cross browser solution nor a wise decision to hide scrollbars overall.
49vw not 50vw, to approximately make room for the vertical scrollbar when it appears.
OK, on with my day ;)
Google forced me to migrate my local .dev domains to .devo because Chrome refused to connect to my localy configured domain names via /etc/hosts.
- The IP address 1.1.1.1 as a public DNS has clear value to the public, DNS IP addresses needing to be for 0-255 values that are memorable. .dev has no real public value considering the plethora of other tlds.
Of course it has, TLDs that describes itself are valuable for some business, and this is exactly what this seems to be about.
Dutch auctions are incentive-compatible - they allocate the resource to the person that gains the highest utility for having it. Maybe Google got some of the people working on ads auctions to design this pricing structure.
I'd like to have a very short domain personally but it's hard to anticipate what the demand will be like here.
This pricing structure is not just for .dev domains.
It's generally a good idea to have some kind of auction for the reasons the parent comment mentions, as it is a more economically efficient way to allocate the limited namespace to those who want it the most.
We can say that, when bidders do have similar bankrolls, whoever wants the domain the most is likely to buy it first. If they don't, whoever has the bigger bankroll will probably be able to buy it first.
I don’t think that’s necessarily true. Any large company is able to drop a ton of money on something that has marginal utility for them, whereas a small business that would gain much more utility from it may be outbid just by virtue of having the wrong opponents.