Are we going to integrate with Gitea, or we will implement own git service?
The current strategy mainly involves integrating ForgeFed into existing systems.
@fr33domlover building it into Vervis,
and myself slowly into GitLab.
Gitea also was is discussion but nobody is working on it.
While the Gitea developers are interested in ForgeFed, they will need a ready spec to implement it themselves.
But the spec is still in the works, so currently it’s not expected that someone not involved with the ForgeFed working group will start playing around.
I don’t know of any plans to implement a ForgeFed-native forge.
Without integration (federation^^) with existing systems the resulting forge might not be very attractive anyway, it would just be another island. I would say that could be a reason for focusing on existing systems.
I think a lot of guys use Gitea only as git repository, and they don’t want to have activitypub because they are not going to use it So I think Gitea should implement extensions API.
I just want to add, Vervis is actually a ForgeFed native forge, it was meant from the beginning to be federated. So it’s going to be (maybe already is, at least partially) an example of a forge with federation at the core.
The Gitea team seems to be waiting for s spec, but if someone wants to start working on federation in Gitea now, that’s totally possible and very welcome and I’d love to help, give guidance, interoperate, etc.
i would add that gitea does not need to do anything - any forge that is free software can be made to be forge-fed compatible - it is not important whether the upstream developers approve of the idea, or are interested at all - if it is free software, someone can make a forge-fed compatible fork, or maintain a forge-fed compatibility patch-set
it would be nice if forges would take it upon themselves to implement; but it is not necessary - anyone who wants to see it be, can do the work, then voila, the world will have it
my idea is to write bare-bones python, ruby, and go reference services in tandem with vervis as the spec takes form - that is not a demanding task and is straight-forward to do - those reference services can be used by any interested in implementing the protocol in any forge written in those languages - i have already started on the python and ruby services, and i will probably make pagure to be forge-fed compatibility when the time is right
We could implement a “router” which will fetch the data from git service apis and then represent it as activitypub
yes that idea has been proposed, to make a generic standalone API
bridge that could be dropped in beside any forge unintrusively -
the problem with that, is that most self-hosted forges do not
have a complete API - i think that currently, only gitlab does
The status of the ForgeFed spec has very little to do with the ability to start implementing federation. You can add actor documents, HTTP signatures, activity async delivery, following/unfollowing of users and repos, bssic UI changes, and even forge-related stuff if you just come to IRC/Forum and ask about the not yet documented things and get some hints.
We just need motivated people with some dev skills and a bit of free time.
TODO: Document on the website who’s working on what