You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.
Start thinking/compiling a plan on how federated bridges would work and how it could be implemented.
The way i see this being implemented is that some of the Storj services will be offloaded to volunteers who run a package like a Bitcoin full node on a server, they then get a reward for running and maintaining this package. The main goal of this is to prevent the Storj network from crashing when the main Storj bridge goes down or even during bridge updates. These "min bridges" do not have to run all normal Storj bridge services, for instance i don't see a reason for these federated bridges to run a billing system, this should be handles by the main bridge. Setting up a federated bridge should be easy enough so that tech savvy people can start and maintain a bridge. The entire idea of this is to make sure Storj does not become a second AWS where if the main bridge goes down, so does the entire network.
The text was updated successfully, but these errors were encountered:
I am new to the project, but extremely fascinated by it. Please forgive my ignorance to the details of the implementation.
What if the bridge was part of being a farmer? Expose the rest apis on each farming node. Since it stores metadata, why not store that metadata on nodes (along side stored data), and allow all of that work to be truly distributed alongside the data it is coordinating.
Bridges ability to accurate account for payments that need to be sent to farmers automatically. At first this is helped with Add farmer storage events bridge#481 and then speed up the rate at which payments are made can be increased until it's instant (likely with Ethereum state channels or https://github.com/raiden-network/raiden).
Actually I would appreciate to run a dedicated bridge host on my HA cluster , only thing what has to be selfprooving is the requirements and rewards system of decentralized storj bridges .
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Start thinking/compiling a plan on how federated bridges would work and how it could be implemented.
The way i see this being implemented is that some of the Storj services will be offloaded to volunteers who run a package like a Bitcoin full node on a server, they then get a reward for running and maintaining this package. The main goal of this is to prevent the Storj network from crashing when the main Storj bridge goes down or even during bridge updates. These "min bridges" do not have to run all normal Storj bridge services, for instance i don't see a reason for these federated bridges to run a billing system, this should be handles by the main bridge. Setting up a federated bridge should be easy enough so that tech savvy people can start and maintain a bridge. The entire idea of this is to make sure Storj does not become a second AWS where if the main bridge goes down, so does the entire network.
The text was updated successfully, but these errors were encountered: