.well-known/avatar
Hot on the heels of a post I wrote 4 years ago, wouldn't it be useful to have a well-known URl for user avatar images?
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.
- A user signs in to a service with the email address
username@example.com - In a similar way to
WebFinger, the service makes a request to:
-
example.com/.well-known/avatar?resource=acct:username@example.com
-
- If the request's
Acceptheader has a MIME type ofimage/*, then the server immediately returns an image. - If the request's
Acceptheader has a MIME type ofapplication/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.
Alex Chamberlain says:
@edent says:
This is designed to be a 1st party service which uses your account's name.
I also think that services like this should have a way to indicate the size of the avatar, similar for libravatar/gravatar.
@Edent
that is a really wonderful idea. I think not enough use is made of
.well-known, and it has so much promise.still has the whole "domain as price of entry", but that's something that could be worked on (IaaS)
| Reply to original comment on octodon.social
Having said that, There is already the h-card format where you can point to an avatar image.
| Reply to original comment on social.lol
| Reply to original comment on cathode.church
| Reply to original comment on cathode.church
• A user may wish to ensure a particular service account cannot be tied to their main online identity. If they sign up to Twitter as @ MyUsername and also as @anonymousconfessions with two different email addresses at the same domain, they may be deanonymized if the same unique (or otherwise matchable) image is set on both accounts.
| Reply to original comment on mastodon.social
• Renaming your service (e.g. from Twitter.com to X.com) may cause the retrieved avatar to change to the wrong thing. This could conceivably reveal the email hosting domain if the 'default' image is not the same as the custom one set for the previous account identifier.
| Reply to original comment on mastodon.social
• Resources would need to be proxied, and thus presumably should also be cached. A standard cache invalidation mechanism might be valuable, for example when recovering from a compromised web-host that served a rude picture with a long time-to-live.
| Reply to original comment on mastodon.social
True. But I'm not sure how I discover a h-card without requesting and then parsing HTML.
I'm think of this as a way to simplify things.
| Reply to original comment on mastodon.social
I do like that gravatar supports multiple emails though and optional different inages for each, but all under one account. It does expose my email matches another account potentially though, which I may not want to share
| Reply to original comment on mastodon.social
Mohammad Hossein Mojtahedi says:
when a user uploads a file to your site, you can, and for large-scale platforms, you should have malware detection. using .well-known, users can load bad images on your website.
@edent says:
Kevin S says:
blockquote>"I don't think it breaches privacy"
<
blockquote>
This immediately becomes an issue when someone uses it wrong. It's easy to say services should proxy the image. But some certainly will not and expose email address or other account identifier. Using a secure hash (such as SHA-2) would be a simple change that would improve the privacy greatly.
Love the idea of using a well known URL for this purpose!
https://solid.mit.edu/
@edent says:
And thinking about that makes me remember LiveJournal, which had the wonderful feature of letting you have multiple icons and the ability to pick one for each post and/or reply; nobody's ever duplicated this and I really miss the layer of meaning it added on top of plain text.
@edent says:
With rel=icon, h-cards, and other metadata - you need to download a large chunk of HTML and then parse it. I was going for something simpler.
https://blog.jim-nielsen.com/2023/well-known-avatar/
| Reply to original comment on bsky.app
Did you take this any further @edent? With Wordpress (& hence gravatar?) feuding with its own ecosystem it seems prudent to revisit!
I’m a little cautious about using plain text to lookup the email, as it exposes all your email addresses by inspection of a static site’s code (or if a site that uses this mechanism doesn’t proxy, so exposes your otherwise private signup email).
Using a hash of the email instead of the email’s local-part to resolve this (à la gravatar) still allows a fairly easy approach to uncovering email addresses (seek hash collisions), but I guess a person could just not use this method if an email address needs to be harder than that to sniff out.
More comments on Mastodon.