What took you so long? I've been waiting for someone to finally get around to building this for a long time.
Introducing Tent - the decentralized social web
31–40 of 229 posts
Re: Introducing Tent - the decentralized social web
#32It 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.
Posts have different "views" one of which is meta which would just have a URL pointing to the photo instead of including it in the post. See: http://tent.io/docs/post-types
Re: Introducing Tent - the decentralized social web
#33Earlier quoted context omitted.
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 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.
Re: Introducing Tent - the decentralized social web
#34I 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.
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/sites/default/files/ostatus-1.0-draft-2-s... they have created an ecosystem unfriendly to developers (who have to approach each provider separately to work out auth schemes and APIs) and likely to lead to vendor lock-in (because relationships can't be transferred and basic features are implemented differently in each system).
Re: Introducing Tent - the decentralized social web
#35"Tent servers can also be run as Tor hidden services to create a social darknet for at-risk organizers and activists."
Re: Introducing Tent - the decentralized social web
#36My first thought was "Well, Diaspora with another name". But after reading and understanding it (it's not very well explained there) seems like a much more abstract thing. They want to build an abstraction layer to the social web, not a social network. The idea seems pretty good. It's just the basics: you follow people and receive their content (text, images, whatever), and people follow you and you share content wit…
We are putting together a wiki-style solution for community-curated post types. Common types are expected to be standardized so that apps are interoperable. For example status/microblog would be a standardized post type. We will launch with common types specified, so that everyone doesn't reinvent the wheel. After that, community managers will help keep the devs in line.
It sounds like a very nice idea. I'm putting together a "multi-protocol social client". I'd love to be able to use Tent. I am correct in assuming there isn't currently a reference implementation?
Re: Introducing Tent - the decentralized social web
#37Why 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…
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.
Re: Introducing Tent - the decentralized social web
#38This looks really neat. How are you going to get people to start using it? Anything more active than hoping that an app/user ecosystem develops?
We are starting with an easy-to-use hosted service that will launch in a few weeks. We are catering to the development community by offering a simple, standardized API that will be easy to use. Privacy is a first-class feature, and Tent is specifically designed to be usable by high-risk activists[1] and people in countries that block other social networks.
[1] http://liberationtech.tumblr.com/post/13377461578/how-the-ne...
Re: Introducing Tent - the decentralized social web
#39Earlier quoted context omitted.
We are putting together a wiki-style solution for community-curated post types. Common types are expected to be standardized so that apps are interoperable. For example status/microblog would be a standardized post type. We will launch with common types specified, so that everyone doesn't reinvent the wheel. After that, community managers will help keep the devs in line.
It sounds like a very nice idea. I'm putting together a "multi-protocol social client". I'd love to be able to use Tent. I am correct in assuming there isn't currently a reference implementation?
There is currently no reference implementation, but it will be on Github within a week or so.
Re: Introducing Tent - the decentralized social web
#40Why 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…
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 than JSON.