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"
|
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
|
It's a Friday evening, and you've sat down to work on some code. \
|
||||||
a decentralized development environment.
|
Halfway through testing the code, you realise that there's a problem with a dependency.\
|
||||||
|
|
||||||
## Why is this significant?
|
Something's not supposed to work the way it does. \
|
||||||
There have been numerous forges that have popped
|
You hop on to the code-hosting platform, or forge, that you use on a daily basis
|
||||||
up over the course of time.
|
and search for the library.
|
||||||
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
|
Wait, it's not here? \
|
||||||
a project that exists in another forge.
|
You close your eyes, before reluctantly heading over to a search engine,
|
||||||
This would require them to charter into unknown forge territory,
|
to find the repository being hosted on another forge that you haven't worked with.
|
||||||
to have to relearn the functionality that they're already at home with.
|
|
||||||
|
|
||||||
ForgeFlux, is an idea, that intends to get rid this problem.
|
At this point, in order to file a bug report, or even send a Pull Request that could
|
||||||
Work on your own forge, but **bridge** the project.
|
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
|
Manually tracking notifications, setting up new remotes for the upstreams,
|
||||||
exist in foreign forges, through the comfort of their own forge.
|
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
|
Worrying about the forge-specific operations that you'll need to perform are a thing of
|
||||||
an attempt to bridge this gap, by introducing the concept
|
the past now. \
|
||||||
of bridging the gap between forges.
|
With the inclusion of a bridging feature in your code-hosting platform, you can finally
|
||||||
This approach required for the forge developers to actively
|
forget about how other forges behave and whether you'll need to work towards creating
|
||||||
participate in the development of the software.
|
a new account to contribute.
|
||||||
|
|
||||||
The present ForgeFlux, focuses on the implementation being present
|
A contribution, be it a Bug Report, Feature Request, or a Pull Request, now can be
|
||||||
in the API space instead.
|
solved through setting up a bridge to the repository you want to contribute to.
|
||||||
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
|
Days are pleasant and you can continue working on your code after you're done with the
|
||||||
utilization of it's software, which result in terms such as `forges`,
|
issue of the library. \
|
||||||
and `interfaces` being tossed around.
|
You check out and have more time for things that you wanted to work on for the rest of
|
||||||
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.
|
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