Strategy for ActivityPub features
Background
ActivityPub is a broad-reaching feature that will allow GitLab instances to interact with the Fediverse using the ActivityPub protocol. See the parent Epic Support ActivityPub for GitLab (&11247) for additional discussions and context.
These features are being contributed by @oelmekki, a very active community contributor with support from @jpcyiza and groupsource code.
A Blueprint has been approved and merged, see also Follow-up from "ADD ActivityPub blueprint" - ex... (#426174)
This issue is a discussion of how these features will be supported by GitLab and which group(s) will own them. At this point it is not clear if this feature will be activated on GitLab SaaS, but a discussion of potential impact should include the GitLab Infrastructure team.
Infrastructure Considerations
The current scope of ActivityPub will implement actors for:
Additional actors can also be added. The potential increase in traffic on GitLab SaaS should be considered, as well as the need to implement rate limiting and throttling.
Potential Complexity
See the Mastadon implementation in Rails for an indicator of potential complexity.
Product Considerations
There are several aspects which need direction from Product, some of which were discussed on a 25-SEP-2023 sync call GitLab internal only
The feature is comprised of a foundational component, and then feature-specific Actors are implemented on top of it. Currently only the Releases ActivityPub is implemented.
- Should this be activated for public projects only (cc @tachyons-gitlab) ?
- Including private projects would add the need to overlay potentially complex authorisation rules across instances
- Will it be activated on GitLab SaaS?
- Which group(s) will own and support the features?
- Do we want to limit the extent of the implementation?
- Will supporting elements be built? eg: API endpoints, rate limiters