
Introducing Tent - the decentralized social web - Titanous
http://tent.io/blog/introducing-tent
======
gjulianm
My 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 with them. The most amazing thing is that, just using these
simple concepts the possibilities are infinite. As they said, every social
network out there can be implemented in this way. ¿Twitter? It's trivial, just
make the format description and you're ready. ¿Facebook? The only thing you
should specify is that the relationships are symmetric (you can follow me only
if I decide to follow you too, that is, we are mutual friends).

To me, the idea seems absolutely great. The problem will be execution: what
apps are created using this protocol. I have also the doubt if apps will be
interoperable. Example: I build a twitter-like app named Foo and another guy
builds another twitter-like app named Bar. Both use similar formats, so, can
an user using Foo see the contents posted with Bar? I imagine that this will
be possible as long as they share the same post format, but I'm not sure.

Anyways, good work. I would really like to see Tent to expand and grow.

~~~
Titanous
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.

~~~
coopdog
One issue I can see is that you only need to have one friend who uses a third
party tentd with questionable privacy policies and now everyone they're
connected to has their data exposed. Would it be possible to implement it such
that you can say 'yes, you can have this data, but only if your server is not
being run by 'blacklist' (would have to assume the requesting sever doesn't
lie about it's identity).

On the positive I can see this catching on because it's easy for existing
social networks to integrate, it would almost become do or die forever more if
a network that does integrate them catches on

~~~
axx
Maybe this could be done by a IP/DNS blacklist on your API side. So you
maintain a list on your "exit node" so that everyone who requests your data
needs to be "a good guy". If this part would be done by the requester it could
be spoofed easily, so it had to happen on the exit point.

------
enobrev
A few years back, I started getting interested in a similar idea. I'm
definitely intrigued in seeing how well it goes. Good luck to you.

Of course, as ideas go, I allowed myself to think further into the
possibilities, and found some interesting avenues.

For instance, why allow the facebooks, twitters, etc to own domain over our
content? Let people store their own data, and offer API endpoints giving
facebook, twitter, etc access. They essentially become frontends and search
engines to our shared content. We get control of our own data (and privacy
therein), they get to provide an interface to that data in a way that fits
what they're trying to offer their "customers".

And then if you take that even further, why allow anyone control over your
data? Why not store all my purchase data and credit info on my own servers,
and allow authorized companies access as needed? Census time? Popup shows up
on my phone asking if i'd like to allow the government access to some of my
data for census - I pick what data is allowed, and it's done.

Electric company's system automatically logs in to get my electric usage.
Phone provider does the same. Publishing a book literally allows access by
readers to your own servers. Releasing an album - same deal. We still have
"stores", but those stores are merely search engines offering a service to
both the content creators and consumers.

It went further, and weirder (in interesting ways). I'm not sure such a system
would truly be beneficial, but I love the idea of allowing people to Truly Own
their own data.

Apologies for the tangent. Good luck to you. I'm a fan of the idea as it's
presented and I hope you're successful.

~~~
lukifer
It's a great concept, but here's where it breaks down: once data is given out,
it can never be retracted. Whether it's an author's novel or a shopper's
purchase history, once the data is released to someone in a readable format,
they are unable to stop the recipient from doing something they don't like
with that data.

Granted, the issue can be mitigated with trust networks, social conventions,
or laws, but it comes down the same issues faced by DRM media formats: if
someone can consume the content, they can find a way to duplicate the content.

~~~
gizmo686
Just because you cannot prevent all threat models, does not mean you through
privacy out the window. For example, if Alice wants to send Bob a message, in
the current system: 1) Alice tells Facebook she wants to friend Bob 2)
Facebook tells Bob, who accepts 3) Alice sends Facebook the message addressed
to Bob (I think in plaintext) 4) Facebook sends the message to Bob. 5) The
message is still unencrypted on Facebook servers, where it is available to
Facebook, advertisers, hackers, and government agencies

Using known cryptographic methods, we can construct a system that works as
follows:

1) Alice looks up Bob's public key (or gets it from Bob to avoid needing a
trusted key service) 2) Using Bob's public key, Alice encrypts a message 3)
Alice sends the encrypted message into the network, addressed to Bob 4) Using
his private key, Bob decrypts the message

In the second example, the recipient (Bob) is the only one who can release the
data. In the first example, a number of potentially malicious parties have
access to the data without corporation from Alice or Bob.

I used a direct message for simplicity, but we do have crystallographic
methods to encrypt a message such that an arbitrary group of people can
decrypt it.

