Fedeproxy dataflow

Development
#1

Bonjour,

Here is how the data will flow through fedeproxy. Whenever the user changes the DB via the web interface, the fedeproxy instance in charge of a given forge will retrieve the change via the REST API and transform it into an internal pivot format that will be stored in the DVCS provided by the forge (the fedeproxy instance itself is stateless, it has no presistent storage). It will then convert this pivot format into an ActivityPub type (commit) and publish the activity.

The fedeproxy instance in charge of the other forge receives the commit activity and uses it to git fetch the details directly from the DVCS of the other forge. It then converts the pivot format into REST API calls to change the DB of the forge, on behalf of the user of the other forge.

Cheers

Converted with asciigrid

image

               :-)
                |
                v
  +----------- web ---+
  | forge |     |     |
  |-------/   +----+  |
  |     +-----| UI |  |
  |     |     +--+-+  |
  |     |        |    |
  |  +--+---+  +-+--+ |
  |  | DVCS |  | DB |
  |  +--+---+  +----+ |
  |     |        |    |
  +--- git ---- REST--+
        |        |
        |        |
        |        |
        |        |              +--------------------------------------+
        |        |              |fedeproxy |                           |
        |        |              |---------/                            |
        |        |              |                                      |
        |        |              |  +-----------+       +-------------+ |
        |        \--------------+--| forge API |       | ActivityPub -<>---\
        |                       |  +-------^---+       +------^------+ |   |
        |                       |          |                  |        |   |
        |                       |  +-------^------+           |        |   |
        \+---------+------------+--| pivot format >-----------^        |   |
          \       /             |  +--------------+                    |   |
           \     /              |                                      |   |
            \   /               +--------------------------------------+   |
             \ /                                                           |
              \                                                            |
             / \                                                           |
            /   \               +--------------------------------------+   |
           /     \              |                                      |   |
          /       \             |  +--------------+                    |   |
        /+---------+------------+--| pivot format >-----------^        |   |
        |                       |  +-------^------+           |        |   |
        |                       |          |                  |        |   |
        |                       |  +-------^---+       +------^------+ |   |
        |        /--------------+--| forge API |       | ActivityPub -<>---/
        |        |              |  +-----------+       +-------------+ |
        |        |              |                                      |
        |        |              |---------\                            |
        |        |              |fedeproxy |                           |
        |        |              +--------------------------------------+
        |        |
  +--- git ---- REST--+
  |     |        |    |
  |  +--+---+  +----+ |
  |  | DVCS |  | DB |
  |  +--+---+  +-+--+ |
  |     |        |    |
  |     |     +--+-+  |
  |     +-----| UI |  |
  |-------\   +----+  |
  | forge |     |     |
  +----------- web ---+
                ^
                |
               :-)
2 Likes
NLnet webinar on linked data
#2
#3

I am not sure about the forge API term within the fedeproxy box ? Is the meaning “fedeproxy uses the REST API of the forge” ?

#4

Yes. The fedeproxy server uses the forge REST API to interact with it.

#5

A 6 minutes video explaining the fedeproxy dataflow is available here:

1 Like
#6

Is there more reading material on the scope of the functionality that FedeProxy will provide? In earlier topics the discussion was focused on Federated Issue Management, whereas here the scope is broader. It looks good to me, though, how this is set up.

In other discussion I got the impression that FedeProxy instance A knowing that Forge A is e.g. Gitea and Forge B is e.g. Gitlab would tailor the AP message exchange according to a Gitea2Gitlab proxy mapping (i.e. AP messages from A to B become Gitlab-specific), rather than having a more universal FP wire format (Gitea2FP on Forge A and Gitlab2FP on Forge B). This in contrast to what ForgeFed does, where ForgeFed format dictates the message protocol.

(Just mentioning this again, in case I misunderstood)

With a universal FedeProxy protocol it would be more feasible to have other services to also hook in onto this configuration, e.g. a Trello board that updates itself with selected content from a forge.

Update: See Multi forge web service with unique features for more info on this idea.

#7

Not really, because the scope of the forges functionalities is fuzzy. The general idea is that all features existing in a forge are in the scope of fedeproxy, as long as they are not natively federated. Once a given feature of a forge is federated with all other forges, fedeproxy becomes useless.

1 Like
#8

A post was merged into an existing topic: Vidéo presentation: Fedeproxy: Forge Federation with ActivityPub