Hacker News Reader

Comment by jaredcwhite | Hacker News Reader

It's frustrating news because the platform never actually got to the point where it could be used as back-end infrastructure in the manner of something like, say, Stripe. In other words, I couldn't built a website where users simply sign up/in, use the service, share content, etc., and not really be aware they're using App.net under the hood. I think App.net shot itself in the foot by being implemented more or less as a Twitter clone to start with. That meant that there was constantly a branding problem -- user wonders "Why am I on Website X and they're asking me to create an App.net account...what's that?!?!"

We still need a ubiquitous social/identity/billing platform that undergirds the web, yet can be used seamlessly by devs of any particular site without exposing the guts of said service. I'm waiting for someone to actually build that...waiting...waiting...

View on HN

I'm in 10000% agreement. And I know from past conversations with Dalton, that this was his larger vision too.

I do agree that starting and focusing so much on the Twitter-clone aspect was what prevented the service from moving beyond that.

It's a shame too because we do need the pipes and infrastructure that can exist without being tied to any specific platform. Build the platform later -- customize it -- but let the identity act as its own piece.

Check out https://tent.io and https://cupcake.io. There's not much going on at the moment because everybody is waiting for the next version of the Tent protocol (0.4), which will be released in a few months.

I am also excited by http://maidsafe.net in the long term, because it replaces the web altogether.

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.

EDIT: turns out it was 18, not 30: https://github.com/tent/tent.io/issues/created_by/steveklabn...

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).

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!

Absolutely correct. We'll also release a protocol validator for 0.4 prior to the server refactor to help other folks implementing other servers.

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.

Right. This is the kind of thing you'd basically get for free if you just used PuSH instead of reinventing the world.

Anyway, good luck. My efforts in this space have failed and you're still plugging away, so...

One of the Tent architects here.

We're actively working on 0.4. The big challenge right now is that a number of organizations are considering using Tent is very large scale deployments for sensitive data, so we're making the transition from move fast and break things to enterprise grade reliability.

This includes everything from a solid protocol validator (future versions of the protocol will have complete validation coverage before we release a reference implementation) and a highly scalable multi-tenant server that large service providers can easily deploy. We're refactoring the server we use for hosting Cupcake users and releasing it under a permissive license in the next few months to make that transition easier.

So it's an exciting time for the core team but there isn't a ton happening on the surface just yet.

Our goal has always been to get Tent to a solid 1.0 after which the APIs could remain unmodified for several years at least (similar to HTTP and SMTP). The tradeoff is that we then need the freedom to break things between versions of the pre-1.0 versions. It's frustrating for early app developers (one of the reasons we don't encourage adoption) but will pay off once we hit 1.0

Have you tried pump.io? That sounds like exactly what you're describing. It works very well at the moment, and you could build just about anything on top of it.

Is that thing still alive? The open issues and unapplied pull requests are really piling up, and some of the public servers seem to be down.

Yes, very much so! Pump.io is much more than the core itself. Lots of desktop, mobile and web applications around it!

Absolutely. I use microca.st every day. The platform only keeps getting better.

Spot on. A lot of people mistook it for a twitter clone. If it was branded as "infrastructure" it might have done better.

Not trying to be snarky, but isn't this "email"?

Email is direct messaging. Even the current incarnation of "social networks" are much more than that, and what they could be in the future is bigger still.

The web would be a better comparison. But with useful metadata.

I'd say "no", since existing email clients don't lend themselves to custom per-message user experiences.

Couldn't better email clients and e-mail services be made that do? I'm trying to look at this from an idiot's perspective (which may not be all that far from my ordinary perspective, because I don't know a huge amount of detail about how email works).

Theoretically, but that's not part of the model today. And if you're going to innovate on that, it's unclear that you'd want to do it on top of SMTP as a transport, rather than something newer. SMTP itself provides very little in the way of assurances about identity, deliverability, etc., all of which you'd care about as you build something higher-level.

The closest thing to innovation in this space that I know of is the stuff that Gmail is doing with custom actions [1] and contextual gadgets. And even there, they are parsing the HTML-ish body of the email to trigger the behavior, which is pretty far away from the SMTP layer itself.

[1] https://developers.google.com/gmail/actions/actions/actions-...

Cool. I'd like to look into this a little further.

Man, I've though the same thing many times. Where would you start? What would you build first? How to get the initial user base?

Reply on news.ycombinator.com