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
Is Gitea API incomplete?
What exactly API calls are needed in order for such a bridge to be possible?
I don’t think that ForgeFed bridges can exist.
What I declare basic functionality—the ability to represent users other from foreign instances—is currently missing in most* applications you might bridge to (GitLab, Gitea), so you would only be able to represent a somewhat strongly limited subset of what ForgeFed is – which then is just an AP bridge, but not a ForgeFed one.
I do not want to say that following a project won’t work this way, but following is only a small part of ForgeFed, the bigger part is interaction (open issues as a user from a foreign instance, comment on issues as a user of a foreign instance, collaborating on code as a user from a foreign instance, …).
* right now only @fr33domlover’s Vervis can do this.
I am interested in working on implementing support in Gitea. Whether as a fork, patch set or directly upsteam remains to be seen. Whichever seems to fit the community best is ok with me.
hi rob -
there is another option, as i described in a previous post -
that is, to make a stand-alone demo service written in golang
- that would serve as a reference implementation for any of the
other options that you mentioned, and any new forge-fed
compatible golang programs that may be invented in the future
even if your eventual goal is to integrate fully into git-tea, a
golang reference service would be a half-way, jumping off point
for any sort of further work using golang regardless of who does
that, or when, such as gogs integration
I am working on the basis of the Gitea integration, see https://github.com/go-gitea/gitea/issues/9045. I was pretty unproductive the last months but just got up again this week.
No trouble. I’m sure there is plenty to be done and I’m happy to help. I’m also around irc under the same username if you want to chat casually about it.
I’m also interested in filling out spec compliance in general with go-fed/activity which is a great base library. Then eventually implementing forge specific language as well.