ForgeFlux/docs
2
0
Fork 0
Code Issues 1 Pull requests 2 Projects Releases Packages Wiki Activity

Removed backslashes

Browse source 
Condensed the content into paragraphs instead of sentences with a
newline.
This commit is contained in:
dat-adi 2022-01-21 17:19:44 +05:30
parent dfe2267801
commit 747f51c2e3
2 changed files with 33 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
content/_index.md
View file

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

31
content/getting-started/how.md
View file

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