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

61–70 of 229 posts

Re: Introducing Tent - the decentralized social web

#61

Post by danielsiders »

spolu wrote: post #56
knowtheory wrote: post #5

Earlier quoted context omitted.

They've got a github repo they're working out of it looks like: https://github.com/tent/tent.io

Argghhh. Ruby.

Only the site generator is in Ruby. While most of our core team are Rubyists, someone is working on a C++ implementation, too. It's a protocol which means you can write an implementation in any language you want. We hope to see many server implementations with different optimal use cases in different languages.

For libraries, Ruby and Javascript are our top priorities with Java and Obj-C/iOS to follow. We'd love help if there are other languages you'd like to write libs for.

Re: Introducing Tent - the decentralized social web

#62

Post by danielsiders »

smacktoward wrote: post #44
danielsiders wrote: post #34

Earlier quoted context omitted.

We take NIH very seriously and originally began by attempting to revise existing protocols. We have some very specific complaints about existing federated web protocols: • no support for private message (pubsubhubbub, anything atom-based) • inability to move relationships when changing service • no standard API for application interaction by leaving each of these (and others) out of scope see: http://ostatus.org/site…

This is valuable -- I'd recommend adding a page to your site that includes these types of critiques, it'd be useful for those working on or around those other protocols. And it'd give people who are interested in your work a URL they could send around when asked "why not just use salmon/webfinger/ostatus/whatever."

Thanks, that's a good note. We didn't want it to seem like we were attacking the other protocols (all of which have had success, have clear use cases, and we owe some debt to for paving the way), but we should make our reasoning clearer to the community. Will do.

Re: Introducing Tent - the decentralized social web

#63

Post by TazeTSchnitzel »

flatline3 wrote: post #42
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…

HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that…

WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)

Re: Introducing Tent - the decentralized social web

#65

Post by TazeTSchnitzel »

flatline3 wrote: post #40
mmahemoff wrote: post #37

Earlier quoted context omitted.

I upvoted this as it's good to question the assumption and it's easy to imagine this working better without HTTP. In practice though, I feel the project is orders of magnitude more likely if it's built with HTTP and REST. A social product needs to reach critical mass and any hurdles you're putting in front of users and developers need to be seriously justified. In this case, workarounds like cookies are Good Enough.

I'd argue that -- for native client authors -- HTTP and REST are actually larger barriers than a simple non-HTTP protocol. I also don't understand the concern over "inventing" a new binary protocol. It's not like it's any more complicated or difficult than "inventing" a non-binary protocol. The framing rules just don't use ASCII/UTF-8 field delimiters. There are plenty of existing encodings to use, no more difficult…

Only if you're using C/C++ and only native OS libraries (or on windows, afraid to use WinHttp for fear of lack of SP1 support)

Re: Introducing Tent - the decentralized social web

#66

Post by zoowar »

rshm wrote: post #48

Instead of sub domain, email address would have been a better choice. user@provider.tld Where provider.tld provides specification/api.. like robot.txt/tent.json that would specify actual api endpoints for given user.

This exists, The Discovery Protocol Stack http://hueniverse.com/2009/11/the-discovery-protocol-stack-r...

Re: Introducing Tent - the decentralized social web

#67

Post by danielsiders »

jasonkolb wrote: post #45

Awesome. I've wanted this forever, glad someone is finally picking up the ball and running with it. I'll be happy to beta test!

How do you feel about alpha? please join the mailing list (on the bottom of http://tent.io) so we can let you know

Re: Introducing Tent - the decentralized social web

#68

Post by arscan »

This looks great guys. I'll definitely put up a server and hook up the content I traditionally expose through my personal website.

Question: what features that are taken for granted on today's popular social networks are difficult/impossible in this kind of distributed system? for example, i suspect something like "friend suggestions" might be difficult, since you only have access to a part of the network. Auto-friend tagging in pictures would be tough too. I'm seeing a lot of upsides listed, but there must be some things you just can't do. A candid discussion of the drawbacks would be helpful.

Re: Introducing Tent - the decentralized social web

#69

Post by kevingranade »

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.

Status.net/OStatus uses a similar PUSH model, basically it scales with number of followers, and yes, if you have thousands of followers the load will be significant. As a data point, I've been running a status.net instance since last December, during which time I've had 50-80* followers, have made an average of 12 posts/day, have followed 100-190* others, and my instance has transferred a grand total of 10,279MB * over that entire period.

followers and followeds gradually increased over the duration. I have this number handy since the connection is reverse-proxied via pagekite.net, which is metered. Over the last few months, I've had all static content offloaded to another server, which reduced the bandwith used, I'm not sure by how much.

Re: Introducing Tent - the decentralized social web

#70

Post by flatline3 »

TazeTSchnitzel wrote: post #63
flatline3 wrote: post #42

Earlier quoted context omitted.

HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that…

WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)

Corporate firewalls are the general boogieman, but in reality, I haven't seen evidence that they're much more than that.

To test this, we implemented fallback-to-HTTPS behavior in a very widely used previously non-HTTP client. We then observed the number of clients that failed to connect via our custom protocol, but succeeded in falling back to HTTPS.

The numbers were negligible.

It's ridiculous that we'd seriously believe that we can't trust that TCP works on the internet. We joke about it being the "interweb", but I see no reason to sow fear, uncertainty, and doubt, and thus and actually turn the interweb into reality.

Post reply on HN