granular network control
opened this issue · comments
I've mentioned this on cabal a bit already, but it would be great if the cabal clients had more granular control over their connections. In some situations you might want to turn off all connections to save battery or bandwidth. In others you might only want local MDNS but not the public internet. In others you might not want to broadcast over MDNS for privacy. Making these settings configurable at runtime and showing a prompt when first running about the considerations around each type of connection would be very helpful.
Sorry to hijack this a little, but do you have any ideas about what the API for something like that should look like?
With regards to the SDK for example.
So far I was thinking something like this:
coreOrArchive.setNetworking('none' || 'local' || 'global')There should be modes for setting each networking subsystem independently, so I would add 'all' to that list (for local (mdns) + global (internet)). There are privacy/consent reasons why you might not want to broadcast mdns but would want to connect to a DHT or signalhub tracker. It might be good to enumerate those modes more explicitly too. Something like:
archive.setNetworking(['mdns','dht']) // options: mdns, tracker, dht. use [] for none.
I think it's better to be explicit about the tech because there could be other local options like bluetooth and other global options (different DHTs, trackers, servers) in the future.
In speaking to the Toronto Mesh folx, they also expressed a desire to specify a list of IPs to peer with.
Another consideration are what bootstrap servers you want to use: right now we use the dat-swarm-defaults module to pick some.
The full data structure for controlling networking might look like this:
{
mdns: true,
dht: {
enabled: true,
bootstrap: [ 'bootstrap1.datprotocol.com:6881' ] // DHT bootstrap servers
},
peers: [ 'eight45.net', '12.21.123.0' ], // direct-connect hostnames/IPs
servers: [ 'discovery1.datprotocol.com', 'discovery.eight45.net' ] // DNS discovery servers
}
great idea
servers -> dns though, it seems a bit more specific?
One thing I'd like to add to the peers thing is that you might need to specify which key the peers are for.
E.g.
{
peers: {
"cabal key 1 here": [ ... etc],
"cabal key 2 here": [ ... etc],
}
}@Karissa agh I dislike the term "dns" for this case because you could also use an IP for this part: it's not dependent on DNS. It's, like, "public-IP-server-assisted discovery".
@RangerMauve this could actually be true for ALL of the discovery mechanisms! Maybe there's a public cabal you want to use i2p for, and others you don't, or maybe some you feel OK with using mdns for, and others you don't want to broadcast your membership to the whole network. This feels like a thing that could range from super simple configurations ("all networking please!") to highly specific.
@noffle The servers are still using DNS as the communication method though, are they not? Maybe dns_servers would be a more descriptive title than either separately.
Regarding different channels, what about something like this:
{
default: {
dht: {
enabled: true,
bootstrap: [ 'bootstrap1.datprotocol.com:6881' ] // DHT bootstrap servers
},
},
"some cabal key": {
mdns: true
},
"some other cabal key": {
mdns: false
}
}@DeltaF1 Oops, looks like I misunderstood how this works. Please disregard what I said -- dns does make more sense as a key. ^___^
Didn't have time to look at this today, but I've got the tab open to look into more tomorrow. 💜 I'll also try to bring it up at the consortium meeting.
Totally forgot to bring it up at the consortium, but I think today was still a "how are we organizing" sort of day rather than a "what technical stuff are we focusing on". :P
definitely the right choice @RangerMauve