Advancing federation in Gitea

Posted by southerntofu following our exchanges on libera#peers:

Bonjour @pilou,

While working on the grant application today, I ran into a question that is worth posting on the issue. Would you be so kind as to copy/paste it on my behalf?

Cheers


Bonjour,

While working on the grant application today, I ran into a question that is probably worth discussing before moving forward. Go-fed is AGPLv3+, and Gitea is MIT. Adding Go-fed as a dependency of Gitea means that Gitea, as a whole (meaning Gitea+Go-fed+other dependencies), can only be released under the AGPLv3+. Or not released at all.

To be more precise, here is the minimal set of actions required to distribute a gitea executable that contains Go-fed:

  • The https://github.com/go-gitea/gitea repository needs no change
  • A license notice stating the executable is under the AGPLv3+ license must be prominently added to the user interface (e.g. added at the beginning of js/licenses.txt)

This is not the only possible course of action, only the simplest.

What do people think about this?

1 Like

Posted

2 posts were split to a new topic: Grant application for federation in Gitea

This is no problem. Only apcore is AGPL, but this project is an opinionated server framework, meant to make life easier in implementing a full-blown server. The go-fed libraries are - probably very deliberately not under AGPL, but BSD-3 license. Gitea would not need apcore and already has a bunch of server aspects implemented their own way. They’d need to reimplement some things again, but not involving too much work (e.g. webfinger).

2 Likes

@aschrijver thanks!

@pilou would you be so kind as to post the following on my behalf?


Oh… my bad, thanks for the clarification!

1 Like

Posted

1 Like

Since it seems likely that nobody will be interested in the 5K€ grant, it would be a good thing to set an expiration date. Would November 1st 2021 be sensible?

1 Like

@pilou would you be so kind as to post the following to this issue ?


@zeripath in the 1.16 plan you write “(It’s worth noting that although this may appear orthogonal to things like federation - this is key to making federation possible.)”. You mentioned this a few times and I concur: authentication / authorization is a building block of federated activities. Maybe I’m stating the obvious but here it is: if issues were created around that topic that clearly articulate how they are relevant to federation, it would be possible to fund their implementation with the money earmarked for federation. My 2cts :wink:

1 Like

Posted!

1 Like

3 posts were merged into an existing topic: Grant application for federation in Gitea

It seems sensible to me.

1 Like

@pilou would you be so kind as to post the following reply to this message?


@zeripath @cjslep here is an idea for the first baby step: creating a keypair for every user that will be used to sign http requests (see also the IETF draft). Although signing http requests is not required by ActivityPub or ActivityStreams, it is mentioned in the ActivityPub wikii. Since mastodon, bookwyrm and other ActivityPub implementations verify and expect a signature, it is de facto required.

If it sounds sensible to you, I think the creation of the corresponding issue as well as its implementation is eligible to be funded by the 5,000€ grant made available by the fedeproxy project a month ago:

  • Write a detailed issue to create a keypair for every user, with technical details that would allow a skilled Go developer with no prior knowledge of the codebase to work on it
  • Propose a pull request to implement the issue, add it to the 1.16 roadmap and get it merged
2 Likes

Posted

1 Like

For the record @techknowlogick created an issue at:

1 Like

I created a second issue for another “baby step” issue towards federation:

2 Likes

Excellent idea, that’s actually the first endpoint that was implemented in fedeproxy. :+1:

I have what may be a naive question regarding the private keypair issue. It is in the 1.16 milestone but not in the Plan of Gitea v1.16. What is the difference?

2 Likes

The “plan of gitea v1.16” issue is a place for maintainers to state what they intend to work on for a specific version, but I have been lazy and just put things into the milestone. I will make a comment about that now in the thread.

2 Likes

Am I right to assume the storage secret PR mentionned here

is this one

?

That is indeed correct, my initial implementation won’t include it (as to not be blocked by the other PR), however it will be fairly easy to update the implementation as needed once the secrets PR is merged. As a related note, when checking how other federated software (mastodon, peertube, pixelfed, etc…) implemented this they all have it stored as plain text but perhaps they should also change that in the future as well (but this is up to each of those maintainers to decide to do that if they so chose).

3 Likes