So, I was at lunch with @pilou yesterday, and the topic of the exact type of interaction came (at the same time as burgers).
I was wondering exactly what a federated forge would look like, but I feel that to me, the model that would work is to replicate what a federate microblogging platform look like.
Github, and by extension, Gitlab, and Gitea, has a concept of homepage, where you see tasks, changes and commits, pushed to repository. You can also start to follow others repositories and people.
So it would, to me, make sense to start the federation here, and let people from server A follow project/users from server B as if their projects were local to server A.
Starting by that has numerous benefits:
- this only requires anonymous outbox and inbox supports, without any authentication issues (that might be thornier). That part should be the simplest to implement.
- the UX/UI work to integrate that would be minimal and quite non intrusive. You just need a way to follow someone remote (so 1 form for that), and a way to signal a event on the display is on a distant server.
Then we can iterate from here, based on the previous UX studies.
For example, does federation mean to be able to authenticate to remote forge to post on remote bugs, to replicate bug internally, to have bug on forge A depend on bugs on forge B state (eg, federated dependencies), to be able to create a readonly duplicate of a remote project/repo ?
Once the federation is bootstraped with simple federated follow, then multiple ways to use the information can be experimented with quick mockups.