.well-known/avatar
By @edent
· avatar IETF open standards standards · 23 comments · 400 words · read ~1,768 times.
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.
Mastodon
Twitter
Facebook
LinkedIn
Reddit
HackerNews
Lobsters
Pocket
WhatsApp
Telegram
I think you've reinvented https://gravatar.com/?
Not really. Gravatar is a 3rd party service which uses an MD5 of your email address.
This is designed to be a 1st party service which uses your account's name.
@blog I suggested something similar for #libravatar some years ago https://gist.github.com/aslakr/6a7306bf74080eea4498c19fb418073a when services can't use the DNS records.
I also think that services like this should have a way to indicate the size of the avatar, similar for libravatar/gravatar.
@Edent
@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)
@Edent I really like this idea and it moves away from relying on gravatar.
Having said that, There is already the h-card format where you can point to an avatar image.
@Edent there's a risk that I sign up for one site, using my Gmail address* but not intending to link it to my "main" identity - in that case I wouldn't want my Google profile picture to show up. So IMO, this'd be great as a "use this profile picture?" prompt but not as something that happens implicitly
@Edent (this is a risk with gravatar too, though to a lesser extent because a gravatar is something you explicitly set up)
@Edent I think the idea is cute, but some human factors might make it a bit risky for some users and (services?):
• 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.
@Edent
• 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.
@Edent
• 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.
@robb
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.
@Edent I wonder if giving a well-known url as you sign up is better, then you opt in to using that data rather than anonymous, perhaps even selecting what info you want used, ie perhaps more than just a profile photo.
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
what about security?
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.
As I said, services should proxy the image. That way they can strip out anything untoward.
Ideally something like Libavatar/Gravatar does this piece for you so existing services can just keep working with this new idea implemented.
<
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!
Reminds of me the Solid project. Though, that idea is for a lot more than just an avatar, but I would think a common avatar would be a thing that could be included.
https://solid.mit.edu/
@blog the query string makes it hard to implement in a static way, doesn't it? At least if oyu want to support more than one image/identity. With one domain per user it'd work, I suppose.
That's a fair point. Are static sites likely to host multiple users?
I was going to say "but what about the fact that every service has its own size for user icons" and then I re-read this and saw that point 4 says it might, perhaps, have a mode where it returns a list of multiple images/formats/sizes.
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.
Isn't this redundant with the favicon and rel=icon discovery? That works for your site (and mine).
Favicons generally only work for a single server. So something like a Mastodon server can't have a favicon for each user.
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.
@jim-nielsen.com already implemented it in static form: https://www.jim-nielsen.com/.well-known/avatar?resource=acct:jimniels@jim-nielsen.com
https://blog.jim-nielsen.com/2023/well-known-avatar/
More comments on Mastodon.