~~~
graue
> we do have crystallographic methods to encrypt a message such that an
> arbitrary group of people can decrypt it.

This doesn't solve the problem you're responding to: "once data is given out,
it can never be retracted". That remains the case. If you encrypt your photo
so that each of your 770 friends can decrypt it, but then you unfriend Bob for
being a jerk, he's still got the key and the encrypted data. So he still sees
that photo.

In contrast, although you could theoretically save every photo and update
anyone ever lets you see on Facebook, it would be difficult enough that in
practice no one does.

~~~
tripzilch
> "once data is given out, it can never be retracted". That remains the case.
> If you encrypt your photo so that each of your 770 friends can decrypt it,
> but then you unfriend Bob for being a jerk, he's still got the key and the
> encrypted data. So he still sees that photo.

That particular photo, yes. But Bob could also have saved that photo as soon
as he saw it or maybe he's got eidetic memory, so crypto can't help with that
anymore.

However, any new photos shared through the same channel can't be seen by Bob
anymore because I assume the key changes as the members of the access group
change.

Still, while you can't solve the original problem (Bob _can_ leak everything),
you can still do _slightly_ better than that by properly implementing Off-The-
Record messaging[1]. This adds perfect forward secrecy, as well as
deniability: The latter is very interesting because in OTR it means that
_both_ parties can authenticate received messages to be certain of the
sender's identity, but they can _also_ FORGE any message to look like it's
been signed by the other. This means that even if Bob decides to publish your
private messages to him, he can never _prove_ you were the one that wrote and
signed them, because he could have forged them himself.

Two problems with that: I'm not sure how the OTR protocol extends to multiple
recipients (but I bet there's some research on it), and while this
"deniability" might be enough for private (text) messages, it's not much use
for photographs in many cases: If Bob decides to publish an embarassing photo
of you that he had once access to, it's not going to be much use that you can
argue "ha, but you can't _prove_ I sent you that photo!".

Still, for textual communication, it adds a (thin) layer of extra security
even though you can never beat Eidetic Bob.

[1] <http://www.cypherpunks.ca/otr/index.php#docs> and in particular
<http://www.cypherpunks.ca/otr/otr-codecon.pdf>

~~~
graue
I addressed the "Bob could have saved that photo" point: "although you could
theoretically save every photo and update anyone ever lets you see on
Facebook, it would be difficult enough that in practice no one does." Facebook
has a sane default of _not_ saving everything that you view on your computer.
Yes, maybe someone saved one or two photos, but they probably don't have them
all.

OTR is pointless for a medium that's mostly about photo sharing. For the
Facebook use case, what's far more important than crypto is the set of social
norms the site establishes via what's easy to do (share) and what's hard,
e.g., archiving everything your friends share as it comes in. Not only would
that be tricky to do without getting detected as a bot, but 99.9% of users
would never think to try it. This problem is inherently more tractable with a
distributed system, and that could be bad.

------
smacktoward
Random 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...

~~~
danielsiders
Definitely-- The first "Tent server implementation" will have it's own name,
TBD. We spent a lot of time on nomenclature and still aren't 100% with any of
the terms, they're effectively all in flux until v1.0. The wackier issue is
whether users call their "Tent-servers" "Tents". If you have any suggestions
on names for this or any other terms, we'd love to hear them!

edit: when the hosted version launches it will be on a different domain, to
make clear tent.io is the protocol alone and we aren't monopolizing the
hosting space (we're doing it more as a community service than as a business).

~~~
rapind
A collection of Tents could be called a "Camp".

~~~
_sh
A cluster of camps, perhaps related to a specific topic, could be called a
'Jamboree'.

~~~
rapind
Jamboree sounds a little too campy.

------
mbreese
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
don't necessarily think that starting with HTTP is the way to go.

I don't have any particular argument with using JSON for data transfer
though... I think that is probably a good choice. Also using SSL for all
connections is probably a good call too.

~~~
Titanous
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 accessible starting point.

We are definitely anticipating heavy mobile use, both through mobile web apps
as well as native. There will eventually be iOS and Android frameworks to
handle all of the communication with Tent servers.

~~~
flatline3
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.

~~~
icebraining
HTTP implements an architectural style which ensures reliability, scalability,
decoupling of systems and support for hypermedia for a complex network of
disparate, unreliable systems and networks.

Do you have any suggestion that provides the same features, or should we forgo
them because HTTP is "hefty"?

~~~
flatline3
> _Do you have any suggestion that provides the same features_

Message passing.

That's all HTTP really is, but it's dressed up in a bunch of historical
complexity and inefficiency centered around supporting web browsers.

~~~
icebraining
But do you have any concrete suggestions of protocols, or are you criticizing
the choice based on an hypothetical protocol that would be very similar but
incompatible with HTTP and all its existing tools (millions of tested and
deployed caching servers, load balancers, etc), and for which whole new
libraries would have to be written, just so you can make it somewhat more
efficient?

~~~
flatline3
I think you're grossly over-estimating the difficulty of defining a protocol.
It's no more difficult than defining the protocol for which you'll use HTTP as
transport.

Load balancers know how to load balance straight TCP. HTTP caching servers are
an HTTP-centric idea.

The 'libraries' you'll need can be much, much smaller when all you need is a
bit of framing and serialization, instead of a complete complex RFC compliant
HTTP client stack.

~~~
icebraining
_I think you're grossly over-estimating the difficulty of defining a
protocol._

It's not writing the protocol that I find the most difficult. It's
reimplementing everything the uses the protocol.

 _Load balancers know how to load balance straight TCP._

Which is only useful if all the nodes are exactly the same, but that prevents
you from distributing the data across them based on the user profiles, and
then load balance according to the user id, as (if I'm not mistaken) Netflix
does. Since they're using subdomains as user identifiers, you'd get that for
free using an existing, well-tested HTTP load balancer.

 _HTTP caching servers are an HTTP-centric idea._

That's a tautology. The question is: are they a _useful_ idea? Is being able
to take advantage of existing and deployed solutions like CDNs useful? Seems
to me like it would be.

 _The 'libraries' you'll need can be much, much smaller when all you need is a
bit of framing and serialization, instead of a complete complex RFC compliant
HTTP client stack._

I think you underestimate the advantages that some of the core HTTP concepts
provide.

~~~
flatline3
> _Which is only useful if all the nodes are exactly the same, but that
> prevents you from distributing the data across them based on the user
> profiles, and then load balance according to the user id, as (if I'm not
> mistaken) Netflix does. Since they're using subdomains as user identifiers,
> you'd get that for free using an existing, well-tested HTTP load balancer._

I'm not sure what you think makes that complicated to implement without HTTP,
or why you consider it 'free'. Netflix had to write custom code to support
that, and could have just as easily done so on top of a message passing
architecture ala ZeroMQ or even AMQP.

> _That's a tautology. The question is: are they a useful idea? Is being able
> to take advantage of existing and deployed solutions like CDNs useful? Seems
> to me like it would be._

Not really, no -- neither a tautology nor are they particularly useful for API
implementation. Their primary value is in caching resources for HTTP requests
in a way that meshes well with the complexity of HTTP.

If you need geographically distributed _resource_ distribution than HTTP may
be a good idea simply because:

\- There's widespread standardized support for HTTP resource distribution.

\- Its inefficiencies are easily outweighed by the simple transit costs of a
large file transfer.

We're largely talking about server "API", however.

> _I think you underestimate the advantages that some of the core HTTP
> concepts provide._

No, the core concepts are more-or-less fine. It's the stack that's inefficient
and grossly complex, largely due to browser constraints and historical
limitations.

~~~
icebraining
_I'm not sure what you think makes that complicated to implement without HTTP,
or why you consider it 'free'. Netflix had to write custom code to support
that, and could have just as easily done so on top of a message passing
architecture ala ZeroMQ or even AMQP._

It's free because it already exists. Load balancers for hypothetical protocols
don't.

 _Not really, no -- neither a tautology nor are they particularly useful for
API implementation. Their primary value is in caching resources for HTTP
requests in a way that meshes well with the complexity of HTTP.

If you need geographically distributed resource distribution than HTTP may be
a good idea simply because:

\- There's widespread standardized support for HTTP resource distribution.

\- Its inefficiencies are easily outweighed by the simple transit costs of a
large file transfer.

We're largely talking about server "API", however._

Isn't the whole point of this system to transfer people's content - posts,
pictures, videos, etc - between servers? I would think pure API "calls" would
be a small part of the whole traffic.

 _No, the core concepts are more-or-less fine. It's the stack that's
inefficient and grossly complex, largely due to browser constraints and
historical limitations._

But to implement them, you need more than "a bit of framing and
serialization".

~~~
flatline3
> _But to implement them, you need more than "a bit of framing and
> serialization"._

I posit you're still __grossly __overestimating complexity based on your own
experience with HTTP, coupled with grossly _underestimating_ the complexity,
time costs, and efficiency costs of the stack HTTP weds you to.

A TCP stream is simple. It's as simple as it gets. Load balancing it requires
a few hundred lines of code, at a maximum. It only gets complicated when you
start layering on a protocol stack that is targeted at web browsers, grew over
the past 20 years, requires all sorts of hoop-jumping for efficiency (keep-
alive, websockets, long-polling), requires a slew of text parsing and escaping
(percent-escapes, URL encoding, base64 HTTP basic auth, OAuth, ...), cookies,
MIME parsing/encoding, so on and so forth.

All this complexity is targeted at web browsers, introduces significant
inefficiencies, and requires huge libraries to make it accessible to
application/server engineers.

What's the gain? Nothing other than familiarity, as evidenced by your belief
that the _core_ of what HTTP provides is so incredibly complicated, and you
couldn't possibly replace it.

No -- it's the complexity of HTTP that's complicated, not the concepts that
underly it. Drop the HTTP legacy and things get a heckuvalot simpler.

~~~
icebraining
It's not so much that you can't replace HTTP, as that you can't replace all
the thousands of tools and packages that already work with HTTP, and that can
be very useful for a project like this. And you can't easily replace the
knowledge that people have to HTTP either. (Claiming that OAuth is part of
HTTP doesn't help with your credibility either, I'm afraid.)

Furthermore, I think that even if the developers of this project could replace
the required tools and forgo the rest, I doubt it'd make sense.

Frankly, you'd need a working prototype to convince me of the contrary, so I
guess we'll have to leave it at that. I'm a stubborn man ;)

------
ivan_ah
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

~~~
danielsiders
hosted service within one month. email apps VERY high on our to do list, been
watching freedombox for a while, we'll reach out to them after initial
release.

~~~
jancborchardt
Since you mention Freedombox – did you also check out ownCloud as well as the
unhosted movement, with the remoteStorage protocol? There is a proof-of-
concept social network build on unhosted: <http://friendsunhosted.com>

Do you have an IRC channel? Feel free to also join our channel at #unhosted.
:)

------
Torgo
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 arise, as this type of thing is needed.

~~~
smacktoward
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.

~~~
danielsiders
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...](http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html#anchor4)
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).

