feat: mdns & dht discovery

[sethvincent]

This pr implements a wrapper module around mdns-sd-discovery and hyperswarm to provide peer discovery through mdns and dht with one api.

[gmaclennan]

Thanks Seth, I did a fairly quick read through and left some comments. I think we need to be careful about race conditions considering that because this is user-event driven this can start and stop at unknown intervals. Also need to clean up events, and maybe parallelize promises for start and stop since both hyperswarm and mdns can take a while and would be better if they initialize / stop at the same time rather than sequentially.

[gmaclennan]

Great work on this. I'd love to hop on a call so you can talk me through some of this - there are parts that I don't quite understand. My questions (likely due to not fully understanding the code):

• Are we broadcasting a new mdns service for each topic? All on the same port? And a single connection for all topics? I wasn't clear what is happening with the peer disconnects and leaving some topics (but not all topics).
• Where are we deduping mdns connections (e.g. there will be an incoming and outgoing connection - Hyperswarm seems to do that here: https://github.com/hyperswarm/hyperswarm/blob/master/index.js#L224-L235
• Race conditions in async methods like join and leave can be common (based on prior experience with the app) due to users being able to switch rapidly between screens and in and out of the app (which causes join and leave actions). I haven't thoroughly reviewed the tests, but I want to make sure we correctly handle the "joining", "leaving", "destroying" states etc. if they do exist - think about the whole thing in terms of a state machine and what possible states exist and what might happen when methods are called in some of these "intermediary" states that happen during an async function.

[gmaclennan]

It would be good to think about the boundaries in mapeo-core between the different modules - thinking as if we would publish as a separate module. My understanding is that the "public" interface (i.e. the interface used by the rest of mapeo core) for discovery is the ./lib/discovery module, and the ./lib/localpeers is an implementation detail. If we clearly define that then we can clearly define the internal API the other pieces will use - the Discovery class - and it would be good to have that API thoroughly tested, so that we have the flexibility to change the implementation details of that module and have good separation between components of Mapeo Core. I think you've written it like this, it's just not currently that clear from how the code is organized and presented. Also good to have function methods and params documented since it really helps with future maintenance (and for code reviews).

[gmaclennan]

Great work on this. I don't quite understand how topics work for incoming connections on mdns, could we schedule some time so that you can talk me through this?

[sethvincent]

@gmaclennan I think this is ready now unless there's anything else we should get in to this pr.

I made a few issues that seem best handled in follow-up prs:

• better handle the tcp server and hyperswarm state to allow suspending and resuming #13
• track which peers initiate the connection #12
• add types for dependencies #14