-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Add WebFinger / ActivityPub avatar provider #140
base: main
Are you sure you want to change the base?
✨ Add WebFinger / ActivityPub avatar provider #140
Conversation
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? |
0daf3ae
to
0ed9176
Compare
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. |
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 |
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.
fa1c2a3
to
c8ae20f
Compare
Rebased on |
This pull request introduces a new avatar provider system and a new provider.
The WebFinger / ActivityPub provider (
webfinger
internally) 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+json
link 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.