Further context: Bluesky lets you use a domain name you own as a user handle.
The official method is to set a TXT record, but apparently their "AT protocol" also lets you confirm a domain by serving `GET your.domainname.com/xrpc/com.atproto.identity.resolveHandle`
I guess I'm not too surprised in that, unlike domain names, these aren't obviously exposed to end users, so terseness doesn't particularly matter. Verbose and descriptive is honestly better for most names.
And given that bucket names are a giant shared namespace, there's absolutely an incentive toward lots of prefixing to help ensure you get the ones you want.
To this day I don't know why it's a global name. For R2 we looked at this, saw the massive annoyance picking bucket names, and made it scoped to your account. CNAME records are orthogonal and can be set up to point to your bucket with a few button clicks.
Oh yeah, also we're more secure by default. Granted S3 was built a long time ago maybe when security was an afterthought and such mistakes are harder to correct now.
Other things I think we do better on:
* The account is the top-level thing we publish a cert for. Without knowing the bucket name you can't really do anything. With S3's global namespace, each bucket has a cert published which makes all buckets discovered as soon as they're created.
* Not default open to the world
* The R2-managed public bucket cname is shared and the URL for the bucket is random (i.e. just a UUID). Additionally, if you delete and recreate the bucket with the same name IIRC that random UUID is changed.
* We have a lot of sensible extensions like automatically creating a bucket on upload (granted not possible for S3 since buckets are global), setting per-object TTLs, handling unicode more gracefully (I think normalizing the key name is a saner choice with fewer foot guns even if there's some potential compatibility issues when you try to synchronize from a filesystem where you have two files with different forms but same normalized), etc etc etc.
Also to try to avoid having to special-case any logic in terraform etc.
Say you're working on a family of sites for tradespeople like plumber.io, electrician.io, carpenter.io, etc. A fair number of people from India have "occupational surnames" like Miller, Contractor, Builder, Sheriff, etc. Suddenly one Mr. Dev Contractor registers a bucket "contractor-dev" and you have to special-case your bucket names in your terraform.
Yep, when writing IaC I always just give it a prefix like "$project-web" and terraform adds a long string of numbers at the end. It's going through CloudFront anyways, so no one should be referencing the bucket name directly unless they're writing to it (and writers can just do `aws s3 ls` to find the name).
No, they indefinitely delayed that deprecation. It's still delayed. I bet[1] it never happens. They haven't figured out what to do with S3 VPC endpoints and buckets with dots in the name, which both to this day require path-based addressing and are both completely legitimate uses. They just stopped talking about this plan entirely and it's been years; I think it's dead.
[1] If they ever actually turn off path-style addressing, come find me and I'll PayPal you a dollar. I don't think it'll ever happen.
(I don't know anything about this personally, but since a lot of people are indicating an interest in this detail of the story, figured I'd try and surface that link better!)
The official method is to set a TXT record, but apparently their "AT protocol" also lets you confirm a domain by serving `GET your.domainname.com/xrpc/com.atproto.identity.resolveHandle`
and `xrpc` was available as an S3 bucket name :)