Integrating go-fed into Gitea


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:

m.Group("/activitypub", func() {

However, that would probably not sit well with the recommended usage of go-fed which looks like this:

		func(w http.ResponseWriter, r *http.Request) {
			if isActivityPubRequest, err := actor.GetInbox(w, r); err != nil {
				// Do something with `err`
			} else if isActivityPubRequest {
				// Go-Fed handled the ActivityPub GET request to the inbox
			} else if isActivityPubRequest, err := actor.PostInbox(w, r); err != nil {
				// Do something with `err`
			} else if isActivityPubRequest {
				// Go-Fed handled the ActivityPub POST request to the inbox
			// 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)

And maybe it would be more natural to setup a chi middleware and install it under the /activitypub root.

I’m new to these parts and possibly very confused :sweat_smile: What do you think ?


After studying how go-fed is integrated in writefreely, in GoToSocial and the apcore framework, I’m inclined to try and group all enpoints under /api/v1/activitypub and rely on:

  • go-fed/activity for:
    • 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 :slight_smile:

A commit is available to illustrate how /api/v1/activitypub could be implemented and passes integration tests… doing mostly nothing but paving the way.

What do you think?

@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.

  • Commits: git clone -b wip-go-fed
  • Title: activitypub: implement /api/v1/activitypub/user/{username}
  • Description:
These two commits:

* add [go-fed]( as a dependency of Gitea: it is a requirement to move forward with [federation]( 
* implement the **/api/v1/activitypub/user/{username}** endpoint which:
  * verifies the username matches an existing Gitea user;
  * creates an ActivityStream [Person]( using the [ActivityStreamsPerson]( object provided by go-fed;
  * sets the [Actor required fields]( (inbox, outbox) and the [Object required field]( (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](
* [Integrating go-fed into Gitea](


@techknowlogick gentle ping ?