Interested in contributing

[ghost]

I'm hoping to work on forgefed integration in gitea, or a standalone go forge.

As there is a lot of prior work done here already it only makes sense to improve the overall community by contributing to this and related work under go-fed.

I'm not really sure where to start at the moment so just wanted to drop in here and see if there is something you would recommend to start with or somewhere else you might need help.

[cjslep]

Thanks Rob for reaching out!

Summarizing our video call, for you & posterity to see:

• Best place to start is ActivityStreams manipulation: go-fed/activity/streams, for example passing an ActivityStream JSON literal string into a JSONResolver, and in callback functions (like func(context.Context, vocab.ActivityStreamsCreate) error {}) play around with the ActivityStreams API.
• Next, check out ActivityPub: the FederatingActor in go-fed/activity/pub, which has a small API. The devil is in the constructor, which takes a bunch of interfaces: func NewFederatingActor(c CommonBehavior, s2s FederatingProtocol, db Database, clock Clock) FederatingActor. Stub out and mess around with it.

Then, if go-fed is the solution going forward, we can talk about the ForgeFed RDF ontology and getting it code-generated for forgefed.

Some design choices/notes about go-fed I had mentioned:

For ActivityStreams:

• Focuses on vocabulary correctness at compile-time, not run-time (ex: accidentally trying to get orderedItems from a regular Collection). Consequence is binary bloat in sheer code generated.
• Type assertions over reflection (faster at run-time)
• Client code uses interfaces. Thus technically, you could swap out the go-fed impl for a different code-generated or hand-tuned impl while still using the go-fed interfaces.

For ActivityPub:

• Pretty much only limits itself to the S2S and C2S spec, and no more. Has some optional default behaviors provided for things like Create or Delete (but defaults can be augmented or overridden).
• Defers everything (and I do mean everything) not in the spec to the client code, which can make it difficult and unwieldy. Therefore, integrating into an existing codebase like gitea will be interesting, and I'm not opposed to go-fed changes to make things easier.
• Other technologies that the Fediverse community has adopted (ex: HTTPSigs, NodeInfo, webfinger) are not provided. I do have at least a supplemental httpsigs library under the go-fed banner to help, but it does take engineering work to put them together.
• go-fed/activity/pub implements a synchronous process (but can have asynchronous S2S delivery). To make async, it requires client code to call Actor APIs in a work queue or something similar, as the impl attempts to call Lock and Unlock appropriately.

Concluding remarks:

• I'm open to feedback. I am working on a revamped website + tutorial, and hearing your experience learning about the library will help me write a better resource.
• go-fed is production-tested S2S, but not C2S
• Thanks for reaching out!

[cjslep]

Update: v1.0.0 has now been released. :) If you would like advice with integrating into gitea, let me know.

[aschrijver]

FYI - Cross-referencing to current open Gitea issues related to ForgeFed:

• Federation for organization, repositories and users, Federation for organization, repositories and users go-gitea/gitea#1612
• Support federated pull requests, Support federated pull requests go-gitea/gitea#184
• Preparing for Federation: "Remote" Users / Federated ID, Preparing for Federation: "Remote" Users / Federated ID go-gitea/gitea#9045

As well as 2 mentions on the Gitea Roadmap issue: go-gitea/gitea#6998 (comment) and go-gitea/gitea#6998 (comment)

[aschrijver]

@robjloranger if you are interested in contributing, then @cjslep wrote an extensive report of steps to be taken to get others up to speed. Check the issue at go-gitea/gitea#14186