Data model and vocabulary

[dachary]

@nchauvat

I had overlooked the fact that you wanted to setup a proxy that would use the API to get the data, then expose that data using ActivityPub. For some reason I was thinking about modifying GitLab, but of course this can not be done with GitHub. Ok.

Exactly. Hence the “proxy” part of the project, to be able to do something when modifying the server code is not an option, which is true for GitHub.com but also for GitLab.com. However I’m convinced using the API and a proxy must be designed as a temporary measure that will disappear once the forges have federation natively implemented. Which is really tricky because it’s so easy to forget the “temporary” aspect when working on a project. One way to achieve that is to translate every aspect of the proxy into merge requests for GitLab/Gitea and try really hard to get them merged. The discussion and resistance, the need to split such merge requests into tiny baby steps, etc. should keep fedeproxy from drifting into something that is too far ahead and (most likely) disconnected from what is ultimately desirable.

@nchauvat

That also explains why you want to export everything, store it onto the disk and diff it the next time you query the project data.

Could we separate the two ? There is one communication channel between the forge and the proxy and another one between the proxy and the fediverse using ActivityPub.

That sounds sane, is it something like:

• GitHub ← GitHub API → fedeproxy
• fedeproxy ← ActivityPub → fediverse

@nchauvat

My comments were targeted at the second communication channel. This is the place where I think using RDF written as JSON-LD and the doap* ontologies is making the most sense, because the doap data model is already in use.

For example https://www.cubicweb.org/project/cubicweb?vid=doap is a description of the cubicweb project using DOAP. It is serialized as RDF/XML instead of RDF/JSON-LD, but that is a detail. What is important is that any application that can load and transform DOAP data can make sense of it. I am convinced this is something to leverage and build on.

Understood, thanks for clarifying. I’d like to say it’s crystal clear but I’m afraid not. Thanks to your explanations it now makes a lot more sense. 48h ago I was still quite confused about many aspects. But I still think I’m missing a few very important parts of the puzzle.

I should take a look at bots designed to be ActivityPub clients (GitHub - mastodon/mastodon-bridge: Moved to https://source.joinmastodon.org/mastodon/bridge, GitHub - yogthos/mastodon-bot: a bot for mirroring Twitter/Tumblr accounts and RSS feeds on Mastodon) and others with a similar purposes (GitHub - zedeus/nitter: Alternative Twitter front-end)

@nchauvat

A minimal viable product could be “fedeproxy is able to publish issues using ActivityPub and other tools of the fediverse can comment on these issues and fedeproxy will write the comments back to the forge”.

What do you think ?

In an earlier comment I kind of dismissed this idea saying it’s in scope and implying that it may not be something that needs to be implemented in a first iteration. I’m still unconvinced but I feel that I’m missing something. You see something that I don’t and that gives me pause.

During breakfast this morning I realized fedeproxy should be able to leverage the UI of Mastodon to (for instance) express: “GitHub - ceph/ceph: Ceph is a distributed object, block, and file storage platform” follows “https://mygitlab.com/myuser/ceph”. If, behind the scene, fedeproxy makes it so both are seen as ActivityPub conformant servers, maybe that would work. Or maybe it’s twisted. In any case, once a software project talks ActivityPub, there can be bots interpreting what it says in useful ways and humans using existing UIs to perform all ActivityPub conformant operations such as following without reinventing the wheel.

As you can see, it’s still very very fuzzy and confused but it’s making progress. I think