UTP required?

[sammacbeth]

Is the utp transport mandatory for this library to work? Unlike discovery-swarm this module does not gracefully handle an error when importing utp-native. This is an issue for platforms where we cannot use the native bindings that the native utp implementation needs.

If utp is required, is there a javascript implementation of the protocol that could be used on top of UDP sockets which I could substitute for the native implementation?

[mafintosh]

It’s required for any kind of hole punching to work but we could make it optional.

What’s your usecase?

[sammacbeth]

I'm testing dropping this module into firefox, using libdweb for TCP and UDP sockets. The utp-native module cannot be used in this context (as it is Gecko not node), so the alternatives would be:

1. Put utp into firefox, and expose it to javascript in the same way UDP and TCP sockets are exposed.
2. Polyfill the native utp with a javascript implementation using UDP sockets. From what I read about utp is runs on top of UDP so I assume this is possible.
3. Polyfill a noop utp implementation, but then we have no hole punching.

Option 1 would probably be impossible, as we'd have to convince Mozilla to take the patch. 3 is not ideal, as then firefox peers would be less connectable. 2 seems viable, but I'm not sure how complex it would be to implement.

[mafintosh]

We have a wasm version actually called utp-wasm we could fall back to. It’s feature complete but much slower than the native one

[sammacbeth]

Seems like utp-wasm could be a good replacement, though I doesn't seem to be working with libdweb at the moment. Do you know a good debug/test setup for utp?

[sammacbeth]

The issue with utp-wasm was caused by the emscripten packaging not working properly with my build stack. This PR fixes the issues there, allowing it to be used as a drop-in replacement for utp-native: mafintosh/utp-wasm#4