I wish we could stop calling things "broken" just because they work in a way that's well thought out but unconventional. How are we ever going to make progress on UI design if everyone immediately gets chastised for deviating from more orthodox web behavior by even the slightest amount?
EDIT: lbarrow is correct that the hash tag navigation is borked. I thought people were just complaining about navigation to a previous site on the same tab. I stand corrected, I fully agree it's broken.
I know @gr2m, one of the guys behind Hoodie - he's one of the most awesome and holistic engineers I have met in my professional career! Also he's a regular speaker at conferences and devoting his time for charitable work.
If you don't have a backend ninja in your dev team, you should take a serious look into Hoodie!
There are probably videos. However, I do not have links.
But he was one of the speakers at re:publica[1] two weeks ago in Berlin as well as one of the moderators of the Global Innovation Lounge that was streamed by voicerepublic[2].
no worries, and thanks! Actually, there is already at least one app in production running on it for a few months now plus a few MVPs, so if you want to go for it: do it. We're currently working towards the release of 1.0.
Yup :) — We are aiming for the Google Docs sharing model eventually. It is specced out and we are slowly implementing it bottom up based on current use-cases.
I'm more the frontend guy at Hoodie, but what you'll be able to do is to allocate roles to users and based on the roles you can give read/write access down to document level.
If you have a specific scenario in mind, I'm happy to elaborate.
would like to know a bit more about comparisons with other realtime & offline-syncable BAAS like: Meteor, Firebase, AngularFire etc -
As a non-dev, this looks very appealing, but before I start learning I wanted to know more about the strengths/weaknesses compared to others.
Hoodie is Open Source and more like BYOBAAS (Bring Your Own Backend As A Service), you can host it yourself, or pay someone to host it for you. You are not beholden to single company’s VCs.
Meteor is about exposing backend and frontend APIs to the browser. Hoodie hides backend complexity as much as it can. The target audiences are very different. Hoodie aims for more frobtendy/designery types, in the future Hoodie definitely wants to reach non-coders as well.
Firebase and Meteor have likely seen more development time, because Hoodie is supported by a bootstrapped company that works on Hoodie part-time and puts it’s profits into future Hoodie development. That way Hoodie moves slower, but Hoodie won’t be at a crossroads when VC funding runs out, or expected growth isn’t big enough.
As far as I can tell, Hoodie’s offline/sync/p2p story is more solid than any other solutions, but then, I’m heavily biased :)
Hoodie’s focus on clean and simple APIs also makes it more easy for beginners.
yeah, my point here is that Meteor gives full-stack (yuck) developers all they need to build quick apps. Hoodie targets UX/Designers/Code-copy-and-pasters.
Full-tack devs will be incredibly quick with Hoodie, like they would with Meteor (or vice versa), it’s just a fundamental difference in design and implementation.
Firebase does provide robust retry behavior. It tracks data changes, allows explicit online/offline mode, and you can easily write event handlers for sync errors. It also has what looks to me like a much more complete security model.
Well, I work for a registrar. I know practically all the tricks around their silly rules at this point and was more wondering which particular set of tricks you used. :-)
I was thinking that initially, but it looks to be a proxy registration with somebody else acting as the domain holder. The domain holder is 'Paul Campbell', who registered under the category "Discretionary Name" as a Sole Trader. I'm guessing there were some little fibs used to get the registration past the hostmasters... :-)
I thought much the same thing. Back in the day getting anything .ie registered was a massive pain, and you could pretty much forget it if you weren't an Irish business or highly motivated individual. They'd even try to impose content restrictions (ie. no adult content)
IIRC it got to the point once that a satirical radio show ran promos for what it claimed was the first porn site on .ie, but the link was actually to a gallery of a disheveled blonde helping to push a car out of a ditch. Which I suppose would count for some people, Rule 34 after all.
Which has nothing to do with hood.ie - overall I'd say it looks interesting, and a great way for a FE dev to build a prototype or v1.0 of a web app. I'd be very nervous about scalability though.
Happy to hear! There are various ways - no matter if you're a developer or not, we're happy if you want to contribute (if you want to contact us for details, see http://hood.ie/#about ). There's also the opportunity of sponsoring (http://hood.ie/sponsoring.html) which is also possible for individuals. And you can of course always help us by spreading the word about Hoodie if you like it, perhaps giving a talk about it, writing a plugin if you want to extend Hoodie's core features (https://github.com/espy/hoodie-plugin-tutorial) or giving us feedback.
Yes comma but :) — We have a production app, but we are very comfortable running Hoodie in production ourselves, of course. The app has 10k registered users and some decent, but no overwhelming traffic. For similar scenarios, Hoodie is definitely ready, for others, we’d caution and recommend to get in touch with us for a more thorough evaluation.
Any particular (eg: technical) reason it doesn't support Android but does support iOS? If Android will get there one day I'd certainly be interested, but if it's never coming for some reason I'd probably look elsewhere.
No technical reason, we are just lacking the person-power to tackle Android now. It should be straightforward to port from the iOS and web versions and we’d be super happy if someone would take that on :)
If you wonder how the synchronization works, it's currently using a custom solution which is built on top of local storage. However it seems[0] that they are planing to switch to the awesome Pouchdb[1].
I looked at pouchdb's website and there's a lot about browser support but I didn't see any docs about the data model. It seems you're expected to know how CouchDB works?
Yeah, it’s a document database, uses UUIDs and revisions for identification and does HTTP-based P2P replication. In Hoodie we abstract that away in a simple to use `hoodie.store` object with the usual `add()`, `update(), `find()`, `findAll()` methods for operations. No need to know about the CouchDB/PouchDB specifics, just store your objects :)
Okay, but the key design decision in any data syncing library is how it resolves update conflicts. Is it last-one-wins, report an error and try again, diff merging, or maybe some kind of operational transform?
Since that's the heart of the problem being solved, it's weird when the docs leave it out.
Conflicts are detected for you, like in version control systems. You need to resolve them yourself, or you can implement a server-wins/client-wins/last-write-wins scenario, if you want to.
Operational Transformation does not work offline at all, and offline seems to be at the heart of Hoodie. OT requires a central point of coordination. That's why the current Google Docs freezes editing if your connection goes. For offline syncing, you need to use CRDTs.
The PouchDB documentation is quite light right now and does assume users are familiar with CouchDB, it has the same semantics as CouchDB (conflicts are stored and resolved by the app)
The documentation and tutorials will be a big focus going forward
>It took less than 15 minutes for a person with no experience in any part of the stack to take an existing single user app and make it a multi-user application with robust security and data storage. […] Bravo, hood.ie, brav-fucking-o.
I think you'll find that you can make a multiuser app from a single user app rather straightforwardly in a day. Although 15 mins would be only for a Q expert.
i building code generator with less then a second to create application. But more focus on business logic environment.All be cater such as header and master detail form.But like most generator code,there is overweight of code.Some code need to removed.The code are based on php.Have try to generate java crud form also but not satisfied with java generic issue.If somebody can help port to other language ,could be great.Sorry latest code don't put in the github yet.
You might like to see two of the Hoodie-ers talking at LXJS, and taking a skeleton app to supporting multiple users with data storage, the whole talk is 20 minutes, but the coding part is much, much less. https://www.youtube.com/watch?v=iyjwlvwOoA4&hd=1
In addition: Meteor data is public by default, and the architecture is always online, whereas Hoodie data is private by default, and the architecture is offline by default.
Besides the points already mentioned, Meteor is VC backed. Hoodie is an open source project first, that we founded & bootstrapped a company for to sustain its future, and that we will eventually turn into a non-profit. We are and will be not accountable to any investor with questionable interests in an open source project.
How is one of the first apps to popularize AJAX, developed on top of a proprietary cross-compiling framework by a top-3 web giant "no different" from Hoodie? Obviously you're getting at some specific point that is completely obscured by the ridiculousness of the comparison. Hopefully it's more than "client-side logic can be useful" because that much is obvious on its face. It's also obvious that the idealized promise of no-backend falls apart pretty quickly for a majority of real world apps. So what is your point exactly?
Sorry, from “delivering business logic to the client” perspective, Hoodie is no different in concept on that angle. Lots of things are very different, of course :)
Can you give an example for why that signup code is bad? In the case that I'm using Hoodie with CouchDB, wouldn't Hoodie just AJAX post a user document to the CouchDB _users database (which is a good implementation)? All of the access control would be in the hands of the server with minimal (if any at all) security logic in the front end.
Yeah, but you're going to see a <form> that POSTs to some target URL, with username and password as fields. The only thing protecting the plaintext password from leaking is SSL. POSTing a XmlHttpRequest is equivalent.
I’m a Hoodie developer, I know what Hoodie does and doesn’t. That disclaimer is just there because some of the things don’t yet work as documented. The particular feature is definitely in existence :)
Desktop clients have been delivering business logic to clients for a very long time with few problems. Web powered apps are similar. The issues involve protecting data stored in the cloud, communicating over secure channels and client security. JavaScript powered applications running in a browser have many security considerations, but they're manageable if you have security aware engineers building your application. Knowing about OWASP[1] helps.
Are there any e-commerce platforms that trust the client to do all the business logic for an order/checkout? If so how do they prevent client side tampering with the business logic without redoing it on the server side?
It seems a naive proposal at best to suggest the client would get business logic in lieu of the server. Typically clients need to assist users and they do that by use of business logic based validations and constraints.
Oh I agree but the GP seemed to indicate that trusting client side logic is a solved problem for web apps. I was curious if he had any sort of examples since it doesn't seem to be something related to the issues he listed.
we don't deliver all our business logic as JavaScript to the client, we just provide a nicer API. All security / scaling / business logic still lives server side.
Take hoodie.email.send(properties) as an example. It just the same as `POST /email` with email properties JSON, with the only difference that it's simpler to understand and to handle for frontend people, and it works offline (syncs when connection is back).
I've been delivering apps just like that for 15 years without problems. As far I can remember there hasn't been an single case where this would have been a real problem.
I'm well aware that it isn't a perfect solution but it just works.
Yes I am aware of it. I also like it a lot. The Q Platform is able to interoperate with that Q library as well as with Angular, etc.
There are also several languages named Q. I don't think "Q Platform" is the same thing as a promises framework. It's not even for Javascript only. So why downvote the platform because there is something named similar to it?
It's also notoriously painful to register a .ie domain. You need some connection to Ireland, but even if you do there are restrictions on what you can register (needing to have a company name or registered business name matching the domain, for example). They have loosened up considerably on the discretionary domains, but it still seems to take at least a week to get your registration approved and completed.
Less than you might think. It's not a trivial matter to get an .ie domain. The IEDR's rules make things difficult if you can't either (a) demonstrate a connection with Ireland the reviewer will accept or (b) demonstrate that you trade in the Irish market. There are ways around some of their rules, such as getting a registered business name from the CRO, but it really is a pain in the backside.
I write this as somebody who works for one of the biggest .ie registrars.
Isn't creating an Irish company relatively easy (if you are in EU)? I guess its a fair amount of work and cost to get a nice name if you dont want a company...
Comparatively speaking, yes, but they're registered in Germany, so that wouldn't fly. It looks like they used a proxy registrant and some well placed fibs to acquire the domain name, which is one of the more dicey ways to go about it as the IEDR aren't afraid to pull registrations.
Much safer and saner is to get a Registered Business Name number from the CRO. It doesn't cost much, you have it practically forever, and it's possible for private citizens and foreign corps to get them.
Giving full email privileges to the client is a terrible idea. Even if you do rate limiting, you're essentially allowing anyone to get your mail server(s) blacklisted and all future mail from anyone marked as spam.
In general, most people would be naturally apprehensive about federating their entire user authentication system through a third party. However, I suppose that by using hoodie you are supporting a group of people whose only job is to ensure security and fix vulnerabilities in your login system. It's also open-source, so you can vet it for yourself.
The JS library needs more work though - I could think of several basic use cases that it can't handle. It would also be great to see some full examples. Overall this is very cool stuff.
Hoodie doesn't provide any email privileges in it's core. There is an email plugin that does that, but it's just a showcase and we would not recommend to use that in a production app. The plugin is maybe 10 lines of code, you can easily use that as base and put all the security in it that you would do in a REST API as well.
I'd be also very interested in your basic use cases that you think Hoodie couldn't handle. It would certainly be great input for the project.
We also encourage people not to use Hoodie in production, yet :)
What @gr2m means: there is no reason Hoodie’s mail feature would work any different from a traditional web app. At some point a server side will validate a client request, and if valid, translate that into sending an email (Gmail comes to mind). Hoodie’s email plugin can do exactly that, except that today’s implementation is a mere sketch of that, like other parts of Hoodie, that show what can be done, but aren’t hardened against production use, yet. None of that means though that Hoodie behaves any differently from a security/abuse/DOS perspective than any other web app :)
Thanks for confirming my crosspost :) However, as I was just saying, wouldn't it be nice to clearly see that we're talking 0.x directly on the website and not only when we install the npm package?
EDIT: Thanks for your answer, I am going to stop crossposting now :D
Our goal is to lower the barrier of entry to build fully capable applications. While using the simple email plugin is not a good idea in a production app, there is no problem to use it with an app that runs on your computer only, or in your companie's intranet.
I know this is nightmare to system architects / backend developers at first sight, but trust us, we know exactly what we are doing. We have excellent architects on our team, you just might not be our primary target group here.
To be fair they are still working on 0.x, they probably don't recommend the whole thing to be used in production (although I personally wouldn't mind for some specific projects...). At this stage, I understand they just want to showcase some cool stuff. This being said, we should always be really careful about security when using dependencies, especially when it's in beta, and especially when mostly everything is done client side. It would be also nice if something more explicit was mentioned on the hoodie website. Like the last release version for example (0.x).
As discussed before here on hn (https://news.ycombinator.com/item?id=5514284), this seems like a great successor (or at least a well-maintained alternative) to CouchApps and Kanso. I will definitively give it a try once PouchDB becomes a dependency :)
Moving from a request based business logic to data based business logic (processing incoming data, as opposed to processing incoming http requests) is an interesting shift. Does anyone know what this kind of system is called? I'd love to do more research.
Heya @reconbot, I don’t know if this specific system has a name, but it is something akin to a messaging bus, where clients and servers just exchange messages, if they have a network connection. Messages can carry raw data (a user record), or intents (send this email), and both sides agree on what to do with certain types of messages. Hope this helps! :)
looks cool on several levels: empowering people to build the things they want w/o being "1337", volunteer driven, a "noBackend"/"One Backend Per User" (http://www.infoq.com/presentations/private-backend) default for a freer internet, and named after one of the most versatile articles of clothing ever invented.
the hoodie-server repo clocks in at just under 3k lines of javascript, though. i mean, there are a bunch of plugins, and wc is far from the best metric, but it's the only one that i've time for while this is still near the top of the list, so i'll just ask:
is this whole project to be viewed more as kick-ass-but-still-in-progress codebase or more like a socio-political statement about what happens when you make creating a single user's experience the priority (vs. trying to roll out an app that could scale your user base while still managing to own all their data)?
You basically nailed it :) — Hoodie is probably further along that it might seem. The team has been working on earlier iterations of this for nearly a decade now, and we have learned a lot along the way, allowing us to be very concise this time around. In addition, we have chosen a few powerful abstractions to make the actual implementation rather tiny.
That said, there is lots of work to be done, to make it, say, Rails, or Django-grade production ready, but the rough sketches are there and we are comfortable running a production app since December 2013, and we are working with a bunch of clients on their products, that we are comfortable with putting our reputation on the line for.
After 1.0 (we are pre), we want to be very explicit with the different levels of stability and maturity we ascribe to all parts of the system and the whole release overall. Our current production app handles 10k registered users on a small VPS without much sweat, so anywhere in that order of magnitude, with similar usage patterns, we thing Hoodie rocks the real-world, but if you are significantly diverging from this, we want to be careful and only recommend other’s to rely on Hoodie, when we have reasonable first or second hand experience of similar scale and use.
As for the socio-political statement: that’s definitely a big part of our motivation. We want to write and spread a story that isn’t the usual idea-vc-flip-sunset / abuse-overworking-cheating horror stories. And freeing data and empowering users is a future we want to see, so we are building it :)
We're working on a similar no-backend product called Hoist that does most of what Hoodie is but is a hosted solution. We do all the 'server' work so you can just build your app. We provide API's for everything from Data management (just post and get JSON) and user management. We're also working on integrating other cloud company API's so you can quickly get hooked up to them (and do the auth with tokens) on the server side and then use their API's in a fully client-side app.
Our client library is entirely open source, but our platform itself is not as it's a commercial no-backend offering. This allows us to offer production-grade hosting for these types of no-backend apps.
Many companies offer production-grade hosting for open source applications. The fact that you are keeping your source closed tells me that you are afraid a competitor (or your clients themselves) could achieve an equivalent quality of hosting for less than they would pay you. To a customer like me, this is bad news.
We absolutely think that open sourcing code is important, but not just a giant lump of all of it; a mountain of code not always useful.
It's still early days for us but we are considering open sourcing reusable parts of our platform or allowing people to host their own if they wish, but we haven't yet decided on which we will pursue yet.
146 comments
[ 3.0 ms ] story [ 191 ms ] threadThey should fix it by not pushing those minor state changes to history, though. Probably an easy fix.
EDIT: lbarrow is correct that the hash tag navigation is borked. I thought people were just complaining about navigation to a previous site on the same tab. I stand corrected, I fully agree it's broken.
http://web.archive.org/web/20100413141437/http://getangular....
More details: http://www.niden.net/2009/12/world-with-part-1-reviewhow-to....
If you don't have a backend ninja in your dev team, you should take a serious look into Hoodie!
But he was one of the speakers at re:publica[1] two weeks ago in Berlin as well as one of the moderators of the Global Innovation Lounge that was streamed by voicerepublic[2].
1. http://re-publica.de/user/2037/event/1
2. https://voicerepublic.com/venues/196#archived-talks
Hoodie also relies on sponsorships, donations, gittip and other sources of revenue: http://blog.hood.ie/2014/01/how-is-hoodie-funded/
And here are a ton of more talks, slide decks, podcast links to Hoodie and closely related topics Offline First and noBackend: http://blog.hood.ie/2014/05/talks-about-hoodie-offlinefirst-...
(Disclaimer: Team Hoodie again :) )
Missing boom, shot, now lru-cache...down the rabbit hole.
will there be ways to manage some complex ACL scenarios ?
If you have a specific scenario in mind, I'm happy to elaborate.
Meteor is about exposing backend and frontend APIs to the browser. Hoodie hides backend complexity as much as it can. The target audiences are very different. Hoodie aims for more frobtendy/designery types, in the future Hoodie definitely wants to reach non-coders as well.
Firebase and Meteor have likely seen more development time, because Hoodie is supported by a bootstrapped company that works on Hoodie part-time and puts it’s profits into future Hoodie development. That way Hoodie moves slower, but Hoodie won’t be at a crossroads when VC funding runs out, or expected growth isn’t big enough.
As far as I can tell, Hoodie’s offline/sync/p2p story is more solid than any other solutions, but then, I’m heavily biased :)
Hoodie’s focus on clean and simple APIs also makes it more easy for beginners.
It is the weirdest description of Meteor I have seen so far.
Meteor is all about helping developers to build excellent web apps with ease and spending less time, not providing APIs.
Full-tack devs will be incredibly quick with Hoodie, like they would with Meteor (or vice versa), it’s just a fundamental difference in design and implementation.
IIRC it got to the point once that a satirical radio show ran promos for what it claimed was the first porn site on .ie, but the link was actually to a gallery of a disheveled blonde helping to push a car out of a ditch. Which I suppose would count for some people, Rule 34 after all.
Which has nothing to do with hood.ie - overall I'd say it looks interesting, and a great way for a FE dev to build a prototype or v1.0 of a web app. I'd be very nervous about scalability though.
[0]: https://github.com/hoodiehq/hoodie.js/issues/8
[1]: http://pouchdb.com/
Since that's the heart of the problem being solved, it's weird when the docs leave it out.
Conflicts are detected for you, like in version control systems. You need to resolve them yourself, or you can implement a server-wins/client-wins/last-write-wins scenario, if you want to.
The documentation and tutorials will be a big focus going forward
I find that extremely hard to believe.
Given that Hoodie’s whole focus is on hiding backend complexities, it is not too far fetched, though.
I would have left that part out. Partly because it doesn't really roll off the tongue well, and partly because it comes across as hubris.
I think you'll find that you can make a multiuser app from a single user app rather straightforwardly in a day. Although 15 mins would be only for a Q expert.
Meteor (and Derby etc) is a full stack JS setup, where you manage both the browser and node.
Both do data sync.
Gmail's code base is not a "offline first, mobile first" platform. The API that is exposed to the client-side is fairly light (watch the traffic).
I highly suggest use research "business logic flaws" in web apps. Anything Jeremiah Grossman has said on this topic is good stuff.
Thanks for the pointer to Jeremiah, though :)
http://cl.ly/image/1o1K2f202T3c
https://developers.google.com/gmail/actions/reference/one-cl...
https://developers.google.com/gmail/actions/actions/actions-...
I'm actually surprised so few companies have implemented it thus far.
"This document describes functionality and features that don't exist yet."
https://github.com/espy/hoodie-plugin-tutorial/pull/13
[1] https://www.owasp.org/index.php/Main_Page
Take hoodie.email.send(properties) as an example. It just the same as `POST /email` with email properties JSON, with the only difference that it's simpler to understand and to handle for frontend people, and it works offline (syncs when connection is back).
http://hood.ie/#plugins
I'm well aware that it isn't a perfect solution but it just works.
https://github.com/zoePage/hoodie-drawing is an example app.
Not released yet -- but if someone has PHP / JS / PhoneGap skillz and wants to work with us, you can be an early member of the community.
https://github.com/kriskowal/q
There are also several languages named Q. I don't think "Q Platform" is the same thing as a promises framework. It's not even for Javascript only. So why downvote the platform because there is something named similar to it?
Another example: http://en.wikipedia.org/wiki/X_Window_authorization
https://dev.twitter.com/docs/oauth/xauth
https://www.google.com/support/enterprise/static/postini/doc...
I write this as somebody who works for one of the biggest .ie registrars.
Much safer and saner is to get a Registered Business Name number from the CRO. It doesn't cost much, you have it practically forever, and it's possible for private citizens and foreign corps to get them.
In general, most people would be naturally apprehensive about federating their entire user authentication system through a third party. However, I suppose that by using hoodie you are supporting a group of people whose only job is to ensure security and fix vulnerabilities in your login system. It's also open-source, so you can vet it for yourself.
The JS library needs more work though - I could think of several basic use cases that it can't handle. It would also be great to see some full examples. Overall this is very cool stuff.
I'd be also very interested in your basic use cases that you think Hoodie couldn't handle. It would certainly be great input for the project.
You do realize that by putting it in your documentation, you're encouraging people to use it.
What @gr2m means: there is no reason Hoodie’s mail feature would work any different from a traditional web app. At some point a server side will validate a client request, and if valid, translate that into sending an email (Gmail comes to mind). Hoodie’s email plugin can do exactly that, except that today’s implementation is a mere sketch of that, like other parts of Hoodie, that show what can be done, but aren’t hardened against production use, yet. None of that means though that Hoodie behaves any differently from a security/abuse/DOS perspective than any other web app :)
EDIT: Thanks for your answer, I am going to stop crossposting now :D
I know this is nightmare to system architects / backend developers at first sight, but trust us, we know exactly what we are doing. We have excellent architects on our team, you just might not be our primary target group here.
But thanks for your feedback, much appreciated!
Will report back shortly.
the hoodie-server repo clocks in at just under 3k lines of javascript, though. i mean, there are a bunch of plugins, and wc is far from the best metric, but it's the only one that i've time for while this is still near the top of the list, so i'll just ask:
is this whole project to be viewed more as kick-ass-but-still-in-progress codebase or more like a socio-political statement about what happens when you make creating a single user's experience the priority (vs. trying to roll out an app that could scale your user base while still managing to own all their data)?
anyway, it seems like some of each.
That said, there is lots of work to be done, to make it, say, Rails, or Django-grade production ready, but the rough sketches are there and we are comfortable running a production app since December 2013, and we are working with a bunch of clients on their products, that we are comfortable with putting our reputation on the line for.
After 1.0 (we are pre), we want to be very explicit with the different levels of stability and maturity we ascribe to all parts of the system and the whole release overall. Our current production app handles 10k registered users on a small VPS without much sweat, so anywhere in that order of magnitude, with similar usage patterns, we thing Hoodie rocks the real-world, but if you are significantly diverging from this, we want to be careful and only recommend other’s to rely on Hoodie, when we have reasonable first or second hand experience of similar scale and use.
As for the socio-political statement: that’s definitely a big part of our motivation. We want to write and spread a story that isn’t the usual idea-vc-flip-sunset / abuse-overworking-cheating horror stories. And freeing data and empowering users is a future we want to see, so we are building it :)
Check it out: http://hoistapps.com
Would love to hear what anyone thinks if you give it a go. I can be emailed on ow@hoistapps.com
It's still early days for us but we are considering open sourcing reusable parts of our platform or allowing people to host their own if they wish, but we haven't yet decided on which we will pursue yet.