Author here. I implemented[0] a stripped-down server that includes the MPMC functionality. Should be a good starting point for alternative implementations. It really shows how simple the concept is under the hood. All it really does is translate HTTP requests into golang channels.
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
> 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".
Noticed someone working on a rather interesting exploit in the logs:
POST /.well-known/acme-challenge/huhn2?mime=text%2Fplain
Plugged that one. If anyone thinks of similar holes I should consider, please shoot me an email at info@patchbay.pub. There are a whole new set of security issues that crop up with this sort of system. Definitely be aware of that before using it!
I would love to make the source available. But there's no getting that genie back in the bottle once you go that route. I wanted to release it and get some feedback before deciding what to do with it. That said, a server that supports the examples on this page is pretty trivial to implement (especially if you skip the pubsub stuff). I had a working prototype in a weekend. Multiple implementations would probably be a good thing.
EDIT: also, the current state of the code base is not something I'd be excited about having my name attached to ;)
You can think about releasing the code with no license or with some form of the newer BSL or something.
It won't stop bad actors from stealing your code and using it but you will stop most corporate actors from touching it (and they are the ones you'd want to pay in the future anyway).
I made a similar project when starting to learn Go. It's opensource and it works. Just don't host it out on the internet. Intranet should be good because no security audit has happened. This was sort of an MVP
Secure Scuttlebutt is a P2P pubsub system for sending files, messages (chat/notifications), and everything else you can implement with pubsub-like systems.
I think it's just confusing because of the overlap with:
I made a similar open source self hosted tool for sharing logs or analysis from several machines, hosting internal versioned documentation, counters and time-series graphs etc.,
Readit News
[0] https://github.com/patchbay-pub/patchbay-simple-server
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.
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.
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. :)
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).
I toyed with this idea at http://dollardeploys.com/ but the feedback I got was "Heroku can do this for free".
POST /.well-known/acme-challenge/huhn2?mime=text%2Fplain
Plugged that one. If anyone thinks of similar holes I should consider, please shoot me an email at info@patchbay.pub. There are a whole new set of security issues that crop up with this sort of system. Definitely be aware of that before using it!
I assume "that one" is posting to /.well-known/.
EDIT: also, the current state of the code base is not something I'd be excited about having my name attached to ;)
It won't stop bad actors from stealing your code and using it but you will stop most corporate actors from touching it (and they are the ones you'd want to pay in the future anyway).
I love this thing though. So simple but powerful.
If I don't see one by EOD I'll have to make - is thing is super cool
https://github.com/sairam/daata-portal/tree/master/daata-ser...
Secure Scuttlebutt is a P2P pubsub system for sending files, messages (chat/notifications), and everything else you can implement with pubsub-like systems.
I think it's just confusing because of the overlap with:
- Patchbay
- Pub
- Channel
If you're curious about SSB, I've posted a link to your site on the network. You can view that (and other content) here: https://oasis-demo.fraction.io/thread/%25IGLa%2F3NDG3cj5gYOY...
Congratulations for shipping it!
This was from a few years ago - https://github.com/sairam/daata-portal/tree/master/daata-ser...
When people working in ops or with remote CLIs would have a great need for such a tool.