History

Let's do some history!

This is 1978's "HOST NAMES ON-LINE". Early Internet standards described the - character as "minus" rather than hyphen.

RFC 608

up to 48 characters drawn from the alphabet (A-Z),

digits (0-9), and the minus sign (-) ... specifically, no blank or space characters allowed;

no distinction between upper and lower case letters;

the first character is a letter;

the last character is NOT a minus sign;

no other restrictions on content or syntax.

So, originally, you could have as many hyphens as you wanted after the first symbol - which had to be a letter. The last symbol had to be a letter or number⁰.

That was later formalised in 1981's "DoD INTERNET HOST TABLE SPECIFICATION"

RFC 810 GRAMMATICAL HOST TABLE SPECIFICATION

<name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]

That's carried in the the slightly more modern RFC 952.

By the time we hit 1987, the word "minus" has gone. Note, there are no restrictions on the number of hyphens - just as long as your domain name doesn't start or end with one¹.

RFC 1035 2.3.1. Preferred name syntax

The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen.

By 1989, the "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" was tweaked again:

RFC 1123 2. GENERAL ISSUES

The syntax of a legal Internet host name was specified in RFC-952. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.

And, from then on, things stayed pretty stable until the futuristic year 2010. That was when Internationalised Domain Names (IDN) became available. They use the xn-- string at the start of the name so, the spec now says:

RFC 5891 4.2.3.1. Hyphen Restrictions

The Unicode string MUST NOT contain "--" (two consecutive hyphens) in the third and fourth character positions and MUST NOT start or end with a "-" (hyphen).

What they really mean is that "--" is banned in position 3 & 4 unless the first two characters are "xn"².

So, in theory, you can have up to 59 consecutive hyphens by ensuring that they start in position 4 and end at position 62.

Something like abc---[…]---z.com should be fine.

OR IS IT?!?!?

TLD Restrictions

There's what the RFC's say, and what a Top Level Domain (TLD) will allow. The Registry (the organisation which administers the TLD) may set their own, more restrictive, policies. Some will ban naughty words, or refuse IDN registrations, or prevent impersonation of Public Suffix domain, etc.

For example, South Sudan's .ss policies refuse to allow any hyphens.

Nominet, who run the .uk Registry, don't have any restrictions on the use of hyphens other than refusing to register xn-- domains.

But, in general, you can register multi-hyphened domain names with most Registries.

Anomalies

Of course, the mighty Internet mostly runs on spit and hope³. Naturally there are going to be mistakes, glitches, exceptions, and anomalies.

My delightful friend Q Misell had a rummage through her archives and helped track down some of the domain names which violate the modern rules. It's somewhat difficult to query every domain name, nevertheless, there are hundreds of multi-hyphened domains lurking within DNS.

Some, like ok--computer.com are long dead, but some are still active⁴!

Possibly the most consecutive hyphens belongs to http://a-------------------------------------------------------------a.com/

Sixty-one hyphens! The maximum possible, and it still works! The website looks like it hasn't been updated since it was first registered in 2000.

But what about more modern domains? The spookily named http://zz--icann-monitoring.uk/ was registered in 2024 - long after the rules were updated. But as Nominet doesn't allow xn-- domains, I guess it is fine?

There are some domains like bq--3bhauz7frjrgbka.com which look like they were pseudo-randomly generated. Perhaps as command-and-control servers?

Here's a quick table showing some of the ones Q found:

Note, "Live" just means an HTTP request returned something. There may, of course, be other services running on that domain, or on subdomains.

So What?

Without a full list of every domain name, it's rather hard to draw firm conclusions. But, in the absence of anything better to do, here are some thoughts.

• Most people don't want multiple consecutive hyphens in their domain names. They're unwieldy but mostly not prohibited.
• If the authors of RFC 5891 had access to a full list of domains, might they have chosen a different syntax for Punycode?
• Why is it so hard to look through every single registered domain name anyway? Even Certificate Logs no longer seem to be easily searchable.
• Are there any other weird restrictions which are violated by older domain names?
• When will DNS finally go all-in with Unicode rather than this kludge? (Probably around the same time as IPv6 adoption!)

If you know of any weird multi-hyphenated domains, please stick a comment in the box 😊

Update! A kind anonymous benefactor has shared a list of eighty-four thousand domains with multiple hyphens. There are some very odd entries in there.

Every site that I sign up for asks me to upload an avatar to represent myself. Whenever I change my photo, I have to log in to a hundred sites and change it there⁰.

Perhaps they could all use Gravatar - but that's a centralised service¹ and doesn't work with wildcard email addresses. Libravatar also relies on email addresses and requires implementers to set up new DNS entries.

So I'm proposing .well-known/avatar. Here's how it works (for now). I'd like your feedback before going further².

I sign up to a service and use the email address whatever@shkspr.mobi.

The service looks up my avatar using a well-known path. For example, request https://shkspr.mobi/.well-known/avatar?resource=acct:whatever@shkspr.mobi and you'll get back this JSON:

