What took you so long? I've been waiting for someone to finally get around to building this for a long time.
Appleseed, OneSocialWeb, StatusNet/OStatus, Disapora...
Introducing Tent - the decentralized social web
41–50 of 229 posts
Re: Introducing Tent - the decentralized social web
#42Why 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…
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 aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.
Re: Introducing Tent - the decentralized social web
#43We're building something like this for a while at Qbix.
It's not an easy problem to solve when it comes to privacy and security: http://www.faqs.org/patents/app/20120110469#b
Eventually to arrive at this: http://myownstream.com
Re: Introducing Tent - the decentralized social web
#44Earlier quoted context omitted.
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.
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."
Re: Introducing Tent - the decentralized social web
#45Awesome. I've wanted this forever, glad someone is finally picking up the ball and running with it. I'll be happy to beta test!
Re: Introducing Tent - the decentralized social web
#46Earlier quoted context omitted.
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 vid…
Pull-style requests actually use up quite a bit more bandwidth than push notifications, because every client and server has to query every few seconds instead of just getting notified when there is a new post. Posts have 'views', so a video or photo post would be pushed out with the 'meta' view which would include a URL to the content instead of the content inline.
I don't think so, considering that not all of my followers are going to be using the service all of the time. If the server just blindly downloaded everything always, then yes, it would be more bandwidth. But with proper caching strategies and servers only requesting new posts when clients are active, I think you could save a lot of bandwidth by not pushing everything.
Re: Introducing Tent - the decentralized social web
#47Website is down?
Re: Introducing Tent - the decentralized social web
#48Instead 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.
Re: Introducing Tent - the decentralized social web
#49Random thought: it might be helpful to give Tent-the-protocol a different name than Tent-the-server-implementation. In other words, "Tent" means either the protocol you're specifying, or the server software you're planning on releasing, but not both.
An analogue would be the naming distinction between HTTP, the protocol, and httpd, the first Web server (http://en.wikipedia.org/wiki/CERN_httpd). That naming split made it easier for people to understand what part of the system others were talking about, and helped make it clear that the two pieces were not tightly coupled to each other.
Maybe you're already planning on doing this when you release the server, it's not clear from the web site. If that's the case, feel free to ignore...
Re: Introducing Tent - the decentralized social web
#50Earlier 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."
Please this! There are so many [dropbox/facebook/twitter]-clones that claim to be different that reinvent things and use poorly designed in-house protocols and I eventually got so tired of them that I mostly ignore them now.