Background
ForgeFed defines an ActivityPub federation protocol for software forges such as Gitea and Forgejo. The spec adds forge-specific actor types (Repository, TicketTracker, PatchTracker, Project, Team, Factory, Workflow, Roadmap, ReleaseTracker, Organization), object types (Commit, Branch, Push, Ticket, Patch, Milestone, Release, Review, SshKey, and others), and properties for commits, branches, tickets, reviews, access control, and organization membership.
Fedify currently does not expose this vocabulary. Building a ForgeFed-compatible application on top of Fedify requires using untyped extensions or custom JSON-LD handling.
Proposal
This should live in a separate @fedify/forgefed package rather than in the core. The ForgeFed spec is still marked as a work in progress, so keeping it isolated would let the ForgeFed bindings evolve without forcing churn in the core package. Users who don't need forge federation also avoid the extra API surface and bundled context.
The package would provide:
- Typed classes for all ForgeFed actor types
- Typed classes for all ForgeFed object types
- ForgeFed-specific property accessors
- A preloaded ForgeFed JSON-LD context, registered so Fedify's document loader doesn't need to fetch it over the network
Initial scope
Actor types
Repository
TicketTracker
PatchTracker
Project
Team
Factory
Workflow
Roadmap
ReleaseTracker
Organization
Object types
Commit
Branch
Push
Ticket (covering both issues and merge/pull requests)
Patch
EnumValue, Enum, Field (workflow-related)
Milestone
Release
Review and its subtypes (CodeQuote, CodeSuggestion, Thread, Approval)
SshKey
Properties
All properties from § 8.2 of the ForgeFed spec, including commit metadata, branch refs, ticket assignment and resolution, access control, workflow fields, milestones, releases, merge request state, and organization membership.
Tasks
Background
ForgeFed defines an ActivityPub federation protocol for software forges such as Gitea and Forgejo. The spec adds forge-specific actor types (
Repository,TicketTracker,PatchTracker,Project,Team,Factory,Workflow,Roadmap,ReleaseTracker,Organization), object types (Commit,Branch,Push,Ticket,Patch,Milestone,Release,Review,SshKey, and others), and properties for commits, branches, tickets, reviews, access control, and organization membership.Fedify currently does not expose this vocabulary. Building a ForgeFed-compatible application on top of Fedify requires using untyped extensions or custom JSON-LD handling.
Proposal
This should live in a separate
@fedify/forgefedpackage rather than in the core. The ForgeFed spec is still marked as a work in progress, so keeping it isolated would let the ForgeFed bindings evolve without forcing churn in the core package. Users who don't need forge federation also avoid the extra API surface and bundled context.The package would provide:
Initial scope
Actor types
RepositoryTicketTrackerPatchTrackerProjectTeamFactoryWorkflowRoadmapReleaseTrackerOrganizationObject types
CommitBranchPushTicket(covering both issues and merge/pull requests)PatchEnumValue,Enum,Field(workflow-related)MilestoneReleaseReviewand its subtypes (CodeQuote,CodeSuggestion,Thread,Approval)SshKeyProperties
All properties from § 8.2 of the ForgeFed spec, including commit metadata, branch refs, ticket assignment and resolution, access control, workflow fields, milestones, releases, merge request state, and organization membership.
Tasks
@fedify/forgefedpackage skeleton (JSR + npm dual publishing, same as other@fedify/*packages)Repository/Ticketusage example