Alpha launch - .well-known/avatar - feedback wanted
26 points by jak2k
26 points by jak2k
I like this proposal but I honestly think it's not for a lack of a protocol, I believe it's developers not wanting to write a lot of code for custom avatar[s | providers (since libravatar reimpements the Gravatar API, so it's literal drop-in besides federated servers)].
That's probably Gravatar's allure, hash an email, embed it in a <img>, and you'll either get the avatar for that user or a fallback.
Either way, I'd love to see Gravatar replacements get traction, since Gravatar is attached to Automattic, which as most readers know is owned by Matt Mullenweg, who can be... eccentric, to put it respectfully.
This is basically webfinger for libravatar. Webfinger can be neat sometimes but libravatar will be better for most people
Looking at the Wikipedia page for webfinger, it sounds to me like it actually addresses the exact use case this post is addressing. It's not clear to me what the tradeoff is, can you explain? Is libravatar centralized (like gravatar), and webfinger only self-hosted, and that's it? Or is there more?
Could probably even do as .well-known/avatar/<hash of email> for a direct link, with a fragment to specify size (or however Gravatar does it).
I assume the idea behind the JSON is for services to download/copy images to then host themselves. In which case, wouldn't there need to be an updated at or similar so a service can query for whether a new image is available.
https://wicg.github.io/responsive-image-client-hints/#sec-ch-width and the more available content type negotiation, paired with webfinger, seems to be fine?
I'd rather just plonk in my home page and have the server request (probably after trying my email address) https://example.com/.well-known/webfinger?resource=https://example.com/
Why not directly reply with an image instead of all that json? Let the consumer resize according to their needs.
Looks like it respects the Accept header?
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.
Though loading an image directly in the browser context wouldn't work if the default is JSON. Not sure if that's useful or not; all the other .well-known endpoints I'm aware of return JSON. Maybe the default should be an image in whatever format the server prefers, and only return JSON if Accept: application/json is specified?
Laudable effort but this has no chance of catching on because Gmail and Hotmail won't care.
I think the indiewebcamp people had a protocol for this a long time ago.
An idea with slightly better chance of taking off (still 0.1%) would be to use Nostr for login then just grab the user metadata and picture from Nostr.