Prep work to pass config down to broadcast for ipv6 #525
Conversation
|
Hey @jedahan, sorry this hasn't been reviewed yet. Could you give some further context on what this change is and why it's beneficial? It looks like it now takes a new environment variable, |
|
Is this something that's important to get merged? It looks like there are some merge conflicts and I haven't seen an update in a while. Looking forward to updates! |
| process.env.ssb_appname, | ||
| Object.assign( | ||
| minimist(conf), | ||
| { host: process.env.ssb_host } |
There was a problem hiding this comment.
don't put a hack like this here... this should already work in ssb-config. are you sure it's needed?
There was a problem hiding this comment.
It may no longer be needed, at the time I think this was a side-effect of how ssb_host was being read / overwritten.
| @@ -34,7 +34,7 @@ module.exports = { | |||
| } | |||
| } | |||
|
|
|||
| var local = broadcast(config.port) | |||
| var local = broadcast(config.port, config.loopback, config.family) | |||
There was a problem hiding this comment.
oh https://github.com/dominictarr/broadcast-stream/blob/master/index.js#L6 loopback makes the broadcast detectable on the same computer (needed for testing)
Was there a problem with this on ipv6? to OP mentions ipv6 but doesn't state it clearly.
There was a problem hiding this comment.
So it will be a little bit of time before I can get a testing setup up and running again. The motivation for this PR was to allow for nodes who are on the same physical network, but only have link-local (self-assigned) IPV6 addresses, to discover each other using another plugin I had written, using ipv6 multicast (similar to ipv4 broadcast).
I need to look into it again, but I think I had to enable loopback to not filter messages from other hosts, not just self-broadcasts.
I opted to pass in the family so the code I was submitting didn't disrupt the normal code path, though it may be better for both to behave the same was, as seen below.
There was a problem hiding this comment.
you should have said something like this in the original post! I think the main reason this PR has languished is because it wasn't clear what you where trying to accomplish, so it wasn't clear how important this was, and so we soon got distracted by other things.
The biggest problem with this code is that it's really hard to test. To really cover all the sorts of network configurations we'd need a much more complicated testing set up than we have currently, like spinning up virtual networks running in VMs. This stuff is currently mainly QA'd by people with unusual network set ups complaining that it's not working.
can you give more context about how/why you are using ipv6? is ipv6 mission critical for you or nice to have?
There was a problem hiding this comment.
The goal is to be able to allow nodes to join a network without relying on a dhcp server. The 'easiest' way I've found for this is with self-assigned ipv6 addresses, since they won't really collide. I am open to figuring out other ways, but my knowledge is limited.
This is for mainly for two projects:
- https://baculus.co - an experiment in disaster response infrastructure
- An art project with a friend related to 'the distributed web of care' where we have participants connecting ad-hoc, though I think I can work around this by only having one node in the room act as a dhcp server.
There was a problem hiding this comment.
right, because dhcd is completely different on ipv6 because you can just choose your own ip address. I've also managed to figure out that the reason it takes so long to connect to a wifi is because DHCP spec mandates multisecond delays
I'm definitely keen to support ssb on adhoc networks! another idea we've kicked around it a public open wifi, that lets you download and install an ssb client on the captive portal page
There was a problem hiding this comment.
Hmm I wonder if I should setup a video demo of baculus, it totally can do this. Right now it just serves up mvd since that requires zero installation from an end-user, but I should also expose Manyverse if it detects and android phone.
There was a problem hiding this comment.
what is MVD? video demo is always good!
There was a problem hiding this comment.
https://github.com/evbogue/mvd - its a web client for scuttlebutt, that hosts identity keypairs in the browser. I'll make a video this week :)
There was a problem hiding this comment.
oh right now I remember
| @@ -54,6 +54,7 @@ module.exports = { | |||
| var data = buf.toString() | |||
| var peer = ref.parseAddress(data) | |||
| if (peer && peer.key !== sbot.id) { | |||
| if (config.family === 'IPv6') peer.host = buf.address | |||
There was a problem hiding this comment.
This is the crux of things - if a node is saying 'I am a node' it feels weird to me to use the contents of their message as the IP - why not use the address the packet came from? (From what I understand, its so my node can forward publicly routeable advertisements, which makes sense). With ipv6 link local, addresses are unique to the interface, so you cannot share another nodes address and it be able to connect.
There was a problem hiding this comment.
I also don’t get it..
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
|
@jedahan I recently worked on fixing multiserver to support link-local IPv6 addresses: ssbc/multiserver#52 Would that be sufficient to support the use cases you want, or does this PR still stand as necessary? |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
|
@staltz I think that is enough. I will test it now. Is there a ssb dev setup guide somewhere? It would be nice to see a checklist, something along the lines of:
|
|
FWIW, I'm not familiar with a guide like that. However, you may be interested in: https://github.com/ssbc/ssb-integration-tests |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
Mostly just passing config along, broadcast does the hard work :)