Today I was looking into the best way to fit go-fed into Gitea. One option would be to have all the endpoints (there are not too many) under /api/v1/activitypub something like:
http.HandleFunc("/actor/inbox",
func(w http.ResponseWriter, r *http.Request) {
if isActivityPubRequest, err := actor.GetInbox(w, r); err != nil {
// Do something with `err`
return
} else if isActivityPubRequest {
// Go-Fed handled the ActivityPub GET request to the inbox
return
} else if isActivityPubRequest, err := actor.PostInbox(w, r); err != nil {
// Do something with `err`
return
} else if isActivityPubRequest {
// Go-Fed handled the ActivityPub POST request to the inbox
return
}
// Here we return an error, but you may just as well decide
// to render a webpage instead. But be sure to apply appropriate
// authorizations. There's no guarantees about authorization at
// this point.
http.Error("Non-ActivityPub request", http.StatusBadRequest)
return
}
)
serialization/deserialization of the message payload
go-fed/httpsign for:
signing messages
verifying the signature of signed messages
Which also means implementing the ActivityPub logic entirely instead of delegating it to go-fed. The reason why I chose this path is that it is unclear to me at this point what the logic go-fed actually implements (which is not to mean it does not implement any logic, just that it is unclear to me after reading the documentation and brrowsing the code). At the same time studying the above implementations I see there is a very significant quantity of code and logic left for the responsibility of go-fed application. And I find difficult to answer the following question: is it more work to implement abstractions proposed by go-fed (pub.Database, pub.CommonBehavior, etc.) or to implement the ActivityPub logic?
I may be wrong to go in this direction and if anyone think so, please speak up
A commit is available to illustrate how /api/v1/activitypub could be implemented and passes integration tests… doing mostly nothing but paving the way.
@techknowlogick I think the implementation is ready for review. Now comes the delicate part (because I do not have a GitHub account). Would you mind copy/pasting it on my behalf and create a pull request from it? Don’t hesitate to tell me if this is too much right now and I’ll ask someone else.
These two commits:
* add [go-fed](https://github.com/go-fed/activity) as a dependency of Gitea: it is a requirement to move forward with [federation](https://github.com/go-gitea/gitea/labels/theme%2Ffederation#).
* implement the **/api/v1/activitypub/user/{username}** endpoint which:
* verifies the username matches an existing Gitea user;
* creates an ActivityStream [Person](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-person) using the [ActivityStreamsPerson](https://github.com/go-fed/activity/blob/d866ba75dd0ff3ddd3a72b132b7cc16e01f6e006/streams/vocab/gen_type_activitystreams_person_interface.go#L12) object provided by go-fed;
* sets the [Actor required fields](https://www.w3.org/TR/activitypub/#actor-objects) (inbox, outbox) and the [Object required field](https://www.w3.org/TR/activitypub/#obj-id) (id). The type of the object is already set by go-fed.
It includes integration tests that verify the ActivityPub message can be decoded (using go-fed) on the receiving end.
Discussion topics:
* [Adding go-fed as a dependency to Gitea](https://forum.gitea.com/t/adding-go-fed-as-a-dependency-to-gitea/3996)
* [Integrating go-fed into Gitea](https://forum.gitea.com/t/integrating-go-fed-into-gitea/3971/3)
Refs: https://github.com/go-gitea/gitea/issues/14186
What do you think ?
