Updated the landing page

Set up a new landing page. The goal is to diss on forge-hopping, and
have people despair about the numerous operations that they have to make
when hopping.
This commit is contained in:
dat-adi 2022-01-21 14:20:26 +05:30
parent f669d069f6
commit dfe2267801
3 changed files with 112 additions and 71 deletions
content

View file

@ -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.

View file

@ -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.

View file

@ -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.