Open dangowrt opened 9 years ago
https://github.com/mwarning/kadnode/ could be used to do (almost) all of that on top of fc00::/8
Instead of requesting peering with some to-be-invented protocol one could also simply generate a temporarily accepted password and publish that on the DHT. However, that would also require to expose my address eg. on ARPA internet to be stored in the DHT and accessible for everyone on the same cjdns network (and not only to those who ask...)
one might think you could run https://github.com/kpcyrd/nightfall listening on the fc00::/8, but that won't work...
I was thinking about how to improve assimilation of existing non-cjdns networks. What I mean by that is to keep the number of non-cjdns-hops between two users of the same cjdns network (e.g. hypeboria) as low as possible, given that this is a desirable for some hosts under some circumstances.
Imagine a DHT service which could run on top of fc00::/8 where people may publish their wish for peering over non-cjdns networks. If there was such a thing, I'd publish a public key and some information (e.g. 'ARPA-INET6', AS#, address prefix) of some-but-not-all of my hosts there. It should be queryable in a way that allows clients to find potential cjdns peers close to their own network location on a specific non-cjdns-(inter)network, ideally inside the same AS (i.e. define hash-buckets well, file peering-info-tuple for AS# and various descending IP-prefix-lengths) An other way to know about potential peers around me may be scanning for cjdns beacons on radio interfaces -- currently sending beacons implies that peering is possible for anyone capable of receiving the beacon without authentication. However, imagine a new type of beasons could be introduced to merely announce the presence of a cjdns node, but still require authentication to actually peer with that node (that may sound awkward, but keep on reading, you'll understand...)
Now imagine a protocol allowing others to request temporary peering credentials over cjdns. They are already connected to me over a cjdns network, but routing may take unnecessary detours which could be avoided. Thus they queried the DHT or scanned for beacons on a radio interface in order to find more peers close to them and found me. They request peering credentials and given that attitude and resources allow, they'll receive an IP-address, port, peering password and lease-time. People with dynamic ARPA-IP-addresses (e.g. cable or DSL users) would typically offer lower lease-times and limit the number of opportunistic peers to something rather low. Boxes in data-centres having static addresses would typically offer longer lease-times to avoid unnessesary noise when allowing a quite high number of opportunistic peers.
I'm totally aware that this may or may not be desirable, thus it should be configurable, similar to how beaconing is configurable on Ethernet interfaces:
0 : no opportunistic peering 1 : query DHT for peers, but do not publish peering info 2 : publish peering info and query DHT for peers
This could be an independent services running on top of fc00::/8 and using cjdroute's admin interface to add and remove peering credentials. I'm not sure whether it should be independent only because it could be...