This is excellent - a big fan of its scriptability via curl. I think you have the beginnings of a truly amazing developer experience here.
If you're interested in monetizing this:
I would pay a fee for this - say $4/month. The only features I would like at this price:
1. Authentication (-H "Authorization: Bearer <token>" would be good enough) - at the level of the routes. This sounds like what you have done for routes like '/' anyway.
2. A CLI to tell which routes I "own".
3. Persistence of messages on the patchbay server up to some reasonable time limit T so that consumers can replay messages since time T without the publishers being blocked on their side.
I would pay $8 per month if:
1. You hosted consumers (go binaries or docker containers which would accept the body and headers of the HTTP response on the consumer side and do something with it), ran them for me in a loop
2. Guaranteed me some level of isolation for things like API keys, etc. which would be passed to my consumers in some fashion.
Even if it were open source, at these prices, I would buy. Don't want the headache of hosting it myself.
Thanks for the detailed suggestions. A few questions:
1/2. Why not a private instance for $4/month, accessible only to authenticated requests (unless of course you choose to open up certain routes for GET and/or POST)? Not only does this mean you can use semantic URLs instead of random ones (which helps offset the annoyance of managing API tokens), but you also get a unique domain that you can do things like put behind CloudFlare or another CDN.
3. This is an interesting idea. However, by far the greatest strength of the current implementation is that it has 0 (well ok, very little) explicit state. What's your use case for the semi-persistent producers?
1. It's interesting that you request hosted consumers and not hosted producers (a la for hosting a website). But I see the appeal. It would be nice to be able to set up something like a text notification trigger and not have to worry about it being tied to your own physical machine.
I totally agree about the open source bit. I don't see open source as a threat to a business model here. With something so simple it's going to come down to execution and customer service. As a staunch supporter of self-hosting, after 1 or 2 services it simply becomes too much to manage, unless you enjoy it as a hobby. I just want to get work done without giving my digital self over to the big guys. Even paying others per service doesn't really work, because at 5USD/service (which I paid for a Mastodon instance for a while), it quickly becomes too much money. Part of the inspiration for patchbay was trying to make a dead-simple substrate on top of which I could implement many other things, hopefully saving me some self-hosting trouble.
I mostly see myself using this as part of CI workflows or to monitor jobs that I run overnight/over the weekend. I also see it as a good way to, for example, start jobs on remote machines by sending a text message.
1/2. I can still make semantic URLs against your service, just with some caveats that they have to be globally unique. I could also proxy over to your domain from mine. Authentication would mean that some random person couldn't just come and POST or GET to my routes so I'm happy. $5/month for a DigitalOcean droplet on which I have to manage the server vs $4/month of using patchbay.pub where all I have to do us GET and POST HTTP requests, the latter wins every time (even though I can run other things on the droplet).
3. Semi-persistence would be great for failures on the consumers or on systems running the consumers. E.g. if I had a Comcast outage, I could still apprise myself of messages published during the outage.
(This last point is also why I would love for you to host my consumers - it also makes it a lot easier for you to make the consumers more reliable.)
Good point about paying for a large number of services - that's why I really like Twilio's pay-as-you-go pricing model. Might be a good one to consider for patchbay, as well - a per message published or consumed cost?
Anyway, really nice job. I think I'm going to use this a bit.
If you want to monitor my usage, I will set an "x-hn-user: zomglings" header on my requests. :)
> greatest strength of the current implementation is that it has 0 (well ok, very little) explicit state
I don't think that's the greatest strength. I think the greatest strength is how easy it is to get started using it and hooking it to personal tools. Whether it has or doesn't have an internal explicit state is totally irrelevant (to me anyway).
for 1/2 you could offer the route /<username>/<channel> to the paying user to help the namespacing issues and keep the shared infrastructure angle. Then charge "enterprise" pricing for private instances
That would go a certain distance, but I'd have to do a lot of measuring to see how scalable it is. Part of the problem with the free instance is I have to aggressively rate/bandwidth limit, because it's running on a single DigitalOcean instance with what maybe 1-10Gbps tops? I'd love to be able to give paying customers much higher performance by spreading across multiple machines. Though if any sort of a viable business model comes out of this, I'll probably look to switch to physical hardware anyway.
> 1. You hosted consumers (go binaries or docker containers which would accept the body and headers of the HTTP response on the consumer side and do something with it), ran them for me in a loop
I toyed with this idea at http://dollardeploys.com/ but the feedback I got was "Heroku can do this for free".
If you're interested in monetizing this:
I would pay a fee for this - say $4/month. The only features I would like at this price:
1. Authentication (-H "Authorization: Bearer <token>" would be good enough) - at the level of the routes. This sounds like what you have done for routes like '/' anyway.
2. A CLI to tell which routes I "own".
3. Persistence of messages on the patchbay server up to some reasonable time limit T so that consumers can replay messages since time T without the publishers being blocked on their side.
I would pay $8 per month if:
1. You hosted consumers (go binaries or docker containers which would accept the body and headers of the HTTP response on the consumer side and do something with it), ran them for me in a loop
2. Guaranteed me some level of isolation for things like API keys, etc. which would be passed to my consumers in some fashion.
Even if it were open source, at these prices, I would buy. Don't want the headache of hosting it myself.