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 }}
Repository navigation
use a different network than the default public ipfs network #3
Ideally, we want to connect only to nodes that run some lazyledger node, too.
Problem Definition
IPFS nodes connect to a large set of nodes by default. That's cool but we want our nodes to only connect to a set of nodes that 1) load the LL ipld plugin and 2) run some other portion of the lazyledger software (light client, (full) node, archival node etc).
Proposal
Provide an alternative set of bootstrap nodes. Ideally, we'd automatically deploy a node before each release and its address to the default config (this is good for testing purposes).
Add a way to only connect to a subnet. Using a private network (swarm key) could be the first very simple approach. Ideally, though we would modify to which nodes the ll-core nodes connect to by using some form of different network ID / protocol version (?) than the public ipfs network uses.
To summarize / capture some input we got on Discord from @Wondertan:
I don't think you need to have a separate network. Being part of IPFS network would help both networks to contribute each other in a win/win model by joing and expanding DHT network.
Even though most of the network won't understand your custom multihash codec, they still will be able to distritbute them over DHT and help all the participant to find content hosters, along with your nodes helping them.
Any node's peer.ID can still be close to some content's hash by XOR metric, what would allow the node to help others in finding that content, even without specifically supporting the mh codec. The support is required only when you want to download and read the content. Though, I need to double check that.
Also, there is a notion of bootstrap peers specifically for DHT: https://github.com/libp2p/go-libp2p-kad-dht/blob/master/dht_bootstrap.go#L13
If we want, we can still use the default bootsrap nodes and use them to find other peers that use a specific protocol. e.g. here is a simple example that implements a chat-app and uses the default bootstrap nodes to find other nodes to talk to: https://github.com/libp2p/go-libp2p-examples/tree/master/chat-with-mdns
Triaging this depends to some extend on the outcome of running more benchmarks: celestiaorg/ipld-plugin-experiments#10
If rerunning the experiments yields OKish results, we do not need to act upon this before mainnet.
Using the public IPFS network basically means sharing global DHT. This could be a case even without using a full-blown IPFS node.
The definition of done for the issue:
At least one "seed" node deployed serving bootstrap/network entry point needs
so we can hardcode it or define it in a hardcoded config.
We should also prepend/append custom protocol IDs to protocols we reuse from IPFS, e.g. Bitswap This is required for content not being shared between the networks, though there are no strong oppositions to that.
Activity
liamsi commentedon Feb 1, 2021
To summarize / capture some input we got on Discord from @Wondertan:
If we want, we can still use the default bootsrap nodes and use them to find other peers that use a specific protocol. e.g. here is a simple example that implements a chat-app and uses the default bootstrap nodes to find other nodes to talk to: https://github.com/libp2p/go-libp2p-examples/tree/master/chat-with-mdns
liamsi commentedon Mar 20, 2021
Triaging this depends to some extend on the outcome of running more benchmarks: celestiaorg/ipld-plugin-experiments#10
If rerunning the experiments yields OKish results, we do not need to act upon this before mainnet.
liamsi commentedon Aug 16, 2021
Transferred this from https://github.com/celestiaorg/celestia-core to https://github.com/celestiaorg/celestia-node
IMO, we should reconsider if we want to run a full-blown IPFS node in #1
Wondertan commentedon Aug 17, 2021
Using the public IPFS network basically means sharing global DHT. This could be a case even without using a full-blown IPFS node.
The definition of done for the issue:
Wondertan commentedon Aug 17, 2021
Wrong button 😅
Wondertan commentedon Nov 29, 2021
@liamsi, I feel like this can be closed. WDYT?
Wondertan commentedon Nov 29, 2021
Closing as we are using a completely different network.
docs/adr: ADR #3 March 2022 Testnet Design for Celestia Node (#244)
feat(core): add GetBlockInfo to Fetcher (#3)
services/header: Refactor `HeaderService` to be responsible for broad…
services/header: Refactor `HeaderService` to be responsible for broad…
bump dagstore #3