Understand how to properly utilize libp2p within feldmanchain(-on-prem)

[GGAlanSmithee]

From an inital look, libp2p seems like a reasonable candidate for a network layer of the on-prem (and global) version of feldmanchain. This issue exists as a reminder to conduct further investigation, and to list things of importance.

Notes

• seems like libp2p mdns collides with win 10 mdns under certain circumstances: reference
• seems like libp2p somehow defaults to settings compatible with ipfs: reference

[GGAlanSmithee]

Making a note for my future self here:

Since libp2p supports running peers on multiple protocols at once, maybe that can be used as a way to allow a peer to either hide from, or make itself visible to, public nets. This would effectively implement the on-prem / public usecase within the same application.

This does, however, open up for the possibility to unintentionally connect yourself to the public net, but this could be implemented in such a way that the user has to make a clear and active decision to do so.

[GGAlanSmithee]

See this for above remarks: #10 (comment)

[GGAlanSmithee]

The "change:protocols" event is built in to libp2p and something that peers listen to out of the box. This event gets triggered every time a discovered peer changes the protocols it listens to. This is effectively the way to perform protocol detection.

There is also the event "change:multiaddrs

[GGAlanSmithee]

As I understand it, there are two general ways of exchanging messages between peers; custom protocols or a pubsub system. I think they can serve more or less the same purpose, but I think protocols are more comprehensive and offer more granular control as to what peers to dial as well as makes it possible to establish secure and verifiable connections. I need to look into this further though.

[GGAlanSmithee]

We are now using pubusb as the primary way of communicating build requests (and in the future other topics). This seems like the way to go in the aspects of discoverability and performance.

[GGAlanSmithee]

Will continue to look into it though, to make sure it will work with the intended workflow.