~~~
smacktoward
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."

~~~
danielsiders
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.

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

~~~
danielsiders
There are a few "standard features" of centralized social networks that are
more challenging to implement, but we haven't found anything impossible yet.
Search, especially real-time requires an external search engine. But it means
Google (et al) needs to subscribe and essentially ask your permission for real
time updates. Friend search is a bit easier if your followers/people you're
following are public. Likely there'll be an app for that.

~~~
cyarvin
A couple of things I don't see on a quick scan of the docs:

(1) I don't see how one Tent entity contacts another proactively - it looks
like A can't message B unless B has already chosen to follow A. If this is so,
is it an anti-spam measure? Given that StatusNet etc. are infested with spam,
it seems like a very wise one :-) On the other hand, it is rather limiting as
compared to centralized platforms, don't you think?

(2) I don't see how you maintain the promise of a portable identity when your
identities are hosted URIs. Eg, if my identity is tent.is/foobar, and I want
to move to a different host, how do I do that? I can download my data, sure.
It looks like I can even bounce from tent.is to another data server. But
unless I want to break all my social connections, don't I remain at the mercy
of tent.is? This strikes me as a rather unsolvable problem, but it would be
reassuring to clarify that you're not solving it :-)

~~~
Titanous
1) This isn't clear in the docs right now, but unauthenticated notifications
are allowed, and eventually we'll add signing (think Domain Keys).

2) Every piece of data in the system will be available via the API including
negotiated app and follow credentials, moving will consist of authorizing an
importer app to have read access to everything, and then pushing a post that
tells all the servers to check the profile again for updated entity and server
details. It should be a very simple process.

~~~
cyarvin
(1) Have you thought about spam, then?

After all, there's a reason social services are centralized on today's
Internets. The reason (IMHO) is that the Internets since 1992 or so have been
an antisocial network, and anything worth attacking that lacks a centralized
defense command is rapidly overrun by digital Huns. For instance, SMTP exists
today because it existed before eternal September, and being valuable was
(barely) defended; but if it didn't exist as a legacy from the old, social
Internet, it would be very difficult to create it in the new antisocial one.
If not impossible.

I mean, it's certainly not that some of us rotting old neckbeards weren't
using finger and talk on the firewall-free Internet in 1989. So we know how
cool it would be if some bright young whippersnapper could solve teh
problem...

(2) This is useful but inevitably imperfect, as forcing every interlocutor to
equate the old and new names is of course impossible. Eg, HTTP redirects make
it possible to change your DNS identity - but hardly trivial, though the
redirect itself is trivial.

And of course it's a process that your existing host could easily frustrate,
though that would be very ill-mannered. Not saying there are any perfect
solutions here.

~~~
falien
(not associated in any way with tent.io)

1\. Just because it is allowed by the protocol doesn't mean any given client
needs to pay any attention. Just like email, I can filter out any messages
from people not in my contacts. I may choose not to and instead run each one
of those messages through a spam filter. In this respect it really seems no
different than email. Individual clients/servers can choose to be as strict as
they like (but servers are servers, and they are sitting on the internet, so
spammers can see them and send messages that will be ignored if they like).

2\. Since connections with most of your contacts are theoretically maintained
so you can push out new data, updating is more akin to propagating a new ip
through the DNS system than using a redirect. Yes a DNS server can misbehave,
but that can only screw up a network of well behaved servers for so long.

~~~
cyarvin
1\. People learned (grudgingly) to use spam filters with their email because
they had an existing service which had achieved large-scale network effect in
a spam-free environment. A new service which develops a spam problem before it
achieves critical mass is much more likely to be abandoned.

There must be some reason we haven't seen successful new decentralized service
protocols on the Internet since the early '90s. I don't know of a more obvious
one.

You can see the issues with StatusNet and spam:

<https://www.google.com/search?q=statusnet+spam>

2\. The problem is that contact names propagate outward from the master state
where a push will update them. For instance, they get written down on business
cards. They also get cached, imprudently but inevitably, in forms that are
still digital but don't update properly.

Imagine a protocol that you could use to update your email address this way,
and you'll see the problem. In theory, you could design a special SMTP message
that would cause all clients to update their address books. In reality this
would scale quite poorly and be quite unreliable, leading people to avoid it,
leading it to be even more unreliable, etc. Of course, your chances are much
better with a bright, shiny new protocol... but still.

~~~
eleventigers
RE 2. I agree since some servers that you are trying to push your new address
may already have changed theirs. What happens then? Do my friends inform me?
What if that unreachable server is not connected to my friends in any way?

------
yk
I wonder about the rationale to use HTTPS for everything, especially about the
SSL part. It seems that by the choice of SSL over a web of thrust (WOT [1])
approach one imports the problems of certificates and CAs into the protocol.
Especially it would be possible for a server with a root CA to impersonate
other people. On the other hand, a social network is about social relations,
which could also directly serve to sign and validate public keys in a WOT.
This could then serve as a authentication against the same social network that
is stored. For example a chat software could show Alice that the person she is
chatting with is indeed Charly, the friend of Bob ( Bob signed Charlies key).

[1] <https://en.wikipedia.org/wiki/Web_of_trust>

------
SCdF
I'm damn excited about this. I've been mulling this concept over in the last
couple of years, because I really we need something post-blogs that isn't the
walled garden facebook / twitter / G+ / et al model.

For the me the ultimate social network would be just blogs, RSS and a feed
reader, with people either managing the blog themselves or using a third party
to do it for them-- the point is it doesn't matter.

The problem is that blogging is complicated, anything with multiple options is
complicated, and discovery is complicated. I know where to look to find a
friend on facebook, I don't know where to look to find his blog.

I don't have time right now (work) to look into Tent in more detail, but it
sounds like it's a definite step in the right direction.

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

~~~
danielsiders
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 their entirety to different followers vs just a
notification being sent vs nothing at all. So blog entries and status updates
might get pushed to all 1M, but you probably wouldn't push an HD video update
to all of them without some more serious server architecture.

~~~
pwf
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?

~~~
Titanous
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.

~~~
pwf
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.

------
kennywinker
This is the Twitter replacement gotham needs.

Repo starred, eagerly awaiting runnable stuff.

------
mgualt
I would be interested to read a 'big-picture' description of what Tent is.
Forgetting for the moment how it compares with competitors, what is the idea?
I read the introduction but I feel that I don't understand it.

From what I can tell, the idea is to create a standard set of objects and
rules for interacting with these objects. Of course that is how protocols tend
to look.

What are some of the new objects/concepts proposed by Tent? For example, is
there a distinction between "home" and "users" akin to server/client? Are
there several types of messages, compared to email? Is there a standard
cookie-like object? What is the conceptual model for sharing? Any insight
would be appreciated.

------
jasonkolb
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!

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

------
teeeler
"His server sends a notification to every server following him or mentioned in
the post with permission to see the post."

The protocol seems to have some fundamental limitations.

For my money I'd rather go with FETHR (see <http://dsandler.org/brdfdr/> and
this paper: <http://dsandler.org/brdfdr/doc/iptps-fethr/>) and its
implementation - which has code available right now
(<https://bitbucket.org/dsandler/brdfdr/>).

~~~
foobarqux
Too bad that project never caught on, it seems really interesting and useful.

------
sidcool
"Tent servers can also be run as Tor hidden services to create a social
darknet for at-risk organizers and activists."

~~~
mcantelon
So can anything, but it's awesome that they are promoting this. Speaking of
which, does anyone know if there's a hidden service Twitter clone? This would
be fun.

~~~
robertfw
TorStatusNet: <http://lotjbov3gzzf23hc.onion.to/>

~~~
mcantelon
Rad... thank you!

------
pacala
Thanks guys. Not a moment too soon. Humbly quoting the motivation:

> What is wrong with other social services? Centralized Social Service
> Providers limit what you can share and who you can share with. They only
> allow users to interact with other users on the same network. Because their
> products are centralized and maintained by a company, users are left in the
> cold when the company changes its products or shuts down. There's nothing
> wrong with a company offering users social services. But users shouldn't be
> limited by those companies. Imagine if you could only email other customers
> of your Internet Service Provider. Unfortunately Centralized Social Service
> Providers have done just that. You can only communicate directly with other
> users of their closed network.

> If you don't like a bank you can withdraw your money and deposit it
> somewhere else, including your own home. You could even start a new bank
> where you and your friends felt safe. You can still pay your bills and
> maintain your financial relationships, just tell them about your new
> account. We aren't talking about money. Your data is far more valuable– your
> family and friends' photos, locations, and private communications. You
> should be able to store them somewhere you trust, move them when you want,
> control who can and can't see them.

------
EGreg
We'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>

~~~
webwanderings
Looks ambitious in liberating the user and their data, but it seems you've
taken too long and have stumbled upon substantive problems on your own. The
screenshot of the platform seems old fashioned, but eventually by liberating
the user/data, you are making them stand on their own island, hence there will
be no "networking" or connections in the true sense, as it is currently
happening on a single platform like Facebook or Twitter. By attempting to set
the data and user free in such manner and by eliminating the single and
cohesive platform, we risk excluding ourselves out.

~~~
EGreg
What do you mean

------
mratzloff
What took you so long? I've been waiting for someone to finally get around to
building this for a long time.

~~~
wmf
Appleseed, OneSocialWeb, StatusNet/OStatus, Disapora...

------
khet
"How is Tent licensed? Tent will be completely free and open and treated as a
standard. To prevent fragmentation before launch, the original authors
currently retain copyright. This is a temporary situation which will be
remedied immediately after a governance model is chosen. We decided it would
be best to share what we could as soon as possible, releasing early and often.
We are entirely committed to free and open software and protocols with open
governance models leading to a ratified standard. Tent will be released under
an open license in the immediate future."

I am curious as to how retaining copyright will help them prevent
fragmentation? Can they not elect themselves as project leaders of the
opensource project and prevent fragmentation?

~~~
morsch
Retaining copyright means that you can't fork their code to easily establish a
working but slightly incompatible version, which is what fragmentation is.

Project leader is not a formalized position (or even a meaningful concept,
really) in free software and doesn't come with the power to prevent forks or
fragmentation. I guess their thinking is once a community of users and
developers is brought together, they can be trusted to establish a model that
retains compatibility since it is in everybody's interest. While at the
moment, an incompatible fork would have the same "network effect" as the
original.

Either way, the copyright only covers the software, not the protocol.

~~~
SoftwareMaven
Retaining copyright isn't what matters. The license they choose on the
copyright they (naturally) retain does.

It is possible that they could craft a license such that protocol-incompatible
changes are not allowed, but I don't think that would be in their best
interest. This is a starting point. The risk isn't fragmentation, it's
crickets (ie nobody cares) and an untested protocol that may need multiple
versions to get right.

------
darkhorn
PHP support is vital.

~~~
zerostar07
really

------
biomechanica
I like how they support Tor hidden services. Though I wish they would go a
step further and support I2P.

It's really nice to see people are working on ways to sort of "replace" the
current centralized services out there.

Let us hope they are attractive enough to developers and users.

------
mike-cardwell
Sounds almost too good to be true. Looking forward to being able to download
some software.

~~~
knowtheory
They've got a github repo they're working out of it looks like:

<https://github.com/tent/tent.io>

~~~
spolu
Argghhh. Ruby.

~~~
danielsiders
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.

~~~
darkhorn
Okay but there are more PHP users out there. If you had one PHP server I would
start to run it right now. My (and many others) shared hostings do not provide
Ruby, Java, C++ support.

------
tagawa
But how does this differ to StatusNet/OStatus? If we have several similar
solutions to a problem it makes it more difficult for one to gain traction.
Seems like reinventing the wheel, or am I missing something?

------
dj2stein9
I hope this crew is looking at WebRTC. The true killer app for a distributed
social network is going to be a global decentalized video chat network.
Imagine Google hangouts without Google. Even just to implement a voice-only
chat without a centralized system would be pretty phenomenal.

Also, I really think they're making a mistake by not using secure Websockets
for their protocol. Plain HTTP has too much overhead for what needs to be an
efficient messaging protocol and the potential need for persistent
connections.

------
Meldryn
How does this compare with Diaspora?

~~~
danielsiders
Diaspora* is a federated open source social network. It does not have a
protocol specification or an API for app support/integration. Diaspora* is not
intended to be run as one server/user, but by clustering users on pods with
pod administrators, etc.

~~~
Meldryn
Reading the API docs, it seems that every user needs their own URI to be
uniquely identified. I wonder how this will work with the average user, just
IP address? What about users with shared internet?

~~~
danielsiders
You're correct-- we anticipate users either registering their own domains
(i.e. <http://danielsiders.com>) or using a hosted service that provides
subdomains (<http://danielsiders.tent.io>). If you're hosting at home (dream
solution here is plug computers), then dynamic DNS pointing to your home
IP/computer.

~~~
kevingranade
PageKite (pagekite.net) is another solution for self-hosted from a household.
_plug_

------
kindalu
I'm thinking about every smart phone as a tent server.

P2P camping site will establish when you are waiting the bus, taking the
boring meeting, or camping at the river bank. I tried to use wifi-
direct/bluetooth, but I found iPhone and Android system set device default to
non-discoverable for security issue. But I do found a lot of Nokia/LG phone in
discoverable mode on subway.

I hope the tent will be successful. Be an application to make strangers
knowing each other and people to go outdoor.

------
alistairbayley
How does this compare to Mr Social? :
<http://mobisocial.stanford.edu/papers/mrprivacy.pdf>

------
victorNicollet
I believe this is a great idea, but I disagree with some points of your
implementation. I actually started writing a lengthy comment about this, and
after about two hours of writing I decided it might look better as a blog
post, so there you go:

[http://www.nicollet.net/2012/08/tent-the-right-goals-the-
wro...](http://www.nicollet.net/2012/08/tent-the-right-goals-the-wrong-
perspective/)

~~~
mgualt
I find your post interesting, and it goes some way to answering my own
questions. However, your post is based on the premise

"There are four issues with decentralized, large-scale sharing of content
between non-technical people..."

and you claim those four issues are 1\. Identity Persistence 2\. Data
Persistence 3\. Publishing 4\. Access Restrictions

I do not see why this is so. But even if it is, it is not even clear if the
main point, at this stage, is to identify the atomic components of the "social
web" -- perhaps what is sought after now is a slightly higher-level conceptual
framework which puts these together.

For example, "publishing" may be missing the point - perhaps we need a finer
grained concept: different kinds of collaboration, delegation of authority,
distribution of tasks, self-communication, electronic cloud prayer...

------
adrianbg
This 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?

~~~
Titanous
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...](http://liberationtech.tumblr.com/post/13377461578/how-the-next-
generation-diaspora-should-be-built-to)

~~~
bct
I don't mean this in a cruel way (I'd really like this to succeed), but that's
a list of features, not a plan for getting adoption.

Figuring out how to bootstrap network effects is critical.

~~~
danielsiders
You're right-- Our plan is to get the protocol and reference server
functioning for general use. We're mindful of the notes made here:
[http://liberationtech.tumblr.com/post/13377461578/how-the-
ne...](http://liberationtech.tumblr.com/post/13377461578/how-the-next-
generation-diaspora-should-be-built-to). We have some thoughts on adoption
tactics and strategy, but the master plan is still under development. All
insights are welcome.

edit: wow, wrong link.

~~~
adrianbg
Twitter and LinkedIn are successful in distinct niches from Facebook.
Companies and privacy-conscious people apart from activists (Germans?) may
also be interested in a social network that lets them own their information.

------
BerislavLopac
In my opinion, there isn't much point in decentralizing servers -- it's been
tried and failed a number of times. What we need is decentralized _clients_ ,
e.g. a true P2P social network. Essentially, imagine that your contacts app
could exchange messages over the Internet directly with any -- or all, or any
combination -- of the contacts stored within.

------
chanux
Where's the donate button when I really need it?

------
ojr
"Not Invented Here" syndrome is manifested as an unwillingness to adopt an
idea or product because it originates from another culture - Wikipedia

The culture of decentralized web doesn't bode well, not enough capitalism,
which might in turn effect the quality of the product.

------
lucaspiller
If anyone is looking to get involved I have (unoffically) started a project to
write a testsuite against the protocol. Contributions would be appreciated.

<https://github.com/lucaspiller/tent-testsuite>

------
hammock
> Tent is specifically designed to be usable by high-risk activists and people
> in countries that block other social networks.

I can't help but read that and think, "terrorists." Then again, there will
always be that tradeoff and you are probably on the right side.

~~~
mratzloff
Osama denied my friend request! :-( (Sad terrorist)

------
liotier
> OStatus [..] stopped short of actual decentralization.

How so ? It looks quite decentralized to me.

------
eschulte
Why not use the OpenPGP standard? PGP public and private keys seem to be the
natural solution for both,

1\. signing data so that the source can be verrified

2\. encrypting messages so that they can only be read by particular recipients

------
maked00
To a normal person, this article is just a collection of fuzzy well meaning
ideas wrapped around a bunch of technical network jaron. The fact that there
is no working demo is rather damming.

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

~~~
icebraining
I think both are unfortunate, since it ties your identity to your current
provider. I'd much rather see a truly decoupled system, even if it didn't
provide a "friendly" user id, but only an hidden fingerprint. People can just
search for name and other data anyway.

------
EternalFury
Friendica does that already. No one cares. Potato chips are potato chips. No
one cares about the brand, but everyone loves them, even though they are not
free.

------
eps
Who's behind Tent, does anyone know?

I can swear I saw a section with names on the site, but can't seem to find it
now. It looks like it was taken out.

------
aj
How is the different from identi.ca? Isn't this pretty much what their premise
is/was? (ignoring implementation differences)

------
darkhorn
<http://en.wikipedia.org/wiki/Tent_(protocol)>

------
ricardobeat
Who is building this? Who designed the protocol, and will publish/veto the
standard?

------
zoowar
What happens when my server is down when you try to post a notification?

~~~
bct
From the docs:

"If the app does not respond with 2XX, then the server should try again
later."

"Shirley has her client in maintenence mode; jerrold.me will attempt to
deliver the notification later using an exponential backoff algorithm."

------
mxuribe
I'm digging this!

------
mparlane
Please make more social networks.

~~~
lwat
Every day I wake up and I think 'If only we had more social networks!'

------
nikunjk
Website is down?

------
webwanderings
"Every user decide which other users can follow them and what information will
be shared with each of their followers."

This effectively makes each person an island in h/herself and hence the model
of social-web breaks down. It wouldn't work and people know it.

In order to liberate the data, you're throwing the baby out with the bath
water.

~~~
arscan
I'm not following your rationale. Isn't that Facebook's default model? I
explicitly choose who is allowed to see my content, and I have control over
how much of that content they can see through privacy settings / lists. The
problem with Facebook is that I simply don't trust them with my data.

~~~
webwanderings
Yes, that's correct, hence Facebook's user feed is not really based on, or
helping, the social-web part of the user's life. The user feed or stream is
there as an advertisement, a selling product, for the product and services to
advertise to (it is sort of a loop, isn't it - you are selling yourself to the
one who is also selling to you).

The real social-web aspect of the Facebook is in their Groups, or Pages, where
users collaborate, converge "together" on a single entity (of any particular
Group or Page).

Do you follow my logic now?

I am against the idea of making users standing independent on their own
because they then become an island in themselves. It is fine if you are making
them a product, a brand, or portfolio, but none of this is helpful for the
authentic social-interaction. You don't need a brand or portfolio to be
social, that's not its original purpose. The original purpose of the user
(individual human being) is to communicate, be social, create communities.

