From f669d069f6cb887c1c4c069b1d72d8ec06b37b39 Mon Sep 17 00:00:00 2001 From: dat-adi Date: Wed, 19 Jan 2022 11:59:20 +0530 Subject: [PATCH 1/5] Updated the introduction page --- config.toml | 2 +- content/getting-started/intro.md | 36 +++++++++++++++++++++++++------- static/logo.svg | 2 +- 3 files changed, 30 insertions(+), 10 deletions(-) diff --git a/config.toml b/config.toml index 1f8b979..5462db4 100644 --- a/config.toml +++ b/config.toml @@ -8,6 +8,6 @@ highlight_code = true highlight_theme = "base16-ocean-light" [extra] -logo = "https://easydocs.codeandmedia.com/logo.svg" +logo = "https://github.com/forgeflux-org/docs/blob/main/static/logo.svg" release = "https://api.github.com/repos/getzola/zola/releases/latest" favicon = "https://www.getzola.org/favicon.ico" diff --git a/content/getting-started/intro.md b/content/getting-started/intro.md index 551b90f..f828156 100644 --- a/content/getting-started/intro.md +++ b/content/getting-started/intro.md @@ -4,18 +4,38 @@ weight = 40 +++ # How does it work? -Interfaces are services that are run on the side of any user, and are used as connecting points of the bridge. + +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 + +- 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 comes to play, by implementing a lookup server that seeks to provide an indexed list of available forge interfaces. +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. - diff --git a/static/logo.svg b/static/logo.svg index 5d7d965..e56524c 100644 --- a/static/logo.svg +++ b/static/logo.svg @@ -1 +1 @@ - \ No newline at end of file +FORGEFLUX \ No newline at end of file From dfe2267801b2078cdc96857a0d2703aa6be454ef Mon Sep 17 00:00:00 2001 From: dat-adi Date: Fri, 21 Jan 2022 14:20:26 +0530 Subject: [PATCH 2/5] 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. --- content/_index.md | 70 ++++++++++++++++++------------- content/getting-started/how.md | 72 ++++++++++++++++++++++++++++++++ content/getting-started/intro.md | 41 ------------------ 3 files changed, 112 insertions(+), 71 deletions(-) create mode 100644 content/getting-started/how.md delete mode 100644 content/getting-started/intro.md diff --git a/content/_index.md b/content/_index.md index 7a28903..50da33c 100644 --- a/content/_index.md +++ b/content/_index.md @@ -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. diff --git a/content/getting-started/how.md b/content/getting-started/how.md new file mode 100644 index 0000000..feecae8 --- /dev/null +++ b/content/getting-started/how.md @@ -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. diff --git a/content/getting-started/intro.md b/content/getting-started/intro.md deleted file mode 100644 index f828156..0000000 --- a/content/getting-started/intro.md +++ /dev/null @@ -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. From 747f51c2e356d611c3006b6d3e26f596c3472c55 Mon Sep 17 00:00:00 2001 From: dat-adi Date: Fri, 21 Jan 2022 17:19:44 +0530 Subject: [PATCH 3/5] Removed backslashes Condensed the content into paragraphs instead of sentences with a newline. --- content/_index.md | 32 ++++++++++++++++---------------- content/getting-started/how.md | 31 +++++++++++++++++-------------- 2 files changed, 33 insertions(+), 30 deletions(-) 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. From f82ddc5d3e459ec282b787b3929f38463a9dbbf0 Mon Sep 17 00:00:00 2001 From: dat-adi Date: Sat, 22 Jan 2022 11:11:58 +0530 Subject: [PATCH 4/5] Terse content Reworked the content to be a bit more polished. --- content/_index.md | 7 +--- content/getting-started/how.md | 76 ++++++++++------------------------ 2 files changed, 23 insertions(+), 60 deletions(-) diff --git a/content/_index.md b/content/_index.md index 8780eef..2ff3a7f 100644 --- a/content/_index.md +++ b/content/_index.md @@ -7,10 +7,8 @@ insert_anchor_links = "right" 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, and you hop on to the code-hosting platform, or forge, that you use on a daily basis to search for the library. - 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. @@ -19,7 +17,6 @@ At this point, in order to file a bug report, or even send a Pull Request that c 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. - Manually tracking notifications, setting up new remotes for the upstreams, configuring GPG and SSH keys, and having to set up a new development workflow. @@ -32,13 +29,11 @@ Worrying about the forge-specific operations that you'll need to perform are a t 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. - You check out and have more time for things that you wanted to work on for the rest of the day. @@ -49,7 +44,7 @@ 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. diff --git a/content/getting-started/how.md b/content/getting-started/how.md index 6c5077f..00acad4 100644 --- a/content/getting-started/how.md +++ b/content/getting-started/how.md @@ -7,69 +7,37 @@ weight = 40 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. +## Interface -[Interfaces](@/services/interface.md) are services that are run on the side of any user, -and are used as connecting points of the bridge. +The bridging component in ForgeFlux is called Interface. -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, +[Interfaces](@/services/interface.md) are programs that run on either +side of the bridge, i.e, a bridge requires the participation of two +interfaces. Currently, Interfaces bridge the following operations: - 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. +An Interface implementation for a software forge is able to +talk to the forge's API and speak [ActivityPub +protocol](https://activitypub.rocks/) for server-to-server +communications. This architecture makes it possible to implement an +Interface for any forge setup. -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. +## Northstar -Deviating from the method that ForgeFed follows, Git is used for changes in the Git -repository. +Since Interfaces run external to the forges, a method to find Interfaces +that service forges was required. -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. +[Northstar](@/services/northstar.md) is a discovery service that maps an +Interface and the forge that it services. It acts very similar to DNS, +except instead of querying host names with intent to find corresponding +IP address, Northstar is queried with the forge's host name to discover +the Interfaces that service it. -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. +## Resources -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. +- + [ecosystem-architecture](https://github.com/forgeflux-org/spec/blob/master/rfc/1-ecosystem-architecture/1-ecosystem-architecture.md): + describes basic architecture and terminology used in ForgeFlux From 8c233e5d4a6b53099ac1e8ce4f0eeb127d0b1f7b Mon Sep 17 00:00:00 2001 From: dat-adi Date: Sun, 23 Jan 2022 20:45:32 +0530 Subject: [PATCH 5/5] Updated config and SVG The logo now points to the root directory, and the SVG has been replaced after resolving the issue with the viewport. --- config.toml | 2 +- static/logo.svg | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/config.toml b/config.toml index 5462db4..24159d9 100644 --- a/config.toml +++ b/config.toml @@ -8,6 +8,6 @@ highlight_code = true highlight_theme = "base16-ocean-light" [extra] -logo = "https://github.com/forgeflux-org/docs/blob/main/static/logo.svg" +logo = "/logo.svg" release = "https://api.github.com/repos/getzola/zola/releases/latest" favicon = "https://www.getzola.org/favicon.ico" diff --git a/static/logo.svg b/static/logo.svg index e56524c..70bdf48 100644 --- a/static/logo.svg +++ b/static/logo.svg @@ -1 +1 @@ -FORGEFLUX \ No newline at end of file +