Posted by southerntofu following our exchanges on libera#peers:
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?
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?
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).
@pilou would you be so kind as to post the following on my behalf?
Oh… my bad, thanks for the clarification!
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?
@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
3 posts were merged into an existing topic: Grant application for federation in Gitea
It seems sensible to me.
@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:
For the record @techknowlogick created an issue at:
I created a second issue for another “baby step” issue towards federation:
Excellent idea, that’s actually the first endpoint that was implemented in fedeproxy.
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.
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).