It is not essential to host the thimbl api on a mammatus cloud, that’s just how our implementation will work.

Best,

I got the impression that there was a dependency on DNS from your slide show on thimbl.net, which says that your system relies on DNS, SSH and finger.

I would like to understand your mammatus platform, but your “how it works” page, where I assume it will be explained, is incomplete and as of now only has a diagram on it with a “Mammatus cloud” component. I look forward to learning what is inside the “cloud”.

I think your concept is promising. Good luck with it.

Myst, the decentralization is a biproduct of the multi-tier architecture, the DNS dependency is only for our own implementation of the API tier. Since we expect that lots of hosts will chose to use our API instead of running that tier on their own, we created the mammatus platform to easily scale our own API deployment. There is nothing in the Thimbl architecture that depends our DNS-based HA model, anymore than any other platform that needs to resolve domain names. The profile and account services are plain twisted/python that a host can implement separately from Mammatus if they want, we will also create a standalone API implementation later on.

Chris, StatusNet is a centralized web-app with federation bolted-on. Thimbl is a distrubuted, transparently interoperable multitier platform based on established standards, that is why Thimbl does not store any client data whatsoever, why you can participate in Thimbl without installing anything developed by the Thimbl project on your server, just running software you already have, finger & ssh, and why any user will be able to use any instance of the UI (which anyone can clone and host, since it’s just static html & javascript) and any instance of the UI can work with any instance of the API (which itself based on the distributed Mammatus platform wich we developed for this purpose). See the Diagram here: http://www.thimbl.net/#about

The similarity betweebn Thimbl and platforms like StatusNet is only superficial, in that we draw upon similarities with
web2.0 platforms in how we communicate our use-case.

Regarding OStatus, we can and will bolt-on suport for different federation protocol such as OStatus at the API layer (and maybe even UI layer) but not in the first itteration, since our goal now is only to produce a “minimal viable product” and build a community around the platform.

Thanks for the comments.

One concern I have is that they don’t seem to be following the OStatus protocols (formerly OpenMicroBlogging), so it won’t play as nicely with other microblog services, esp Identi.ca/StatusNet. Admittedly it’s only sites using StatusNet software that follow it so far, but at least it’s a protocol which already works and successfully interfaces with many services and clients.