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
parent
f669d069f6
commit
dfe2267801
3 changed files with 112 additions and 71 deletions
|
|
@ -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.
|
||||
|
|
|
|||
72
content/getting-started/how.md
Normal file
72
content/getting-started/how.md
Normal 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.
|
||||
|
|
@ -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.
|
||||
Loading…
Reference in a new issue