search

ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
15.98k stars 3k forks source link

Permanent p2p forwarding #5460

Open Stebalien opened 5 years ago

Stebalien commented 5 years ago

Now that we have the shiny refactored ipfs p2p command, it would be awesome if we could make forwards/listens permanent. That is, have a --save or a --sticky flag to save these mappings in either the config file or, possibly, the datastore (IMO, the config file actually makes the most sense here).

overbool commented 5 years ago

@Stebalien, I'm interested in this, could you explain it in more detail?

Stebalien commented 5 years ago

Basically, I'd like to be able to run:

And have ipfs save these mappings in my config file. IPFS would then automatically restore them on start.

overbool commented 5 years ago

@Stebalien I got it.

overbool commented 5 years ago

@Stebalien if save these mappings in the config file, can i save them as follow?

 "P2P": {
    "Listens": [
        {
            "Protocol": "/x/one",
            "Address": "/ip4/127.0.0.1/tcp/9898"
        },
                ...
    ],
    "Forwards": [
        {
            "Protocol": "/x/another",
            "Address": "/ip4/127.0.0.1/tcp/6565"
            "Peer": "/ipfs/Qm..."
        },
                ...
    ]
 }

WDYT?

Stebalien commented 5 years ago

SGTM. Thoughts @magik6k?

magik6k commented 5 years ago

Not sure about the names, can think of anything better though, so I'd call this good enough.

Stebalien commented 5 years ago

Well, we could just say Listen and Forward. We could also consider using maps. That is:

{
    "Listen": {
        "/x/one": "/ip4/127.0.0.1/tcp/1234",
    },
    "Forward": {
        "/ip4/127.0.0.1/tcp/4411": {
            "Peer": "QmId", // not sure if this should have the full multiaddr...
            "Protocol": "/x/another"
        }
    }
}

However, I really don't have any strong opinions here so I'd just say, go with whatever makes sense to you.

overbool commented 5 years ago

@Stebalien I make a pr in https://github.com/ipfs/go-ipfs-config/pull/8 about this issue, could you help me review it?

ghost commented 5 years ago

Not sure we should keep adding p2p things to go-ipfs when the libp2p daemon is already on its way.

Stebalien commented 5 years ago

The libp2p daemon is still a ways off and we're even further away from having go-ipfs use it. When it does, we can migrate over but I'd rather not block on that.

raulk commented 5 years ago

I don’t necessarily see this as libp2p daemon material. OTOH, it does feel well motivated to make the libp2p Host accept a configuration file. Perhaps some kind of JSON binding that maps to a subtree of the Config struct? https://github.com/libp2p/go-libp2p/blob/master/config/config.go

overbool commented 5 years ago

Not sure we should keep adding p2p things to go-ipfs when the libp2p daemon is already on its way.

@Stebalien Does this issue still need to be solved? It looks like libp2p daemon did the same thing.

Stebalien commented 5 years ago

At the moment, it's unclear what the libp2p daemon will handle (it doesn't currently do much of anything). IMO, the libp2p daemon should actually be extremely minimal and services like this one should be provided by external applications.

Eventually, we may migrate this functionality to a different component (maybe the libp2p daemon, maybe some daemon that uses the libp2p daemon). However, that shouldn't block this.

Stebalien commented 5 years ago

One thing that came up: https://github.com/ipfs/go-ipfs/issues/5523

IMO, we should refuse to persist "dynamic" addresses.

Winterhuman commented 2 years ago

@Stebalien Any update on this issue?

Stebalien commented 2 years ago

Unfortunately, no.