@ireneistaIrenes (many) @vtrlxVictoria i was hoping to solve this in phases:
(1) frontend-level API, like LSP for code collab
(2) propagating the frontend info, via federation or via git-notes (preferably git-notes as mentioned)

i imagined this would produce a useful v1 prototype where users can collaborate without a shared central forge, and using their own client instead of the forge's web frontend. as you noted, the pull-only nature of this mitigates several issues—access controls that currently exist for git and can link signed data to a public key can be reused

that would be an alternative to a forge, and would reuse access controls we already have for code collaboration. i'm having trouble figuring out the analogy to instance-level blocking in this analogy—if users only pull from remotes they trust and are actively collaborating with, what opportunity exists for vandalism and harassment?

i think code forges would continue to maintain access controls for git remotes, so they would be able to employ existing moderation tooling for this approach. i'm clearly unfamiliar with how trust scoping works in oauth, but using git as our "transport layer" seems to also allow us to delegate moderation instead of imposing additional access controls in this protocol. would you agree with that? or is there an attack scenario i'm missing that would require identity verification in this protocol?