Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Tent - the decentralized social web

tent.io

Post reply on HN
Print view View original

21–30 of 229 posts

Re: Introducing Tent - the decentralized social web

#21

Post by bickfordb »

mbreese wrote: post #7

Why is it that every new protocol seems to want to piggy back on HTTP? It seems to me that maintaining state would be a useful feature for a social protocol. Another issue is that this assumes that the web will be the client of choice in the future... with mobile apps being as big as they are in the social space, this seems a bit shortsighted. Don't get me wrong, I like the idea behind having a "social server", but I…

People build things on top of HTTP because HTTP is a pretty general, reasonable, easy to implement protocol; most alternative protocols tend to re-invent something like it or not become popular. Most protocols resemble or can be implemented on top of (Action, URI, Headers, Body) => (Status, Headers, Body). Most of the improvements suggested to HTTP tend to come in the form of encoding messages more efficiently at the cost of extensibility. Reasonably efficient HTTP servers exist for every platform.

I'm not sure exactly what you mean by maintaining state, but if you mean long-lived connections: this already exists in HTTP with chunked-encoding and the new web socket extensions. Stateful protocols tend to be more difficult to write programs for and load balance.

Re: Introducing Tent - the decentralized social web

#22

Post by gnaritas »

mbreese wrote: post #7

Why is it that every new protocol seems to want to piggy back on HTTP? It seems to me that maintaining state would be a useful feature for a social protocol. Another issue is that this assumes that the web will be the client of choice in the future... with mobile apps being as big as they are in the social space, this seems a bit shortsighted. Don't get me wrong, I like the idea behind having a "social server", but I…

> Why is it that every new protocol seems to want to piggy back on HTTP?

For the same reason cars all want to drive on the same roads.

Re: Introducing Tent - the decentralized social web

#24

Post by danielsiders »

Torgo wrote: post #18

I am not convinced that this needs a new protocol as they claim. Facebook-style functionality be done on top of activity streams, pubsubhub, salmon, webfinger et al. They indicate they have investigated existing systems and found them lacking. I would rather have something like this built on protocols that a bunch of people have discussed out in the open first. That said, I am interested to see more details as they a…

We considered the protocols you're mentioning. There are a few huge problems for our use cases: PSH is built on Atom which means all feeds are public. That's fine for your public feed ala Twitter, but unacceptable for private messages. We also think it's critical for users to be able to take their relationships with them when they move to another server/provider. OStatus and PSH don't make that possible. They also don't have a standard application access API, so developers have to work around different providers' specifications if they exist at all.

The federated social net was a great first step, but the lack of support for access control/private messages and account portability means that you end up with lots of proprietary implementations of basic features which can create vendor lock-in.

Re: Introducing Tent - the decentralized social web

#25

Post by lucaspiller »

pwf wrote: post #16

It seems like this will use up a crapton of bandwidth with its 'push' style notifications. If someone with a million Facebook followers makes a new post, one entry is made in the database and then users pull it down as they visit their own pages. If a million people decide to 'camp in my tent' (?), my server is suddenly pushing out gigs of data every time I make a post.

Even worse are pictures and videos. Rather than including a URL to it, the 'push' includes the base64 encoded binary data. Hmm.

Re: Introducing Tent - the decentralized social web

#26

Post by smacktoward »

Torgo wrote: post #18

I am not convinced that this needs a new protocol as they claim. Facebook-style functionality be done on top of activity streams, pubsubhub, salmon, webfinger et al. They indicate they have investigated existing systems and found them lacking. I would rather have something like this built on protocols that a bunch of people have discussed out in the open first. That said, I am interested to see more details as they a…

Or at least some hard details about what those existing alternatives are lacking. That could lead to further improvement, as whatever communities have already formed around those alternatives could debate the questions and possibly improve their protocols.

As it is the FAQ reads like "those are old and busted, we wanted something new and hot," which gives off an aura of NIH syndrome.

Re: Introducing Tent - the decentralized social web

#27

Post by ivansavz »

This would be the "killer protocol" for the freedombox, if combined with some smart dyndns management.

Here is a use case scenario I am imagining. I define two servers for myself: home.me.com and cloud.me.com. Where home.me.com is a dyndns to the freedombox. Dyndyns being unreliable, if a tent msg cannot get to my home server, then the messages are sent to cloud.me.com and then pushed to home.me.com when it comes back online (think POP mail).

The facebook killer then, is a hosted service like cloud.me.com for non-tech people, but a seamless transition to the hosted at home service as soon as you buy a freedombox. This way you have the best of both worlds. Your face in the cloud, and long term storage at home.

Other app wishlist: tent to smtp and smtp to tent adapters for gmail killing

Re: Introducing Tent - the decentralized social web

#28

Post by Torgo »

danielsiders wrote: post #20
pwf wrote: post #16

It seems like this will use up a crapton of bandwidth with its 'push' style notifications. If someone with a million Facebook followers makes a new post, one entry is made in the database and then users pull it down as they visit their own pages. If a million people decide to 'camp in my tent' (?), my server is suddenly pushing out gigs of data every time I make a post.

We anticipate follower counts similar to the levels seen on Twitter today. Managing 1 few hundred followers isn't too difficult, thousands can be managed by cranking up the dynos on heroku. But yeah, Justin Bieber is going to need a hosted solution to handle that kind of load (like he has now with Twitter, YouTube, etc). We also have a setting in subscriber settings that control which types of posts are pushed in the…

What about allow a publisher to delegate a subscription endpoint via something like pubsubhubub? Then publisher just has to push to the aggregator, everybody does their pulls from them.

Re: Introducing Tent - the decentralized social web

#29

Post by danielsiders »

mbreese wrote: post #19
Titanous wrote: post #13

Earlier quoted context omitted.

HTTP accomplishes all of our design constraints via REST and long-lived streaming connections. It is a very reliable, mature protocol, and the security and performance are very well understood. Also, if we invented a new binary protocol, users wouldn't be able to host their Tent servers on easy-to-use platforms like Heroku. Developers may implement other protocols in the future, but we are targeting HTTP as an access…

You wouldn't have to invent a new binary protocol, a simple text protocol can work wonders (see: memcached or Redis). I'd personally look more towards SMTP for inspiration (not security wise, of course). Since you're going to mainly be passing messages back and forth, not resources. You really should also think about two separate protocols... one server-to-server, the other server-to-client. At least, that's how I've…

Actually, we do support passing resources back and forth and for a lot of use cases doing so saves quite a few round trips in the long run.

Our protocol has two distinct parts, one server-server, the other server-app. It's just easier to manage a single "API" than having some support server-server but not server-app--we're hoping to avoid ecosystem fragmentation into those who don't want to support apps or vice versa.

Re: Introducing Tent - the decentralized social web

#30

Post by pwf »

danielsiders wrote: post #20
pwf wrote: post #16

It seems like this will use up a crapton of bandwidth with its 'push' style notifications. If someone with a million Facebook followers makes a new post, one entry is made in the database and then users pull it down as they visit their own pages. If a million people decide to 'camp in my tent' (?), my server is suddenly pushing out gigs of data every time I make a post.

We anticipate follower counts similar to the levels seen on Twitter today. Managing 1 few hundred followers isn't too difficult, thousands can be managed by cranking up the dynos on heroku. But yeah, Justin Bieber is going to need a hosted solution to handle that kind of load (like he has now with Twitter, YouTube, etc). We also have a setting in subscriber settings that control which types of posts are pushed in the…

What arguments do you have against a 'pull' style for notifications? Something like a GET to /latest that passes in the last time the client checked for updates and only gets back the URI of the last 10 or so posts since then. An HD video post could contain simply a URI that points to the video, so the video isn't even downloaded until the 'app' within tent asks for it.

This way you could have a path with all the videos on it that you could proxy off to a server with more bandwidth. It would get the user a lot more control over how their content is accessed.

Edit: And what if my server is down when one of my friends makes a post? Will I never see it?

Post reply on HN