diff --git a/content/_index.md b/content/_index.md index 50da33c..8780eef 100644 --- a/content/_index.md +++ b/content/_index.md @@ -5,16 +5,15 @@ insert_anchor_links = "right" ## A day of the past -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.\ +It's a Friday evening, and you've sat down to work on some code and halfway through +testing the code, you realise that there's a problem with a dependency. -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. +Something's not supposed to work the way it does, and you hop on to the code-hosting +platform, or forge, that you use on a daily basis to search for the library. -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. +Realizing that the project is not quite hosted on your forge, you close your eyes, +before reluctantly heading over to a search engine, to find the project repository +being hosted on another forge that you haven't worked with. 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 @@ -22,23 +21,24 @@ repository and relearn the workings of the particular forge before finally worki on the code. 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 +configuring GPG and SSH keys, and having to set up a new development workflow. + +The evening prolongs into the night, and you're finally ready with that PR, which you had to learn a new forge for. ## A day of the future 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 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. 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. Days are pleasant and you can continue working on your code after you're done with the -issue of the library. \ +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. @@ -50,6 +50,6 @@ 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)\ +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 index feecae8..6c5077f 100644 --- a/content/getting-started/how.md +++ b/content/getting-started/how.md @@ -11,7 +11,8 @@ Similar to how bridges are made, with two connecting endpoints for the start poi 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. \ +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. @@ -27,46 +28,48 @@ which include but are not limited to, Recently, ForgeFlux has moved towards implementing the [ActivityPub protocol](https://activitypub.rocks/) for interoperability with various -Social Networking implementations as well. \ +Social Networking implementations as well. + Implementing the ActivityPub protocol, we've currently established three Actors -in the environment, Repositories, Issues/Pull Requests, and Users. \ +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. +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. \ +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. +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. \ +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. \ +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 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. \ +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. \ +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.