DNS-SD compatibility

[sammacbeth]

It seems that the usage of multicast-dns here differs from the DNS-SD standard. This means that libraries and applications implementing these standards will ignore these broadcasts. This is an issue for applications that want to interopt with hyperswarm, but must use a higher level API (like ServiceDiscovery, Bonjour etc). This was also mentioned in #7 as an issue for mobile support in react-native.

Would it be possible to tweak the mdns usage to follow this standard? For example using a module such as bonjour (which is just a thin layer on top of multicast-dns) would do this.

[mafintosh]

As long as it can be done with the same amount of roundtrips (i.e. 1) I'm 👍 if someone wants to try this out.

AFAIK it just involves adding the PTR record before sending the SRV which I think can be done in 1 roundtrip if you use the additional section of the record.

[sammacbeth]

I had a little look into this. Unfortunately, with only a superficial knowledge of MDNS I was not able to work out how to add DNS-SD compatibility directly via multicast-dns usage. However, this seems to be exactly what the bonjour library is doing, and it's API is fairly simple to consume.

Testing with bonjour, it would be possible to announce and lookup as follows:

// announce
bonjour.publish({ name: key.toString('hex') type: 'hyperswarm', port: 10000 })
// lookup
bonjour.find({ type: 'hyperswarm' }, callback);

As this is DNS-SD compatible, tools such as dns-sd can see these announces:

$ dns-sd -B _hyperswarm local
DATE: ---Mon 21 Oct 2019---
18:01:05.959  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
18:01:05.960  Add        3   9 local.               _hyperswarm._tcp.    18bf0e130d7bd2b0c395e170312cddcecae54a04

Would it be ok to add a dependency on bonjour to implement this, or is there an advantage to implementing directly on multicast-dns?