WebWormHole: Send files quickly using WebRTC

Conceptually it's the same design as Magic Wormhole though all the technologies are different.

It's just a PAKE then you do a file transfer encrypted with the key you agreed using the PAKE.

PAKEs are very human friendly, they leverage a relatively weak secret (like "Monopoly Vegetable") that humans can deal with, to agree a good quality secret (like an effectively random 128-bit AES key) in such a way that both parties find out if the other party doesn't know the weak secret.

Because humans are bored easily you can use rather weak secrets safely - it's a natural rate limit. An adversary who guesses almost right "Cluedo Animal?" only gets told they're wrong, and after maybe two or three more attempts the legitimate parties are annoyed and refuse to keep trying so their adversary is foiled.

Machines wouldn't naturally use something like this because if a machine has a secure channel to another machine it can just move the 128-bit AES key, not waste time with some weaker human-memorable secret.

This technology won't hide the IP addresses of those communicating

A passive on-path adversary learns the size (perhaps not exactly but at least close) of the file transferred.

And of course an active adversary can prevent the file transfer by spamming the service with nonsense.

I'm curious how this compares with the DAT project https://docs.dat.foundation/docs/intro I've had issues using that with networks throwing NAT errors, but need a secure P2P file solution for large data transfers. Wondering if this wil do the trick.

You're right that MPMC queue is a specific case of req/res where responder doesn't switch to a channel for replying so it does make sense to switch to it; nothing will be lost. You could even use the pubsub protocol by putting a query param (pubsub=true), instead of reserving a whole path prefix just for this protocol. I'd still keep pubsub because it's still useful in the general case, especially since your initial itch to scratch, poor man's notification, is done in pubsub mode

(Side question: why use pubsub for notification ? You wouldn't want to lose the notification if no one is listening on the consumer side... but you also want to possibly send it to multiple consumers at the same time. Maybe there's space for something a bit different, like "As a producer I want to block until at least one consumer is here; if there are multpile, send to all of them")

The only concern I'd have is that in the general case of req/res there's no "easy" cli tool to parse the request headers and a potentially streaming body, so it's harder to do a 1-liner (or a 5-liner) to process the input.

Thanks for the feedback

> You're right that MPMC queue is a specific case of req/res where responder doesn't switch to a channel for replying so it does make sense to switch to it; nothing will be lost

Not quite, unfortunately. The current implementation of req/res assumes the first path segment is the responder "id", and everything after that is the path to the file on that responder. So responders will shadow things and cause potentially unintuitive behavior for users who just want an MPMC. There may be ways to mitigate that though. I haven't though it through.

> You could even use the pubsub protocol by putting a query param (pubsub=true), instead of reserving a whole path prefix just for this protocol

That's actually exactly how it worked originally. Once I started adding more protocols, I switched to the /proto/ api since it makes it clear right at the beginning of the URL how it works, whereas query params are at the end of a potentially long path. Still not 100% sure about this though. Been thinking about switching to a pb-proto={res,queue,pubsub}.

> (Side question: why use pubsub for notification ? You wouldn't want to lose the notification if no one is listening on the consumer side... but you also want to possibly send it to multiple consumers at the same time.

In practice I actually haven't been using pubsub for notifications. MPMC is almost always what I need. Since the chat example is mostly a toy, I'm really not sure pubsub is earning it's complexity cost.

I suppose pubsub is still useful for streams of events (like webhooks) where it's not necessarily a disaster if the event gets dropped, but you definitely don't want the sender piling up blocked requests.

> Maybe there's space for something a bit different, like "As a producer I want to block until at least one consumer is here; if there are multpile, send to all of them")

That's an interesting idea. You'd still need a separate protocol for it, because you have to read the entire message into memory in order to send to multiple requesters, but it could be useful for sure.

> The only concern I'd have is that in the general case of req/res there's no "easy" cli tool to parse the request headers and a potentially streaming body, so it's harder to do a 1-liner (or a 5-liner) to process the input.

Yes, it pretty much requires a real script. I'm tempted to pull it out into a completely separate thing, but it turned out that MPMC is almost completely a subset of req/res, so it felt like a lot of duplication.

Thanks for taking the time to reply!

> I suppose pubsub is still useful for streams of events (like webhooks) where it's not necessarily a disaster if the event gets dropped, but you definitely don't want the sender piling up blocked requests.

Yeah, it seems to me the semantics here is not so much pubsub but rather "at-most-once". I think that kind of things makes sense for frequent updates where you mostly care about the most recent value, so things like pings from a temp sensor or stuff like that

> You'd still need a separate protocol for it, because you have to read the entire message into memory in order to send to multiple requesters

Actually, related to the previous point, that's an at-least-once thing: if there is 1 (or multiple) consumers, send to all of them; if there is none, wait for the first one, and once the first one is connected send to it. There wouldn't be a need for much serializing in memory

Regarding req/res: it kinda feels like there's some overlap with the world of CGI, it's basically the same issue; maybe it's possible to re-use or extract some of the existing libraries ?