Data model and vocabulary

[dachary]

@nchauvat

Or to have a project replicated from github in our heptapod, and when we add an issue to it, its get added to github on the other side.

This is precisely the use case I’m most interested in. Could not agree more

@nchauvat

Now that I think of it, I am not so sure FEDE.has_text_diff is such a good idea, because the underlying DVCS already has a synchronisation mechanism, why redoing it ?

As I said, I know little about ActivityPub and one thing I have not understood is why sending the content when doing outbox.addActivity() instead of just stating “the object at this url changed” and let the client GET the new version at this url in case it wants the new version.

Very good point and I was going in the wrong direction, I stand corrected. Looking at the PeerTube documentation and trying to transpose in the context of fedeproxy:

• A PeerTube server is the equivalent of a software project (e.g. GitHub - ceph/ceph: Ceph is a distributed object, block, and file storage platform)
• A PeerTube video (represented by this ActivityPub extension) is the equivalent of a commit in the software project
• The protocol to fetch a PeerTube video (i.e. http, webtorrent, etc.) is the equivalent of the repository protocol (i.e. git protocol, mercurial protocol)
• The format of the content of a PeerTube video (i.e. mp4, webm) is the equivalent of the format of the data contained in the repository (i.e. anything really)

@nchauvat

For example I find interesting to make a gitlab issue appear as a toot in mastodon and when users reply to it, the comments are added to the issue in gitlab.

To continue with the comparison with PeerTube, there are multiple protocols and formats, including a custom REST API and ActivityPub with extensions. In the case of fedeproxy there are git/mercurial protocols and we’re discussing here about what should be communicated via the ActivityPub protocol. And I also think interactions with software development issues via ActivityPub messages are in scope.

I spent time looking at

• ActivityPub
• Activity Streams 2.0
• Activity Vocabulary
• JSON-LD 1.1 and now better understand @nchauvat advice regarding https://ontologi.es/ (doap-bugs + doap-changesets + doap-tests + doap-deps) because it really is designed for reusing RDF with JSON

in addition to the PeerTube documentation and the associated code. It begins to make sense but I’m still unsure about how to put it all together. The above use case can be rewritten as:

• On a given project P on GitLab
• User U comments on an issue for P on GitLab
• Fedeproxy for GitLab:
  • uses the GitLab API to get the issue
  • saves it in a file using the format used by GitLab import/export
  • commits the file in the repository of the project (in a branch dedicated to saving issues)
  • published the permalink of the commit including my comment as an ActivityPub activity in the outbox of user U on GitLab
• Fedeproxy for GitHub polls the fedeproxy for GitLab and upon the reception of the permalink
  • fetches the commit from the GItLab repository
  • reads the content of the file describing the issue and uses the GitHub API to apply the differences, e.g. for each of my comments verifies it is up to date (creates a new one if it does not already exists, update the message if it existed but does not contain the same thing, removes if it is absent)

I realized that although it would be nice to extend ActivityPub to represent issues and other aspects of a software project in the way forgefed does, it is only one of several ongoing efforts to have a format representing a software project (other than the code itself):

• https://forgefed.peers.community/vocabulary.html
• https://ontologi.es/ (doap-bugs + doap-changesets + doap-tests + doap-deps)
• https://docs.gitlab.com/ce/user/project/settings/import_export.html
• etc.

The above use case proposes to use https://docs.gitlab.com/ce/user/project/settings/import_export.html because it is easier in the context of GitLab. But that may be a mistake because it will never evolve into a standard. However I’m conflicted about the other two because I’m not entirely sure they will evolve into a standard either and they would be significantly more complicated to use to represent all aspects of issues and pull/merge requests that are in the scope of fedeproxy.

This is where I am today