Grant proposal for federation in Gitea

Hi @cjs,

Only now do I discover the Go-Fed Work Tracker Megathread and the grant proposal part:

  • Write NGI0 Discovery grant proposals:
    • For ActivityPub testsuite completion
    • For engineering of an OCAP-based transport/routing protocol based off of eris and scr

I would be very motivated to work with you on a grant application to implement federation in Gitea with go-fed. I have some experience and although I do not really enjoy the administrative process (I’m a developer at heart), I acknowledge that there is value in clearly articulating the goals and outline the process to get there.

To the best of my knowledge there is no ongoing call for proposal at the moment, therefore no pressure, which I like (being extremely bad at doing things at the last minute). There will however surely be at least a few open calls by the end of the year and it would help continue the effort that will hopefully be bootstrapped if a developer is motivated to take baby steps with the seed funding (tiny tiny seed :seedling: :slight_smile: ) that was made available this week to work on federation for Gitea.

What do you think?


Thanks for reaching out. Let’s set up some time to do a voice call and discuss the details further? If possible, evenings during the week or anytime weekends are usually the best for me. If that’s not possible, I can perhaps find a time slot during a weekday, but will have to double check.


What about tomorrow Sunday July 11th, 2021 11am at ? I don’t expect anyone else would be interested to join the conversation but I would not mind if you’re ok with the idea.

For the sake of transparency, I’d like to record our discussion and post it here for archival. Also I have a bad memory and that helps me keep track of things :sweat_smile:

Sorry, I didn’t get a chance to read this before the time passed. :frowning: Perhaps a date Tuesday or later?

1 Like

Yeah, it was really short notice :sweat_smile:

What about Sunday July 18th, 2021 11am UTC+2 at ?

For the record, the meeting is confirmed. Anyone willing to join is welcome.

Which timezone is this meeting in?

1 Like

Oooops. It’s 11am Paris/Berlin time / UTC+2.

Here is what I’d like to discuss. This is not an agenda and it could go very differently, but right now that’s what I have in mind.

  • Acknowledge the status quo: Design Discussion: ActivityPub support + ForgeFed vocabulary did not make progress in over six month.
  • A 5K€ grant did not trigger an immediate reaction, which probably indicates there are not many people available for freelance / bounty work on Gitea
  • A grant application is an order of magnitude more money and it may allow people who are currently busy to pause their activities for a few months and work on federation in Gitea
  • The ideal grant application would fund at least two person full time during six months and be submitted by @cjs and @zeripath because they have an excellent track record on go-fed & Gitea respectively. But it could also work with two other persons, provided they have enough time to learn.
  • My incentive is not to be funded: my work is already funded for fedeproxy. My motivation is that fedeproxy would greatly benefit from a native implementation of federation in Gitea.
  • My contribution is to be responsible for writing a sensible grant application (similar to the fedeproxy grant application)
  • There is one condition to my involvement everything in the grant application process and after it is submitted is done in public (it starts here), 100% transparency. To get an idea of what I mean, see how the fedeproxy idea came to be, how the grant application was prepared down to detailed accounting of income an expenses.
  • I see three successive steps for the grant application to stand a chance:
    1. Two person willing and able to execute the work are interested (this is where we are now)
    2. A generic description of the project is written, using NLnet and NGI DAPSI guidelines and template as a reminder of what is required in every grant application
    3. Whenever a grant opportunity presents itself (which may be months from now), use the generic description to fill out the application
  • Writing a generic grant description that both makes sense and matches the grant application constraints is a lot of work. It took me no less than two weeks full time for fedeproxy and I expect it would take me up to four weeks for go-fed / Gitea because the subject is more difficult. Reason why I’m preparing well in advance.
  • Adapting the generic grant description to an actual call is two full days of work (for me… other people may do it faster but I’m not good at doing things quickly)
  • My next action item could be to draft a generic project description (see the one I wrote for fedeproxy for an example of what I mean).
1 Like

Sorry my signal was so poor in that conversation and cut out several times including right at the end.

Your plan seems like a good way to get things started.

I guess what we really need are proposals that are going to lead to concrete plans and PRs that can be merged.

However it was great to chat to you both!

1 Like

Here is the recording of the conversation.

1 Like

Yes. PRs merged in Gitea should be the primary deliverables :+1:

As discussed today, this conversation is going to move to GitHub - go-gitea/gitea: Git with a cup of tea, painless self-hosted git service so that it is more accessible to Gitea developers and the Gitea community.

Just finished up watching that call from earlier. Always nice to hear voices of people who’ve I’ve communicated with solely via text for some time.

Bonjour @dachary, I didn’t connect your username on Gitea’s forum that you were the same person behind fedeproxy, although I would’ve still treated you the same (hopefully I came across as kind and respectful. Again, I apologize for discourse eating some of your responses there).

@zeripath gave a fair representation of the context of the situation from Gitea’s side.

+1 for accounting for reviewers in the grant (per @zeripath’s point while this may have a possibility of cabal of contributors/maintainers attempting to force this through, there is a failsafe of needing a manager or owner to merge the PR to ensure that PRs and approaches match the project’s goals and PRs and nothing is rushed)
+1 for many small PRs vs 1 big PR (I suspect one barrier for devs right now is reading the spec to determine what could be a small PR that could be implemented, as that is how I feel personally. I would love to contribute, however with various administrative duties of being one of the project leads such as infra, sponsor & community management, and more, I am only able to focus on timeboxed development tasks. If someone where to say what a small PR could be, then I would be very much able to contribute that)
+1 for proactive reaching out users of go-fed

Some technical notes around a future implementation:
@zeripath has contributed an excellent queue system, and so that could be leveraged for background tasks required for federation (for inbound/outbound requests)
When importing PRs for inbound migrations, we fetch the diff (really the patch file) and save it as a git ref (eg. refs/prs/123), and so that logic (or similar logic) could be leveraged for at the very least of importing federated PRs (haven’t read the spec, but perhaps I’m assuming something like an AP request is made with a git patch file is made for federated PRs)

Minor rambling:
I foresee that likely the first PR as a proof of concept to show federation working would be federating users/user discovery (simple example would be to put the URL to a gitea user’s profile is a mastodon search box to fetch the user profile, avatar bio & url?). That would be outbound, then next we could do inbound user discovery (which would be used for future work). For inbound, already there is the concept of external users (from importing issues/PRs from github/lab etc…) which may be extended for use of this (or maybe we store federated users as another user type in the user table)

An apology for using some closed systems for the project (github, discord), there is some (slow going) progress being made to migrate to foss alternatives (which

Caveats: I have done very minimal reading the fedeproxy spec, and so if anything above is glaringly wrong or my assumptions are off, please do let me know :slight_smile:
Full disclosure: I am an elected member of the Codeberg Präsidium, and one of the elected project owner’s of Gitea.


Very interesting! That’s a strong incentive to create at least one or two tasks that are self contained.

Here is an idea: someone could create an issue description for that first step (and maybe split it into a few issue instead of a single one). So that someone else can conveniently work on it within a reasonable amount of time. @cjs do you see that as a first use case of go-fed within Gitea? In my opinion both writing the issues and implementing them is in the scope of the 5K€ grant . Creating a well written issue is work that can be funded in this context.

Nothing is in contradiction with the fedeproxy specs. Everything is in line :slight_smile:


For archive:

1 Like

For the record, the conversation continues here: