Difference between revisions of "Channels/Decentralized"
(→Seed Nodes) |
|||
Line 10: | Line 10: | ||
The DHT (Distrubted Hash Table) design is designed for a very large number of nodes and channels. It should be very hard to disrupt. | The DHT (Distrubted Hash Table) design is designed for a very large number of nodes and channels. It should be very hard to disrupt. | ||
− | There is no centralized system for channel registration, user control or anything else. There is a mechanism to register names on the Snowblossom block chain, but that | + | There is no centralized system for channel registration, user control or anything else. There is a mechanism to register names on the Snowblossom block chain, but that is decentralized itself. |
==Limitations== | ==Limitations== |
Latest revision as of 21:38, 3 January 2020
Lots of projects claim to be decentralized. It is important to disclose exactly where this project is and what the remaining limitations are.
Towards that end, we will note some points about this project and answer what can be done about them and what the limiting factors are.
The objective is to have this project completely decentralized, where no one entity could take down the network.
Contents
Awesomesauce
The DHT (Distrubted Hash Table) design is designed for a very large number of nodes and channels. It should be very hard to disrupt.
There is no centralized system for channel registration, user control or anything else. There is a mechanism to register names on the Snowblossom block chain, but that is decentralized itself.
Limitations
Seed Nodes
Currently most of the seed nodes used for the DHT are run by Fireduck. We should add some diversity. If all the seed nodes were unreachable or down new nodes would be unable to join the DHT and wouldn't be able to find peers for channels. The seed nodes are the ones nodes initially contact to learn about other nodes on the DHT network. After being in contact with the network for a while, a node learns about other peers and doesn't need the seeds any more.
With this issue now closed, the multicast discovery on local network will work: https://github.com/snowblossomcoin/channels/issues/15
So that a new node will be able to join the network as long as it starts at least once on a local network that has a running node that has DHT peer data.
Fixes:
- Add more seeds - https://github.com/snowblossomcoin/channels/issues/18
- Allow older peers from DB - https://github.com/snowblossomcoin/channels/issues/21
IP Address Discovery
Currently, nodes reach out to an app in Google App Engine in order to discover their own IPv4 and IPv6 public addresses. See: https://github.com/snowblossomcoin/channels/blob/master/src/NetworkExaminer.java
If this broke, nodes would be unable to announce themselves as peers on the network.
Fixes:
- Improve address detection: https://github.com/snowblossomcoin/channels/issues/16
snowchannel.io hosting
The proxy implementatation points x.snowblossom.io to a channel where x is the channel identifier. To help with that. *.snowblossom.io is a publicly reachable site that tells people to fix their proxy settings. It is hosted on CloudFront/S3.
If this went away, people would get timeouts or other errors when their proxy settings were not set correct. Not a huge deal.
Source Control
Source control is all on github. Anyone could have a clone, but it is still a single point that would have a big impact on the system if disrupted.