✨ Add WebFinger / ActivityPub avatar provider#140
Conversation
networkException
force-pushed
the
webfinger-activitypub-avatars
branch
from
1c577e3 to
cef80ca
Compare
|
Interesting idea, but I'm not sure this "fetch webfinger first, if it doeesn't exist, fetch gravatar" logic is understandable from the UI. It would also be nice if you could update the tests to include this change. :) (If you want to update the API documentation, it's here, but I could do this as well.) |
|
hm I don't quite know how to improve the UI, do you think a radio button to select the avatar provider would be good? |
networkException
force-pushed
the
webfinger-activitypub-avatars
branch
2 times, most recently
from
0daf3ae to
0ed9176
Compare
networkException
changed the title
networkException
force-pushed
the
webfinger-activitypub-avatars
branch
from
0ed9176 to
20a2112
Compare
|
In addition to the UI changes we discussed last time, I've basically rewritten the entire fetching to be a lot more robust and support for having a mastodon server fetch the user on behalf of us. With that comes an access token and url that need to be configured, I've done my best to implement this but I don't think it actually works in production - how would I implement such a config value properly? |
|
Thanks for putting this much work into it – and sorry for taking so long to look at it. The first two commits look great. And, most importantly: This breaks the API (and the tests checking the API). |
|
We could probably think about proxying those images in the future. But the next TODO is making the test pass again. |
|
oh I thought I pushed my local changes already, I have some patches to rework this including api compatibility |
|
I pushed my changes to main...networkException:mete:webfinger-activitypub-avatars-diverging, let me know what state you want to continue working on / changes to my diverging branch. In summary my changes make use of the |
|
Yours looks way better, let's use that one. |
YtvwlD
force-pushed
the
webfinger-activitypub-avatars
branch
from
c2d0939 to
e0c9078
Compare
|
The tests pass now. Aside from the two small conflicts: Are we ready to merge this? |
|
I just noticed that the missing avatar image is probably AGPL licensed, we might want to use something else |
|
Just removing the image for now would look like this (Left Webfinger; Right Gravatar) |
networkException
force-pushed
the
webfinger-activitypub-avatars
branch
from
fa1c2a3 to
c8ae20f
Compare
|
Rebased on |
This patch updates the database schema in preparation for supporting more avatar providers. It adds a new per user avatar_provider column and renames the email column to avatar to allow more generic input which will be interpreted depending on the provider.
This patch starts preparing the user interface for supporting multiple avatar providers by adding the ability to edit these values in the edit form and updating the user overview page. It also introduces an avatar provider enum currently only containing gravatar. As the current API version implement still expects an email field we return email instead of avatar and avatar_provider and only have it be non null when avatar_provider is set to gravatar. Likewise passing an email in update or create call sets avatar to the email and avatar_provider to gravatar.
This patch adds the webfinger and faraday gems in preparation for webfinger and activitypub based avatar resolution. Note that faraday is a transitive dependency of webfinger.
This patch introduces a new avatar provider based on the changes from
the previous commits.
The WebFinger / ActivityPub provider ("webfinger" internally)
loosely interprets the avatar field in a user as an RFC 7565 acct URI,
the library used also allows only specifiying a domain name though.
Based on this it will contact the host and query the WebFinger endpoint.
If the WebFinger response contains an avatar relation, the link contained
in that relation will used.
Only some fediverse software supports this however, as such we also
implement a tiny bit of ActivityPub and directly query the user using
its "application/activity+json" relation.
Given a Mastodon url (and optionally an access token), mete can also
use the Mastodon client api to resolve the actor returned by WebFinger,
which is generally more reliable than speaking ActivityPub directly, as
requests can be signed by the Mastodon server.
The results of these lookups will be cached for one day and can be
invalidated by updating the user from the UI.
networkException
force-pushed
the
webfinger-activitypub-avatars
branch
from
c8ae20f to
81a2e38
Compare
|
Rebased, needs another round of testing and probably removing the AGPL licensed missing avatar png |
This icon is CC0.
|
This removes the icon, for starters. |
|
Thank you very much for your contribution! And sorry for taking this long to merge. |
2 participants
This pull request introduces a new avatar provider system and a new provider.
The WebFinger / ActivityPub provider (
webfingerinternally) interprets the avatar field in a user either as an RFC 7565 acct URI or, if it does not contain an@symbol, a RFC 3986 host string.Based on this it will contact the host and query the WebFinger endpoint.
If the WebFinger response contains an avatar relation, the link contained in that relation will used.
In most cases however, for example when querying a Mastodon, Akkoma or Calckey user, the WebFinger response will not contain such a link. Then, the provider will look for an ActivityPub actor using an
application/activity+jsonlink in the WebFinger response.This pull request implements two strategies for obtaining an URL for the avatar image of an ActivityPub actor:
With no additional information given, mete will try to contact the hosting server directly. This might fail for various reasons such as missing request authentication or signature.
Given a Mastodon client access token, mete will contact the according Mastodon server and ask it for the profile picture of the actor. Note that depending on the server's settings, this might cause the profile picture to be fetched from the server's cache instead of the actor's server directly.
The results of these lookups will be cached for one day and can be invalidated by updating the user from the UI.