Issue federation development plan (June & July 2021)

Key takeaways of the discussion with @arthurlogilab:

  • There is a confusion between referencing an issue (i.e. mentionning an issue in another issue) and federating an issue which essentially means copying the issue and keeping this copy up to date
  • Merging two users may not be implemented as expected in GitHub (see successors)
  • Getting a root token on a forge to deploy fedeproxy is a requirement that is too strong: sysadmins will not trust fedeproxy with a root token until it has a good track record of not containing bugs that may leak or loose data. It is simpler to assume a root token is available for the initial implementation. But the next step is to make it so fedeproxy provides the user with the desired experience even when the token is an application/user token. For instance it will not be able to create users and a workaround is needed to represent comments that are authors by users that exist on the remote forge but not on the local forge.
  • The separation of responsibility between the two communications channel (ActivityPub & git) must be articulated: it is unclear.

When explaining how DVCS is required to synchronize the issue tracker state between forges during yesterday’s update, I realized that it is quite confusing. Because ActivityPub is intuitively thought to be the source of truth. If the information is read from the DVCS, why is there a need for ActivityPub at all?

To clarify the relationship between the DVCS and ActivityPub when it comes to issue trackers, it would be best to add one goal: Adding an issue comment to an existing issue using the forgefed issue type.

If a user wants to +1 on an issue, they do the following:

  • User B exist on Forge B and does not have an account on Forge A
  • User B wants to +1 the Issue A on Forge A
  • User B goes to the “plus one” tracker of the fedeproxy user on Forge B
  • User B opens an issue in the “plus one” tracker on Forge B with the URL of Issue A
  • Fedeproxy mirrors Project A from Forge A into Project B on Forge B
  • Fedeproxy federates Issue A into Issue B of Project B on Forge B
  • Fedeproxy +1 Issue B
  • The issue federation copy over the +1 from Issue B to Issue A
  • Fedeproxy adds a comment in the issue of the “plus one” tracker with a link to Issue B
  • Fedeproxy closes the issue of the “plus one” tracker

For the record, there is no project export API endpoint in Gitea and no feature to dump a project (issue, merge requests, etc.) in a file.

The description was updated: the GitLab export format is no longer used, a format is created from scratch.

I no longer think is a viable choice because of the reasons described here and going back to copy/pasting code from BookWyrm would be best.

This is not possible because BookWyrm is not Free Software. It is a useful source of inspiration but the code cannot be re-used as is.