Feature: Add support for libp2p validation

[terichadbourne]

@jacobheun I heard you mention on a call today that the blocker for you to creating meaningful lessons on libp2p in ProtoSchool is that a libp2p node isn't created and you therefore can't do the validation you want to in exercises. I'm sure I'm phrasing that poorly, but I'd love it if you could say more about what would be needed to make the system work for you so that we could potentially add some functionality and turn your content into a ProtoSchool tutorial lesson after IPFS Camp. Thanks!

[jacobheun]

So, we have a few types of interactive lessons that we've put together. Thinking more through this I think we could workaround some of these things. I'll write this out so we can talk through potential options/improvements.

The first type of lessons, are basic configuration lessons like adding transports, discovery services, stream muxers, etc. These should be fairly straightforward to check in the result of validate. An example of this configuring TCP and Websockets might look like:

const run = async () => { /* globals TCP, Websockets */
  // Return libp2p configuration
  return {
    modules: {
      // Add transports here
    },
    config: {}
  }
}
return run

The second type, are directly calling libp2p methods. For example, adding a protocol handler. This would require us being able to check the libp2p instance they used to verify the correct things were added. We can technically get the libp2p instance from ipfs, ipfs.libp2p, but I worry that could just cause confusion. If we modify the libp2p instance, do we get that back in the verify code? If so, instead of checking the result (undefined) we could do some checking on the libp2p instance to make sure it had the protocol registered.

const run = async () => { /* globals ipfs, CustomProtocol */
  // Add the CustomProtocol to libp2p
  ipfs.libp2p.handle(CustomProtocol.protocolTag, CustomProtocol.handler)
}
return run

The third type involves communicating with other nodes. For protoschool, I think we'd need to be able to mock out some of the code. I don't think it makes sense to have actual dial or discovery code running, but mocking those methods would make it easy for us to verify they're doing the correct thing.

const run = async (peerInfo) => { /* globals libp2p, dialHandler */
  // If we could mock/stub `dial` we'd be able to validate it was called with the correct values 
  libp2p.dial(peerInfo, dialHandler)
}
return run

---

I think the main challenge with the libp2p lessons right now is that a significant part of the learning is in customizing libp2p itself, as that's the nature of how libp2p is designed (bring what you need). I think there are plenty of lessons we could build around using the libp2p apis (provided we could mock certain things to avoid actual network calls), but I think it's valuable they also start with configuring the specific portion of libp2p needed for that.

If we created a lesson where we could have a build progression, that would be helpful. While we wouldn't use the users results from the previously lesson, starting with the previous lessons solution code could be helpful.

A full example could be something such as working with pubsub. It could involve:

1. Configuring libp2p to use pubsub
2. Subscribing to topics (starts with the pubsub enabled node from previous step)
3. Publishing to topics

[terichadbourne]

@mikeal Since you built the internal workings of ProtoSchool originally and are more familiar with libp2p than I am, would you mind taking a look at @jacobheun's suggestions above? Does this proposal look feasible? Any technical challenges you expect we'd encounter?

[terichadbourne]

As part of our mid-quarter scoring, and in anticipation of a reduction in folks available, we're deprioritizing this to a P2 and don't expect to get to it this quarter unless any volunteers pop out of the woodwork.

[terichadbourne]

@codynhat I believe we chatted about this issue while at Offline Camp. It's something the core ProtoSchool team won't have time for this quarter but we're very open to having others start working on it if it's something that interests you. (I think there was one other person discussing this with us. Was it Tim S.?)