cabal-cli

cabal-cli copied to clipboard

Some toronto mesh folks (https://github.com/tomeshnet/prototype-cjdns-pi/issues/213) would appreciate this, since it would let them bypass dht and lan routing (since they're usng cjdns) and just connect to known peers directly.

This could be stored in a ${CONFIG}/cabal/config json file, or similar. cabal-client would also be a good place for this.

Thanks! I'd like to add that a way to list currently connected peers, and to drop connections would also be nice. A dynamic way to do all these things would be better then something in a config, as available peers can change often, and it'd be nice to look at who can be peered with at boot and every so often, and then be able to add them without restarting cabal, if that's possible.

Also, what would happen when you connect with peers who don't share any cabals with you? Cause with the bittorrent DHT you can dynamically request peers for each cabal but with this manual method, it might be nice to keep the peers to manually add in case they have messages to exchange later, even if they don't now.

@makeworld yes we'd need to find a way for both sides to signal what cabals they are a part of (and prove membership; maybe a msg encrypted with the cabal shared key?).

Thinking about this again, this is probably too hacky and difficult to be a long term solution. And so I think manual connections can be useful for testing, but we need a dht in the long term. Proving that they have access to the cabal is good, but not a top priority. All the stuff I was saying about keeping peers and stuff doesn't make sense if it's just for testing either. What I said in my first message is probably best: a way to add peers even when the client is already running, by ip address. And then a way to drop them and list the ones who are connected, again preferably as a command separate from the client. Is that ok? Sorry for doubling back on you there.

@makeworld sounds good!

Any development on this so far? Don't mean to be annoying, I know it's not a priority. Thanks! @noffle

just want to say we're still thinking about this, and it just came up in a discussion! no implementation in sight yet tho, but https://github.com/hyperswarm/dht/issues/4 shows others are thinking about features related to this as well :)