Has tent fixed the massive issues with their protocol? When it first came out, I opened about 30 issues on the repository. They basically let them all get quiet and then closed them without comment. One or two had a bunch, though.
I think the major issue with Tent was that their development efforts had always been divided between two Tent servers. Tentd, the reference implementation used by self-hosters, and their proprietary multi-tenant server that powers https://micro.cupcake.io. But in a blog post in November 2013 (https://cupcake.io/blog/2013/new-tent-server), they announced that they will stop the development of Tentd and open source their multi-tenant server. The development of https://flynn.io (another Cupcake project) will simplify the deployment of the multi-tenant server. The first preview release of Flynn was announced two weeks ago (https://cupcake.io/blog/2014/flynn-preview-release).
Hi, Steve. Most of the github issues you opened (in the week after Tent 0.1 was announced) weren't "problems" with the protocol, just differences of opinion with our architectural choices. For a variety of reasons that we discussed extensively we felt (and still feel) that hypermedia, microformats, and other preexisting attempts to solve "decentralized social" aren't good solutions to the problems we're trying to solve. A few of the other issues you raised were actual implementation errors (we shipped the initial proof of concept very quickly), and to my knowledge they've all been fixed.
In the first few days after we released the first Tent proof of concept we were swamped with user feedback and a variety of discussions. We addressed many architectural questions in detail from "why not use a custom binary protocol" to "consider using ostatus, microformats" and "Consider not making claims about REST". If you're still interested in any of these topics I'd be happy to explain in greater detail the reasons for our choices.
Tent has evolved a great deal since the initial release. We've discussed most of the reasons behind the choices we made in great detail on Tent, IRC, and during monthly office hours, recording of all are available online.
> A few of the other issues you raised were actual implementation errors (we shipped the initial proof of concept very quickly), and to my knowledge they've all been fixed.
Awesome, great.
The biggest one, in my mind, is the 'one POST per follower per message' problem. The previous stance was, and I realize I'm being a little bit uncharitable with this characterization, "we want people who use the service a lot to have to pay, so we're keeping the protocol inefficient for this purpose." Is this still the way things work?
And yes, while a lot of them do come down to opinion, a service that re-invents the world in this space sends off really bad signals. It's just a different kind of lock-in. Same beef I had with App.net.
> The biggest one, in my mind, is the 'one POST per follower per message' problem.
Yeah, all distributed systems must communicate with their peers. In the worst case this means sending a POST for each message to each subscriber since each subscriber is a different server. This can be optimized by pipelining messages that were sent within the same time window.
In the best case, which is probably the most common, multiple users will share the same host and the protocol can be aware of this and add an envelope that specifies all subscribers on the host with a single copy of the message sent to each host instead of each subscriber. We plan to add this optimization before Tent 1.0.
There hasn't been much updates on Tent since the last office hours in January (https://tent.io/officehours/2014-01-28), but Daniel said a few hours ago that they will announce May office hours in the next few days (https://micro.cupcake.io/posts/https%3A%2F%2Fdaniel.cupcake....).
I'm really excited for the new features in Tent 0.4 (https://github.com/tent/tent.io/issues?labels=v0.4&page=1&so...) and I can't wait to self-host Tent on the new multi-tenant server!