Permanent p2p forwarding

[Stebalien]

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]

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

[Stebalien]

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

• ipfs p2p listen --save /x/ssh /ip4/127.0.0.1/tcp/22
• ipfs p2p forward --save /x/ssh /ip4/127.0.0.1/tcp/1234 /ipfs/Qm....

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

[overbool]

@Stebalien I got it.

[overbool]

@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]

SGTM. Thoughts @magik6k?

[magik6k]

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

[Stebalien]

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]

@Stebalien I make a pr in ipfs/go-ipfs-config#8 about this issue, could you help me review it?

[ghost]

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

[Stebalien]

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]

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]

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]

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]

One thing that came up: #5523

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

[Winterhuman]

@Stebalien Any update on this issue?

[Stebalien]

Unfortunately, no.