977 karma · joined May 19, 2020
> You can migrate from a Free Team organization to a Personal account by opening a support ticket. No action will be taken against your account while your ticket is being processed.
Are the absolute values the running totals? If so, why do they decline from 2021 to 2022?
I think a graph for unique counts would be cool to see too. For example, the ClickHouse query posted earlier in this thread shows:
domain count unique
-------------------------
.org 349414 58226
.net 114499 31129
In the same context, I think it would be interesting to see the top 50 domains on each TLD.
Anyway, it's very cool info to see. Thanks for sharing it!
The ENS stuff is cool, but I hope it doesn’t catch on unless they come up with a way to coexist with ICANN. I think multiple DNS roots would be a net negative no matter what.
I think the kind of approach used here is a bit better than OpenID in terms of separating authentication and identity. You have a permanent account on the service for authentication and the identity (your domain) is more of a pointer / shortcut. That strikes a good balance in terms of letting the service provider dictate authentication policies without usurping your identity people recognize.
Unfortunately I don't think any of the big tech companies would get onboard with an idea like this. They're all racing / competing to control identity right now. Although I've always thought the idea would fit well with Twitter.
If anything, I think having a domain tied to multiple services that break when the domain expires will help people notice so they can redeem within the grace period.
Impersonation via an expired domain might be an issue, but that's already a problem we have to deal with and I don't see how it could get significantly worse, especially since services could put up warnings when domains move between accounts.
The value is in the way the domain owner participates online and what kind of reputation they build. There are many old-school communities where I recognize the handles of extremely knowledgeable, friendly, helpful people and I have no idea what their real names are.
Imagine if the well earned reputations of high quality participants were transferable across online communities by using a domain as global handle.
example.com <--> ryan29-abcdef
I hope this idea catches on. I think a more decentralized approach to identity combined with 3rd party attestations or filters could change the way the internet works.
Imagine what could be built if everyone used domains as handles / identities. Social networks could go hands off for moderation and allow plugable moderation engines that rely on domains for identity, trust, reputation, etc..
I'm convinced that domain validated identities and attestation could usher in a revolution for reputation and trust. Are there any more projects doing similar things?
That's been a thing for a long time. I hit it when trying to share games with child accounts. IIRC, the high level process was:
- Set up child computer with a child account.
- Add parent account as family member on child computer.
- Set up a PIN for the parent account on the child computer.
- On the child OS account, open the Windows Store and log in as the parent.
- Log back in to the Windows Store using the child account.
When I ran into the issue, I could buy anything I wanted with the child PIN and it bypassed all restrictions.
I was so surprised by the way it worked that I spent an entire afternoon testing it. I got a prepaid credit card, set up fresh MS accounts for the parent + child, set up a clean OS install, and recorded everything using VirtualBox by using the on-screen keyboard to show the PINs.
At the time there was a bug in VirtualBox's video recording that caused it to record random garbage and I got so frustrated that I set it aside and never went back to it.
It seems like an auth bypass issue to me and it's been a problem for over 7 years. It's been around so long it's even made it's way from an unofficial blog into official MS docs [1]:
> As of Dec 25 2015, there seems to be a bug in the Windows Store sign in process as it may ask for your PIN code but it actually wants your family member’s PIN code. That is, at least at the time of this writing, use the PIN of the signed in family member even though it asks for your PIN!
1. https://learn.microsoft.com/en-us/archive/blogs/henrikn/shar...
example.tech
exampletech.com
That would make sense to me. I wouldn't even be surprised if some registrants are unable to pay in USD or if they get charged exorbitant fees for foreign exchange.
Even if the registrars added a warning during checkout with a link to an explanation of how it works, I bet very few people would read it. They'd probably have the same number of upset customers and the complaint would shift to registrars hiding a complex pricing scheme in the fine print.
My hunch is the OP is an extreme outlier and the issue happens so infrequently that the complexity of explaining it up front isn't worth it. In the past ~5 years this is the first time I've seen someone with a receipt and a legitimate complaint.
I think some of the responsibility can fall on the OP too. They say they've registered hundreds of domains, so it's not unreasonable to think they should be spending some time learning what rights they have as a registrant, how disputes are resolved, how long term pricing works, etc., especially if they're registering premium domains.
I think this person's case is a good example of where that can be problematic. Even if they had paid the correct price originally, they'd be seeing a 35% price increase because of the exchange rate. It's not unreasonable for them to have assumed the original purchase and renewals were always going to be in their local currency without fluctuation due to foreign exchange rates.
I skimmed ICANN's registrar accreditation agreement for info about pricing and it basically says registrars can price domains however they want. The registry agreement has pricing related limitations, so I think the intent is to ensure registries don't engage in abusive pricing with the assumption that competition will keep the registrars honest because registrants can transfer their domain to a new registrar if they're being mistreated.
That leaves this person with no recourse. The registrar (in my opinion) undercharged them and didn't do a good job of communicating the true ongoing cost of the domain. Transferring to a competing registrar doesn't help because the registry pricing for the domain is going to be around $700 USD while the registrant's expectations were set at TRY4360 ($230 USD today).
There aren't any great options to make it right either. The registry can't start discounting domains to fix mistakes made by a registrar, the registrar can't take a loss of $470 / year (at current exchange rates, potentially forever), and the registrant shouldn't have to pay $700 USD / year for a domain they thought was TRY4360 ($230 USD today). To make it worse, the registrant's expectations didn't get reevaluated until the bill for renewal came due and if they've spent a year developing on the domain it feels like extortion (to them).
It's also not fair to expect the registrant to realize they're underpaying. Price differences between registrars are enough for people to assume a low price is the result of finding a registrar with better pricing.
Google Domains isn't the only registrar that gives the impression domains are priced in local currency either. Gandi bills me in CAD and doesn't mention USD when I'm buying domains. Namecheap shows me prices in CAD, but bills in USD and it's not clear USD is the real price rather than simply being the billing currency.
Forget you know the registry sets prices in USD and go pretend to register 6b.dev on Google Domains. Select a foreign currency and see if you can figure out the price will fluctuate based on the exchange rate for USD. I'm not sure where the OP got the idea renewal would only be $12 rather than the TRY4360 they paid originally. There's nothing that left me with that impression.
The wholesale price is determined by the registry (Google), but the retail price will include markup from the registrar (Namecheap, Porkbun, Google). In the case of .dev Google runs the registry and acts as a registrar. As for registrars, that comparable (6b.dev) is $709 at Porkbun, $720 at Google, and $843 at Namecheap.
Namecheap is marking it up more than the other registrars.
I wonder if your registration last year included any kind of first year discount. This is the first time I've seen someone show an actual receipt for this type of complaint. I estimated the pricing at about $315USD vs $700USD. That's enough of an increase that I'm really curious to know what happened.
> The parties acknowledge that the purpose of this Section 2.10(c) is to prohibit abusive and/or discriminatory Renewal Pricing practices imposed by Registry Operator without the written consent of the applicable registrant at the time of the initial registration of the domain and this Section 2.10(c) will be interpreted broadly to prohibit such practices.
From what I've seen, people typically tend to be confused about what they bought when you see threads like this. In the past several years I've never seen anyone produce documentation or screenshots that show they registered a non-premium domain that was reclassified as premium while they had it registered.
1. https://itp.cdn.icann.org/en/files/registry-agreements/sbs/s...
> The parties acknowledge that the purpose of this Section 2.10(c) is to prohibit abusive and/or discriminatory Renewal Pricing practices imposed by Registry Operator without the written consent of the applicable registrant at the time of the initial registration of the domain and this Section 2.10(c) will be interpreted broadly to prohibit such practices.
I've been watching for it to happen to someone for years because I own a domain that would be at risk of getting reclassified as premium if it were allowed. I've been monitoring the same word as my domain on 300+ TLDs for about 2 years. I've never seen one get reclassified as premium without being dropped first.
Are you positive yours wasn't classified as premium with a huge discount for the first year?
I think the new TLDs would do much better if they'd quit with the pricing games and strengthen registrant rights instead. As a registrant, I want predictability and minimal risk when I register a domain. The only way to get that right now is to stick with .com AFAIK. It's too bad because I'm a huge fan of using 'somecompany.tech' plus 'somecompanytech.com', but, in my opinion, most of the new TLDs are too risky to depend on.
I'm really interested in any updates you would have because I always considered .app and .dev to be "safe" domains in the sense that I thought Google would always have transparent, uniform, predictable pricing without any exorbitant increases.
1. https://itp.cdn.icann.org/en/files/registry-agreements/dev/d...
> When I log on to Blockscan chat, I sign in with Ethereum. This means that I am immediately visible as vitalik.eth (my ENS name) to anyone I chat with. In the future, to fight spam, Blockscan chat could "verify" accounts by looking at on-chain activity or POAPs.
Imagine that same idea, but with traditional domains and support on major platforms. I've wanted domain validated/verified identities for as long as I can remember. Imagine being able to use your domain name as a handle, with instant reputation/recognition, on all major platforms:
twitter.com/@example.net
youtube.com/@example.net
The general idea is that you precompute a bunch of proofs and store them on disk. Challenges are issued and if you have a matching proof, you can claim the token for that challenge.
The part that I find interesting isn't the tokens. It's the concept that an algorithm can prove you've committed some disk space to the network. The reason I find it interesting is because, for small amounts of disk space, the incremental cost of participation is $0. If I plot proofs on unused disk space and only try to match proofs when my computer is on anyway, it basically costs me nothing.
Compare that to someone trying to farm (aka mine) on an industrial scale and they have a real, non-zero cost starting with the first byte of storage they buy. I find it interesting because it's different than normal economies of scale where a large operator eventually outperforms all the small operators (economically).
Unmatched, but valid proofs, are a byproduct of mining the tokens and those are what proves you have some idle capacity. Since normal PC owners pretty much have to buy excess capacity for something like a hard disk, participating in a system like that doesn't have much downside. It's that byproduct that I think is interesting.
I'm not sure if there are any pragmatic use cases, since the 500GB of free space a normal user has might not exceed the value of pretending to be a real person, but being able to say "I have $50 of idle capacity and I can prove it" could be a novel way to combat large scale networks of bots and bad actors.
With Mastodon, it looks like Ruby on Rails, Node.js, PostgreSQL, and Redis for the backend stuff. For me, the only realistic way I'd run a node would be via Docker (Compose) which means I'm limited to something non-redundant (ie: no HA) that only scales vertically, at least easily.
> The article mentions an admin of 80K users spending 300+euro/mo
I think it's well understood that centralized systems win because normal, non-technical people don't want to deal with the complexity of managing their own servers and that devolves into the situation like the one you pointed out where normal users consolidate on a single node and the owner of that node ends up stuck with all the cost, moderation, maintenance, etc.
The thing that I think isn't considered enough, or at all, is that decentralization of control doesn't need to mean decentralization of infrastructure. Imagine something like Mastodon but built with newer tech that makes it deployable to Cloudflare, Netlify, Vercel, etc. Think along the lines of using something like SvelteKit + adapters. I can see all of those infrastructure platforms getting to the point where a custom deployment could be distilled down to something as simple as installing an app on a phone where the only thing you need to do is feed it a domain.
As long as it's federated using a custom domain, making it simple enough for a normal person to run an instance increases the decentralization of control which is more important than decentralizing the infrastructure in my opinion.
I think one of the main things that we need to make that more realistic is for someone like Cloudflare to provide a local runtime for their core services (Pages, Workers, Functions, KV, R2, etc.). Having something vertically scalable is adequate because that's no worse than what most of us get with a Docker based deployment which is the maximum complexity most people will be willing to deal with, at least the people I know.
The other thing that would help a lot would be if those companies I mentioned collaborated to have deployment compatibility. IE: I should be able to write one app and deploy it to any one of them as long as I use a standard set of features. I think that would be amazing from the perspective of being a customer / dev, but I don't know how realistic it is on the business side of things.
Besides that, I looked at every DynDNS system I could find back in the summer. There were only 3 that I was happy with; Hurricane Electric, Google Domains, and a pair of self hosted Bind servers.
If you want the best, simple solution, and it doesn’t need to be completely free, register a domain with Google domains. If anyone knows of limitations, let me know.
Namecheap maxes out at 150 DynDNS hosts :-(
No. It's basically one download of all your data in 1 month [1].
> For example, if you store 100 TB with Wasabi and download (egress) 100 TB or less within a monthly billing cycle, then your storage use case is a good fit for our policy. If your monthly downloads exceed 100 TB, then your use case is not a good fit.
In my experience it's an excellent fit for backups if you run disaster recovery tests quarterly on each set and have enough sets to run on a rotating, monthly schedule. You're only downloading about 25% per month at that point.
I’m from Canada, so I used the ccTLD for all of my non-public stuff. CIRA seems to be well run.
I was really frustrated by the trendy TLDs, especially the ccTLDs. I felt like I had to register those because anyone willing to use (ex:) .io probably has a high enough risk tolerance they’ll use the name without even considering existing trademarks, etc.. The .io and .co domains are the most frustrating because they’re more expensive than the others.
So I would say relying on .com, .net, and your ccTLD is great advice in terms of TLDs to use, but don’t hesitate to register some of the trendier ones for brand protection because it’s the cheapest thing you can do to discourage others from using the same name.
That's a good point in terms of invalidation, but a new domain registrant should be able to claim the namespace and start using it.
I think one possible solution to that would be to assume namespaces can have their ownership changed and build something that works with that assumption.
Think along the lines of having 'pypi.org/example.com' be a redirect to an immutable organization; 'pypi.org/abcd1234'. If a new domain owner wants to take over the namespace they won't have access to the existing account and re-validating to take ownership would force them to use a different immutable organization; 'pypi.org/ef567890'.
If you have a package locking system (like NPM), it would lock to the immutable organization and any updates that resolve to a new organization could throw a warning and require explicit approval. If you think of it like an organization lock:
v1:
pypi.org/example.com --> pypi.org/abcd1234
pypi.org/example.com --> pypi.org/ef123456
Losing control of a domain would be recoverable because existing artifacts wouldn't be impacted and you could use the immutable organization to publish the change since that's technically the source of truth for the artifacts. Put another way, the immutable organization has a pointer back the current domain validated namespace:
v1:
pypi.org/abcd1234 --> example.com
pypi.org/abcd1234 --> example.net
I think that's a reasonably effective way of solving attacks that rely on registering expired domains to take over a namespace and it also makes it fairly trivial for namespace owners to point artifact consumers to a new domain if needed.
Think of the validated domain as more of a vanity pointer than an actual artifact repository. In fact, thinking about it like that, you don't actually need any cooperation or buy in from the domain registries.
> The hard part is how to issue a new key if you lose the old one, since that probably requires social vouching and a reputation system.
It's actually really hard because as you increase the value of a key, I think you decrease the security practices around handling them. For example, some people will simply drop their keys into OneDrive if there's any inconvenience associated with losing them.
I would really like to have something where I can use a key generated on a tamper proof device like a YubiKey and not have to worry about losing it. Ideally, I could register a new key without any friction.
I don't know if registries would play ball with something like that, but it would be useful and should probably exist anyway. I would even argue that once a domain rolls through grace, redemption, etc. and gets dropped / re-registered, that should invalidate it as an account recovery method everywhere it's in use.
There's a bit of complexity when it comes to the actual validation because of stuff like that. I think you'd need buy in from at least one large company that could do the actual verification and attest to interested parties via something like OAuth. Think along the lines of "verify your domain by logging in with GitHub" and at GitHub an organization owner that's validated their domain would be allowed to grant OAuth permission to read the verified domain name.
If I own example.com, I should be able to have 'pypi.org/example.com/package'. The domain can be tied back to my (domain verified) GitHub profile and it opens up the possibility of using something like 'example.com/.well-known/pypi/' for self-managed signing keys, etc..
I could be using the same namespace for every package manager in existence if domain validated namespaces were common.
Then, in my perfect world, something like Sigstore could support code signing with domain validated identities. Domain validated signatures make a lot of sense. Domains are relatively inexpensive, inexhaustible, and globally unique.
For code signing, I recognize a lot of project names and developer handles while knowing zero real names for the companies / developers involved. If those were sitting under a recognizable organizational domain name (example.com/ryan29) I can do a significantly better job of judging something's trustworthiness than if it's attributed to 'Ryan Smith Inc.', right?