A global/federated avatar and a local one

[spaceottercode]

This is a low priority feature request but thought I put it out there just in case. And somethings are best mentioned earlier than later. The Tumblr exodus has brought to light one concern: avatars are federated as-is (as are header but that's n/a).

Here are some possible solutions that come to mind:

The following assumes servers can distinguish a local request from a remote one and can react accordingly.

1. give admins the ability to default all avatars to a default one when fetched remotely.
2. have an option akin to "nsfw avatar" (checkbox) or perhaps a more generic "nsfw account" that could be leveraged for this and other features. When toggled, an alternate version, perhaps a blurred version, is sent to the remote server.
3. let users set at most two avatars: a global and local one. Your Clark Kent / Superman option. As to which one is set when only one avatar is provided: it depends on the ui and what you guys prefer. One possibility would be a user specified avatar clobbers all neighboring default avatars but never a neighboring user specified one.
4. Other
5. None of the above

for me option 2 might be best, if any.

[trwnh]

Off the top of my head, no, this wouldn't be strictly possible? Unless you federate out a profile picture over ActivityPub and then apply a different one locally. In that sense, you could only have a local override. It would also kind of complicate the avatar uploading workflow and not quite solve the underlying issue that you seem interested in (nsfw avatars). It would also complicate the API and necessitate keeping track of request origins, which may not be available/given for public data such as avatars -- simply loading a URL will return the JSON representation, e.g. https://mastodon.social/api/v1/accounts/14715 in Mastodon's case (since Pixelfed is planning on adding support for the Masto API). It might still be possible in cases where authentication is required (e.g. fetching private data). I'm not going to close the issue for now because there's still the possibility of more discussion about this, though.

[spaceottercode]

I see what you mean. It's as if we would need to add an extra property to the JSON object: say avatar_local (or avatar_alt). The client would choose between the two. Other clients continue using the original one. Yeah, the UI/UX issues makes me opt for the 1st or 2nd solution. The 3rd while cool, introduces complexity. Solution 1 & 2 would maintain about the same front end. Anyhoot thought I mention it. Thanks for taking a look.

PS the avatar_static got me wondering if that's how masto implements the auto play anim gif feature.

[trwnh]

One other interesting thing is that Gravatar allows setting avatars with different "ratings" (G/PG/R/X) and the corresponding avatar is used on each Gravatar-enabled site based on the site's rating. So if you set PG and R avatars, you would see no avatar on G websites, the PG on PG websites, R on R websites, and R again on X websites. Basically, the avatar's rating gets shown on equal or higher-rated sites.

But implementing such a system would be a bit difficult to do over ActivityPub since there is no concept of a "site rating" yet. A lot of standardization work needs to be done so that there's a common spec for this stuff first (perhaps modeled after Gravatar or similar, but standard nonetheless).

[spaceottercode]

In retrospect the avatar property probably should have been a object instead of a string. Mastodon has both an avatar and an avatar_static (my guess is the latter is for strictly non-animated avatars and accessibility). As an object, an avatar object could conceivably house properties needed to provide alternative avatars, including the one used by Mastodon (e.g. static) or ones modeled after Gravatar. These properties, or at least the most common or useful ones, would need to be standardized eventually. Though I'm not against implementations ironing out AP a little here and there amongst themselves 😁

[trwnh]

The one problem with avatar_static is that it's part of the Mastodon API only, so it doesn't federate out over ActivityPub. If you look at the ActivityPub representation of the same account at https://mastodon.social/@trwnh.json then you can see there is only icon for avatars and image for headers. However, icon is allowed to be an array, although the example assumes this will be used for different sizes rather than different audiences. https://www.w3.org/TR/activitystreams-vocabulary/#dfn-icon

It's conceivably possible to define an extension that, like Gravatar, defines different avatars for different uses, because as far as I can see there isn't really a way to signal how to handle an array for icon. Existing implementations may expect there to only be one object (because this is what Mastodon currently does), and they would need to be able to figure out what each icon is supposed to represent. This might be done by summary, but perhaps there's a better property to use for this. Briefly scanning the vocabulary, I see a context that isn't really well-defined, so you could define a custom context that would potentially have to be parsed or standardized... or you could use audience to define actors or collections that are allowed to see certain icons... or any number of things. It'll take some work to figure out what the best vocabulary to settle on should be.