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 @anon20068248, 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 
Full disclosure: I am an elected member of the Codeberg Präsidium, and one of the elected project owner’s of Gitea.
) that was made available this week to work on federation for Gitea.
Perhaps a date Tuesday or later?