Introducing Tent - the decentralized social web • Hacker News Board

Re: Introducing Tent - the decentralized social web

#211

Post by flatline3 » Thu, Aug 23, 2012, 3:50 PM UTC

icebraining wrote: post #209

flatline3 wrote: post #208

Earlier quoted context omitted.

> 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 i…

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…

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

Re: Introducing Tent - the decentralized social web

#212

Post by evanprodromou » Thu, Aug 23, 2012, 4:16 PM UTC

danielsiders wrote: post #34

smacktoward wrote: post #26

Earlier 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…

Hey, so, I'm one of the co-authors of OStatus.

First, welcome to the community of people working on this important problem. I highly recommend you join this group to stay informed about what's going on elsewhere:

http://www.w3.org/community/fedsocweb/

It's an "issue" group, not dedicated to any one protocol, service, or software package. Please, make sure you're a part of it!

A couple of notes:

1. We're working on including private messages in PubSubHubbub 0.4 and thus into the next version of OStatus. Understood that it's a big deal.

2. You're right, there's no standard API. ActivityPub is an attempt at that; see here: http://www.w3.org/community/activitypub/

Thanks for considering. Let's make sure we interoperate!

Re: Introducing Tent - the decentralized social web

#213

Post by nacker » Thu, Aug 23, 2012, 4:27 PM UTC

danielsiders wrote: post #55

smacktoward wrote: post #49

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 ma…

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…

Cool stuff! I like that you mentioned mesh compatibility.

Yurt, Caravan, Convoy?

Re: Introducing Tent - the decentralized social web

#214

Post by icebraining » Thu, Aug 23, 2012, 5:22 PM UTC

flatline3 wrote: post #211

icebraining wrote: post #209

Earlier quoted context omitted.

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…

> 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 on…

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 ;)

Re: Introducing Tent - the decentralized social web

#215

Post by mcantelon » Thu, Aug 23, 2012, 5:46 PM UTC

robertfw wrote: post #74

mcantelon wrote: post #51

Earlier quoted context omitted.

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.

TorStatusNet: http://lotjbov3gzzf23hc.onion.to/

Rad... thank you!

Re: Introducing Tent - the decentralized social web

#216

Post by BerislavLopac » Thu, Aug 23, 2012, 6:29 PM UTC

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.

Re: Introducing Tent - the decentralized social web

#217

Post by jancborchardt » Thu, Aug 23, 2012, 7:09 PM UTC

jsilence wrote: post #187

enobrev wrote: post #97

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, twitte…

" Let people store their own data, and offer API endpoints giving facebook, twitter, etc access." That is the goal of unhosted. http://unhosted.org/ I really whish their RemoteStorage protocol would gain traction. The locker project is heading into the same direction, although with a different approach. Posting content to Facebook et al and then recollecting it into your locker. http://www.lockerproject.org/

Thank you for the shout-out! :) There also is an unhosted social network now, check it out at http://friendsunhosted.com (my username is jan@5apps.com, feel free to add me)

Re: Introducing Tent - the decentralized social web

#218

Post by eschulte » Thu, Aug 23, 2012, 7:41 PM UTC

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

Re: Introducing Tent - the decentralized social web

#219

Post by graue » Thu, Aug 23, 2012, 7:46 PM UTC

gizmo686 wrote: post #148

lukifer wrote: post #132

Earlier quoted context omitted.

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 d…

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…

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

Re: Introducing Tent - the decentralized social web

#220

Post by gizmo686 » Thu, Aug 23, 2012, 8:47 PM UTC

cturner wrote: post #206

gizmo686 wrote: post #149

Earlier quoted context omitted.

Who says port 80 has to be http?

I think 443 will be a better example because (I think) it's harder for a middle party to profile https and see that it is indeed https and not something else.

I don't think so, even with https, you still have the handshake which middle parties can see.