{
    "subject": "acct:whatever@shkspr.mobi",
    "links": [
        {
              "rel": "http:\/\/webfinger.net\/rel\/avatar",
             "type": "image\/webp",
             "href": "https:\/\/shkspr.mobi\/.well-known\/avatar\/avatar-1024.webp",
            "sizes": "1024x1024"
        },
        {
              "rel": "http:\/\/webfinger.net\/rel\/avatar",
             "type": "image\/jpeg",
             "href": "https:\/\/shkspr.mobi\/.well-known\/avatar\/avatar-512.jpg",
            "sizes": "512x512"
        }
    ]
}

That's a slightly enhanced https://webfinger.net/rel/#avatar which adds a sizes parameter. The service can then pick the appropriate MIME and size.

Alternatively, you can request the same URl but with a header of Accept: image/gif and receive the default sized avatar in that specific format.

Try it by running:

curl -H "Accept: image/avif" https://shkspr.mobi/.well-known/avatar/ --output "test.avif"

You should receive an auto-converted version of my avatar.

Some Thoughts

Please add your thoughts to the comments box. Here's some feedback I've received so far.

Perhaps this is too complicated? What's wrong with just serving up an image when the URl is requested? That would make it easier for static sites.

Simon Josefsson

@jas@fosstodon.org

@Edent Thinking about this, while I like content negotiation as a clever hack, I wonder if maybe it isn’t too clever. The nice thing with WKD is that you can deploy it with any normal static HTTP file without any special magic. Maybe the protocol could be dumbed down to simply rely on WKD-style URLs? I’m not sure how to configure my web server (Apache) for your avatar well known URL with negotiation magic.

2025-10-23, 16:50 0 boosts 1 favorites

What about a size parameter?

Chip

@chip@talking.dev

@Edent It'd be nice if the query could limit the size of the avatar being returned. If only there were `Accept-Max-Size`, but maybe a query param? I wouldn't want my performance taking a dive if Alice has a 35M avatar that my client starts downloading. If my client had requested with `max_size=3072` I'd rather not see the avatar than degrade performance/pull excess data

2025-10-23, 15:02 0 boosts 1 favorites

Will anyone actually use it?

Andreas Gohr

@splitbrain@fedi.splitbrain.org

@Edent good luck with getting the hundreds of services to implement it. I mean it. it would be awesome and you might be well connected enough to make it happen.

2025-10-23, 15:03

What about hashing the email?

David Bushell 🎮

@db@social.lol

@Edent would using a hash of the email address in its place improve privacy? 🤔

2025-10-25, 11:52 0 boosts 0 favorites

You've already given the service your email address, and your domain already knows your account name - so there's no privacy leak here. Obviously, a service shouldn't hotlink to your avatar image.

How about DNS?

I like it. Is there an argument that service / endpoint should be specifiable at the DNS level?As others in your comments pointed out, if your site is currently just static, some users might prefer to run an entirely separate dedicated avatar service.

— Emily Shepherd (@emi.ly) 2025-10-25T11:57:43.456Z

Personally, I think that's a bit complicated, but I'm happy to be convinced.

Is this restricted to email?

No! For example, if you know my GitHub username then you should be able to get the avatar from https://github.com/.well-known/avatar?resource=acct:edent

How can a service tell if the avatar has been updated?

Perhaps a hash, timestamp, or something else?

Can requests for multiple accounts be sent at once?

I'm not sure how / if WebFinger handles this. I suppose there ought to be some limit to avoid overwhelming a server.

Proposal

I think the default should be to return an image.

If an accept of image/… is requested, the server should try to return an image in that format.

If an accept of application/json or similar is requested, the server should return a JSON document listing the available avatars.

I don't think a ?size= GET parameter is necessary; services can resize once they've downloaded, or use the JSON document to get the right size.

A limited amount of alt text could be added using the title attribute in the JSON.

Before I start writing up anything formal - I'd love your constructive criticism on this.

When I sign up to a web service, I don't want to faff around uploading an image to use as my avatar. I want that service to look at my email address or social-sign-in and automatically pick up my preferred graphic.

Here's how I see it working.

1. A user signs in to a service with the email address username@example.com
2. In a similar way to WebFinger, the service makes a request to:
   • example.com/.well-known/avatar?resource=acct:username@example.com
3. If the request's Accept header has a MIME type of image/*, then the server immediately returns an image.
4. If the request's Accept header has a MIME type of application/json, then the server can return a WebFinger-style document with "rel":"http://webfinger.net/rel/avatar" and, perhaps, a list of different images, formats, and sizes.

This makes it incredibly simple for people to use the same avatar everywhere.

It also means that if you're designing a service which publicly shows usernames, you can make avatars available without an expensive API call. For example, Twitter could make user's avatars available at: twitter.com/.well-known/avatars?resource=acct:edent

But what about...?

This is a sketch of an idea. I'd like to know if people think it is useful before I take it any further.

I don't think it breaches privacy - a user's image is public on all services anyway.

Users should still be given the option of changing their avatar if they want.

A service shouldn't expose the user's email address - they should proxy the image.

Anything else I should have thought of?

Updates

To stave off some common points raised.

• No this isn't like Gravatar. That works by being a 3rd party service and using the MD5 of your email address.
• No this isn't like Libravatar. See above.
• No this isn't like WebFinger. That only returns JSON.
• No this isn't like h-card. That requires a server to parse HTML in order to find an image.
• No this isn't like BIMI. That's expensive and only supports SVG.