diff --git a/content/_index.md b/content/_index.md index 7a28903..50da33c 100644 --- a/content/_index.md +++ b/content/_index.md @@ -3,43 +3,53 @@ title = "Magic Bridges" insert_anchor_links = "right" +++ -# ForgeFlux +## A day of the past -[ForgeFlux](https://forgeflux.org/) aims to implement federation in [software forges](https://en.wikipedia.org/wiki/Forge_(software)) , enabling -a decentralized development environment. +It's a Friday evening, and you've sat down to work on some code. \ +Halfway through testing the code, you realise that there's a problem with a dependency.\ -## 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. +Something's not supposed to work the way it does. \ +You hop on to the code-hosting platform, or forge, that you use on a daily basis +and search for the library. -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. +Wait, it's not here? \ +You close your eyes, before reluctantly heading over to a search engine, +to find the repository being hosted on another forge that you haven't worked with. -ForgeFlux, is an idea, that intends to get rid this problem. -Work on your own forge, but **bridge** the project. +At this point, in order to file a bug report, or even send a Pull Request that could +fix the issue, you would be required to create an account on the forge and clone the +repository and relearn the workings of the particular forge before finally working +on the code. -Bridging a project would allow for a user to contribute towards projects that -exist in foreign forges, through the comfort of their own forge. +Manually tracking notifications, setting up new remotes for the upstreams, +configuring GPG and SSH keys, and having to set up a new development workflow. \ +The evening continues into the night, and you're finally ready with that PR, which +you had to learn a new forge for. -## Has this been done before? +## A day of the future -The initial [forgefed](https://forgefed.peers.community/) 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. +Worrying about the forge-specific operations that you'll need to perform are a thing of +the past now. \ +With the inclusion of a bridging feature in your code-hosting platform, you can finally +forget about how other forges behave and whether you'll need to work towards creating +a new account to contribute. -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. +A contribution, be it a Bug Report, Feature Request, or a Pull Request, now can be +solved through setting up a bridge to the repository you want to contribute to. -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](https://github.com/forgeflux-org/spec/blob/master/rfc/1-ecosystem-architecture/1-ecosystem-architecture.md), if there is any confusion regarding the usage of particular words in this documentation. +Days are pleasant and you can continue working on your code after you're done with the +issue of the library. \ +You check out and have more time for things that you wanted to work on for the rest of +the day. +## Enter ForgeFlux + +While the days of the past are what we live in currently, ForgeFlux is the intermediary +that seeks to get developers to the days of the future! + +Implementing bridging leveraging the API space, [Northstar](@/services/northstar.md) +points, and the [Interface](@/services/interface.md) sets it all up. + +Know more about how ForgeFlux works [here!](@/getting-started/how.md)\ +We're currently still in active development, and you can check what we've been +working on, in the `updates/` section. diff --git a/content/getting-started/how.md b/content/getting-started/how.md new file mode 100644 index 0000000..feecae8 --- /dev/null +++ b/content/getting-started/how.md @@ -0,0 +1,72 @@ ++++ +title = "How does it work?" +weight = 40 ++++ + +# How does it work? + +Bridges connect people, and so does ForgeFlux! + +Similar to how bridges are made, with two connecting endpoints for the start point +and the end point, ForgeFlux does the same with Interfaces. + +[Interfaces](@/services/interface.md) are services that are run on the side of any user, +and are used as connecting points of the bridge. \ +These interfaces are responsible for communicating with each other, and interact in the +form of messages for a server-server model, and a REST API model for the server-user +model. + +Interfaces are geared towards performing various operations for the repository, +which include but are not limited to, + +- Pull Requests +- Issues +- Comments +- Notifications +- Forking + +Recently, ForgeFlux has moved towards implementing the +[ActivityPub protocol](https://activitypub.rocks/) for interoperability with various +Social Networking implementations as well. \ +Implementing the ActivityPub protocol, we've currently established three Actors +in the environment, Repositories, Issues/Pull Requests, and Users. \ +This way, you can only subscribe to actors and if someone is interested in only a +single issue, they would only be required to interact with that particular Actor rather than +the entire repository. + +Deviating from the method that ForgeFed follows, Git is used for changes in the Git +repository. \ +While [ForgeFed Section 5.2](https://forgefed.peers.community/behavior.html#push-activity) +mandates a Push activity to be sent out to all followers whenever there's a `git push`, +it is not feasible for external implementations like ForgeFlux, +which leverage the Forge APIs, to perform this operation since we'll have to consider +the API rate limits. + +Here, we are deviating again from ForgeFed by making it optional. +So, federating forges/interfaces will have to periodically do a `git pull` to receive +changes made to the main repository. + +For operations such as Issues and Pull Requests, we utilize ActivityPub. \ +This is quite similar to [how Mastodon works](https://docs.joinmastodon.org/spec/activitypub/). + +However, as the count for interfaces go up in magnitudes, it becomes increasingly hard +to keep track of them. \ +This is where [Northstar](@/services/northstar.md) comes to play, by implementing a +lookup server that seeks to provide an indexed list of available forge interfaces. + +## Has this been done before? + +The initial [forgefed](https://forgefed.peers.community/) 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](https://github.com/forgeflux-org/spec/blob/master/rfc/1-ecosystem-architecture/1-ecosystem-architecture.md), +if there is any confusion regarding the usage of particular words in this documentation. diff --git a/content/getting-started/intro.md b/content/getting-started/intro.md deleted file mode 100644 index f828156..0000000 --- a/content/getting-started/intro.md +++ /dev/null @@ -1,41 +0,0 @@ -+++ -title = "How does it work?" -weight = 40 -+++ - -# How does it work? - -Bridges connect people, and so does ForgeFlux! - -Similar to how bridges are made, with two connecting endpoints for the start point and the end point, ForgeFlux does the same with Interfaces. - -[Interfaces](@/services/interface.md) are services that are run on the side of any user, and are used as connecting points of the bridge. -These interfaces are responsible for communicating with each other, and interact in the form of messages for a server-server model, and a REST API model for the server-user model. - -Interfaces are geared towards performing various operations for the repository, which include but are not limited to, - -- Pull Requests -- Issues -- Comments -- Notifications -- Forking - -Recently, ForgeFlux has moved towards implementing the [ActivityPub protocol](https://activitypub.rocks/) for interoperability with various Social Networking implementations as well. \ -Implementing the ActivityPub protocol, we've currently established three Actors in the environment, Repositories, Issues/Pull Requests, and Users. -This way, you can only subscribe to actors and if someone is interested in only a single issue, they would only be required to interact with that particular Actor rather than -the entire repository. - -Deviating from the method that ForgeFed follows, Git is used for changes in the Git repository. \ -While [ForgeFed Section 5.2](https://forgefed.peers.community/behavior.html#push-activity) mandates a Push activity to be sent out to all followers whenever there's a `git push`, -it is not feasible for external implementations like ForgeFlux, which leverage the Forge APIs, to perform this operation since we'll have to consider the API rate limits. - -Here, we are deviating again from ForgeFed by making it optional. -So, federating forges/interfaces will have to periodically do a `git pull` to receive changes. - -For operations such as Issues and Pull Requests, we utilize ActivityPub. -This is quite similar to [how Mastodon works](https://docs.joinmastodon.org/spec/activitypub/). - -However, as the count for interfaces go up in magnitudes, it becomes increasingly hard to keep track of them. -This is where [Northstar](@/services/northstar.md) comes to play, by implementing a lookup server that seeks to provide an indexed list of available forge interfaces. - -ForgeFlux is currently in the Active Development phase, and is being worked on towards the alpha-testing stage.