Skip to content

use a different network than the default public ipfs network #3

Closed

Description

@liamsi

Summary

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.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned

Activity

  1. liamsi commented on Feb 1, 2021

    @liamsi
    MemberAuthor

    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

  2. liamsi commented on Mar 20, 2021

    @liamsi
    MemberAuthor

    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.

  3. liamsi commented on Aug 16, 2021

    @liamsi
    MemberAuthor

    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

  4. reopened this on Aug 16, 2021
  5. Wondertan commented on Aug 17, 2021

    @Wondertan
    Contributor

    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.
  6. Wondertan commented on Aug 17, 2021

    @Wondertan
    Contributor

    Wrong button 😅

  7. Wondertan commented on Nov 29, 2021

    @Wondertan
    Contributor

    @liamsi, I feel like this can be closed. WDYT?

  8. Wondertan commented on Nov 29, 2021

    @Wondertan
    Contributor

    Closing as we are using a completely different network.

  9. added a commit that references this issue on Dec 7, 2021
  10. added a commit that references this issue on Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions