40bce2aec3
I figured that this is going to be the main source of truth unlike an OpenAPI Specification, and as such is the only one that we should be following.
1.9 KiB
+++ title = "Magic Bridges" insert_anchor_links = "right" +++
ForgeFlux
ForgeFlux aims to implement federation in software forges , enabling a decentralized development environment.
Why is this significant?
There have been numerous forges that have popped up over the course of time. Each of these forges have their own community base, and projects that are associated to the forge itself.
However, issues arise when a user wishes to contribute towards a project that exists in another forge. This would require them to charter into unknown forge territory, to have to relearn the functionality that they're already at home with.
ForgeFlux, is an idea, that intends to get rid this problem. Work on your own forge, but bridge the project.
Bridging a project would allow for a user to contribute towards projects that exist in foreign forges, through the comfort of their own forge.
Has this been done before?
The initial forgefed was an attempt to bridge this gap, by introducing the concept of bridging the gap between forges. This approach required for the forge developers to actively participate in the development of the software.
The present ForgeFlux, focuses on the implementation being present in the API space instead. This reduces the interference required on the side of the forges themselves, and seeks to develop on existing utility and APIs provided.
ForgeFlux, consists of a terminology for the development and
utilization of it's software, which result in terms such as forges,
and interfaces being tossed around.
It is recommended for a reader to go through the ecosystem-architecture, if there is any confusion regarding the usage of particular words in this documentation.