Add Webfinger endpoint

[KN4CK3R]

This PR adds the Webfinger endpoint for federation.

Supported schemes are acct and mailto. The profile and avatar url are returned as metadata.

[Ta180m]

This is a great start, but I think there are still a few additions to make to match what Mastodon and PeerTube currently do. We'll need to add another item to links containing the ActivityPub actor IRI (in this case something like https://git.example.com/api/v1/activitypub/user/USERNAME), a remote interaction link (this hasn't been implemented yet for Gitea), and an aliases field.

[realaravinth]

Towards federation! 🚀

I'm interested in how you/the Gitea devs are planning to deal with Issues and Pull Requests. Gitea and all GitHub-like forges support subscribing to issues and pull requests, which will send notifications to the user about issue/PR activity. This is different from watching the repository for all activities.

Modelling this in ActivityPub: Issues, Pull Requests and Repositories when modelled as ActivityPub group actors, can allow actors(users) to follow and receive notifications on activity, very much like how subscribe works. If this approach is correct, then we would have to deal with namespace collisions, how can an issue/PR/repositoriy share the same namespace as usernames?

I'm part of ForgeFlux, a software project involved in implementing federation for popular forges using APIs. Our implementation deals with namespace collisions using special characters. For more information, kindly see our webfinger implementation docs.

[6543]

@realaravinth if you are interested in this, a summary can be found at #18240 and the focabulary is in work by ForgeFed (#14186)

[Ta180m]

Towards federation! 🚀

I'm interested in how you/the Gitea devs are planning to deal with Issues and Pull Requests. Gitea and all GitHub-like forges support subscribing to issues and pull requests, which will send notifications to the user about issue/PR activity. This is different from watching the repository for all activities.

Modelling this in ActivityPub: Issues, Pull Requests and Repositories when modelled as ActivityPub group actors, can allow actors(users) to follow and receive notifications on activity, very much like how subscribe works. If this approach is correct, then we would have to deal with namespace collisions, how can an issue/PR/repositoriy share the same namespace as usernames?

I'm part of ForgeFlux, a software project involved in implementing federation for popular forges using APIs. Our implementation deals with namespace collisions using special characters. For more information, kindly see our webfinger implementation docs.

ForgeFed models issues, PRs, and repositories using the Ticket and Repository types, instead of Group. I don't think namespace collisions will be a problem, because these different actors/objects will have different IRIs.

@realaravinth Is there a specific reason for using ! as the deliminator instead of / in the ForgeFlux implementation?

[KN4CK3R]

This is a great start, but I think there are still a few additions to make to match what Mastodon and PeerTube currently do. We'll need to add another item to links containing the ActivityPub actor IRI (in this case something like https://git.example.com/api/v1/activitypub/user/USERNAME), a remote interaction link (this hasn't been implemented yet for Gitea), and an aliases field.

I did not add them because they are not there at the moment. The ActivityPub PR should add that.
This PR only provides the basic endpoint for users. If we want/need more actors than users this should be added afterwards.

[Ta180m]

Sounds good, I'll add those fields to my PR #19133.

Edit: Done in 43d82e1c582262d15222f8f3370ef95d9c65ac6c

[KN4CK3R]

Is it intended that private users now can not participate in federation?

[codecov-commenter]

Codecov Report

Merging #19462 (8a3403d) into main (d242511) will decrease coverage by 0.15%.
The diff coverage is 41.37%.

@@            Coverage Diff             @@
##             main   #19462      +/-   ##
==========================================
- Coverage   47.51%   47.35%   -0.16%     
==========================================
  Files         944      952       +8     
  Lines      131549   132433     +884     
==========================================
+ Hits        62500    62715     +215     
- Misses      61541    62159     +618     
- Partials     7508     7559      +51     

Impacted Files	Coverage Δ
cmd/dump.go	0.71% <0.00%> (-0.01%)	⬇️
cmd/serv.go	2.33% <0.00%> (-0.06%)	⬇️
models/action.go	48.61% <0.00%> (ø)
models/error.go	36.46% <ø> (-0.03%)	⬇️
models/issue_label.go	68.02% <0.00%> (ø)
models/issue_lock.go	0.00% <0.00%> (ø)
models/issue_project.go	31.70% <0.00%> (ø)
models/organization/team_repo.go	76.19% <0.00%> (ø)
models/pull.go	56.62% <0.00%> (+0.80%)	⬆️
models/statistic.go	0.00% <0.00%> (ø)
... and 153 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3ec1b6c...8a3403d. Read the comment docs.

[Ta180m]

Is it intended that private users now can not participate in federation?

By "private", do you mean their email is private? If so, I think they should still participate in federation.

Edit: I misunderstood the question. I agree that private users should not participate in federation.

[6543]

hmm event. add 1 or 2 calls from an integration test - just to make sure it stays working

[realaravinth]

@realaravinth if you are interested in this, a summary can be found at #18240 and the focabulary is in work by ForgeFed (#14186)

@6543: thank you, subscribed to both issues :)

ForgeFed models issues, PRs, and repositories using the Ticket and Repository types, instead of Group. I don't think namespace collisions will be a problem, because these different actors/objects will have different IRIs.

@Ta180m: ForgeFed Ticket inherits from object but has a followers attribute to accommodate subscribers. The followers attribute in the forgefed document links to AP followers collection, which says:

5.3 Followers Collection

Every actor SHOULD have a followers collection

IMHO inheriting from actor is more semantically accurate, thoughts?

Is there a specific reason for using ! as the deliminator instead of / in the ForgeFlux implementation?

Nothing in particular. I needed delimiting character that wasn't a part of the PRECIS framework(RFC8264) IdenfifierClass so that a valid username entered by a user won't contain the delimiting character and I saw lemmy using it for representing communities :D

[wxiaoguang]

Some comments and questions.

Still have the question why not use url.Prase directly.

[6543]

still lgtm