4 ms·

What makes this really interesting to me is that it uses a golang implementation of WebRTC on the server side. When I was playing with multiplayer networking in

What makes this really interesting to me is that it uses a golang implementation of WebRTC on the server side. When I was playing with multiplayer networking in the browser ~1.5yr ago, there really didn't seem to be a lot of options for WebRTC servers. Great to see some progress here. Also, it sounds like it's using streaming rather than loading the entire file, which would give it an advantage over https://file.pizza https://file.pizza, which is what I usually recommend for p2p transfers. If you like these types of tools, but don't require p2p (or can't use it because of NAT), I'll also plug my own https://patchbay.pub https://patchbay.pub, which will let you do streamed transfers with nothing but curl.

carlinmack 6y ago
thoughts on send.firefox.com?
- anderspitman 6y ago
  Seems like a solid option, and maybe better for recommending to people in general. Is it p2p? Nice thing about patchbay is pretty much all servers ship with a client (curl), so you don't have to worry about installing anything even for transferring large files. It's even lower friction than SSH/rsync with ssh agent because you don't have to type the destination path. Just run the receiver in the directory where you want the file to go. I used patchbay to transfer a 2GB earlier today. It looks like this: #sender curl https://patchbay.pub/anders/file.bin https://patchbay.pub/anders/file.bin --data-binary @file.bin #receiver curl https://patchbay.pub/anders/file.bin https://patchbay.pub/anders/file.bin > file.bin
rakoo 6y ago
I stumbled upon patchbay the other day and I thought it was really cool, now I just need to find a good excuse to toy with it. Just a heads up: the homepage still references the old index.html which you say in your blog article might have the wrong paths. Indeed looking at the docs all paths require a mode
- anderspitman 6y ago
  Do you have an example of where it's incorrect? I'm pretty sure it's the right index.html. Note that it's still very similar to the blog post.
  - rakoo 6y ago
    There is no mention of the req/res flow (someone could POST to /req, expecting it to be a MPMC queue) In the docs it seems MPMC queues should start with /queue, but it turns out that anything that's not /pubsub or /req,/res just works, so is it really needed ? Also the doc doesn't specify that pb-method is available to get the requester's method in the request/respond protocol Anyway those are just minor things, thanks for the service it really rocks
    - anderspitman 6y ago
      Thanks! Several good points. > In the docs it seems MPMC queues should start with /queue, but it turns out that anything that's not /pubsub or /req,/res just works, so is it really needed /req/res was developed after the initial launch, since I had the idea later. It represents the most general form of the entire concept, since you can tunnel essentially any HTTP traffic through it. The plan is to change the default protocol to /req, which is why I changed the examples to /queue, to make the transition smoother. Lately I've been going back and forth on whether it's a good idea to make the switch, since most of the time /queue is what I want, and using /req/res involves complexity that isn't really in the spirit of patchbay. But just today I decided another project I'm working on will need the full HTTP capabilities, so I think I'm going to pull the trigger on it in the next couple weeks. There are several independent implementations of the /queue-style approach, so I think it's ok for patchbay.pub to take a slightly more feature-full approach. Thoughts?
      - rakoo 6y ago
        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.

carlinmack 6y ago

thoughts on send.firefox.com?

anderspitman 6y ago
Seems like a solid option, and maybe better for recommending to people in general. Is it p2p? Nice thing about patchbay is pretty much all servers ship with a client (curl), so you don't have to worry about installing anything even for transferring large files. It's even lower friction than SSH/rsync with ssh agent because you don't have to type the destination path. Just run the receiver in the directory where you want the file to go. I used patchbay to transfer a 2GB earlier today. It looks like this: #sender curl https://patchbay.pub/anders/file.bin https://patchbay.pub/anders/file.bin --data-binary @file.bin #receiver curl https://patchbay.pub/anders/file.bin https://patchbay.pub/anders/file.bin > file.bin

rakoo 6y ago

I stumbled upon patchbay the other day and I thought it was really cool, now I just need to find a good excuse to toy with it. Just a heads up: the homepage still references the old index.html which you say in your blog article might have the wrong paths. Indeed looking at the docs all paths require a mode

anderspitman 6y ago
Do you have an example of where it's incorrect? I'm pretty sure it's the right index.html. Note that it's still very similar to the blog post.
- rakoo 6y ago
  There is no mention of the req/res flow (someone could POST to /req, expecting it to be a MPMC queue) In the docs it seems MPMC queues should start with /queue, but it turns out that anything that's not /pubsub or /req,/res just works, so is it really needed ? Also the doc doesn't specify that pb-method is available to get the requester's method in the request/respond protocol Anyway those are just minor things, thanks for the service it really rocks
  - anderspitman 6y ago
    Thanks! Several good points. > In the docs it seems MPMC queues should start with /queue, but it turns out that anything that's not /pubsub or /req,/res just works, so is it really needed /req/res was developed after the initial launch, since I had the idea later. It represents the most general form of the entire concept, since you can tunnel essentially any HTTP traffic through it. The plan is to change the default protocol to /req, which is why I changed the examples to /queue, to make the transition smoother. Lately I've been going back and forth on whether it's a good idea to make the switch, since most of the time /queue is what I want, and using /req/res involves complexity that isn't really in the spirit of patchbay. But just today I decided another project I'm working on will need the full HTTP capabilities, so I think I'm going to pull the trigger on it in the next couple weeks. There are several independent implementations of the /queue-style approach, so I think it's ok for patchbay.pub to take a slightly more feature-full approach. Thoughts?
    - rakoo 6y ago
      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.