Live data from Hacker News

Introducing Tent - the decentralized social web

tent.io

181–190 of 229 posts

Re: Introducing Tent - the decentralized social web

#181

Earlier quoted context omitted.

Maybe anything that requires knowledge of the whole network would be pretty difficult. For example, showing the full list of the photos that are being posted. You can't just follow every user that posts photos. The best solution that comes to mind now is building a server with a database of all the users and their respective servers. But, of course, that would break the decentralized purpose of Tent. It's an interest…

A DNS requires people to agree about who owns a certain identifier, which would be problematic in a decentralized system (though there are proposals like namecoin). I think a better system could be publishing a triple (name, keyfingerprint, current-server) on a shared datastore (e.g. DHT). The user doing the search would still need to find some out-of-protocol way to identify the right person, though. EDIT: Kadmelia…

Yes. The "keyfingerprint" might be the server's public key for purposes of end-to-end security of the connection. (No more SSL! There's better libraries now.)

cjdns has a simple approach: your tcp6 address is your public key. This the right idea. Leverage what you already have that is unique (not to imply IP address is necessarily truly unique, e.g., anycast).

But in general to be on the network, you have to at least one unique item: your network address. So leverage that to make other unique identifiers.

To encrypt communications, you may need to maintin encryption keys. So leverage them to be part of each peer's unique identifier on the network.

Connecting to strangers, and only using the network to get each and every bit of infromation from the outside world, is all fine and good, but this sort of peer-to-peer networking is much more valuable with peers who you can identify in person. Without using a computer. You can exchange all the above numbers (identifiers) on business cards.

Re: Introducing Tent - the decentralized social web

#182

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

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

Re: Introducing Tent - the decentralized social web

#184
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…

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…

[deleted]

Re: Introducing Tent - the decentralized social web

#185

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…

Kind of a usability-meets-marketing problem. The good thing is that the word "tent" is a versatile one – maybe the server could become "Tentpole" or something along those lines.

Hey, I thought of tentpole too (that's what's getting the tent up and running).

Re: Introducing Tent - the decentralized social web

#186

Earlier quoted context omitted.

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?

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

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.

Re: Introducing Tent - the decentralized social web

#187
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/

Re: Introducing Tent - the decentralized social web

#188

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

Maybe you should get in touch with the OpenSocial movement: http://www.opensocial.org/

Combine forces.

Re: Introducing Tent - the decentralized social web

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

Well, in a decentralized social network you'd have to make sure the tentpole you are living under is able to hold the weight.

This is decentralized. In my expectation this network is not about a few celebs having millions of followers. I'd love to see it become peer to peer on the human level. Friends who are actually real friends, or at least people you have met and have had a real human interaction with.

Re: Introducing Tent - the decentralized social web

#190

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…

I think you should call your server TBD and then make up what it stands for :) It's harder than I thought, but the "T" is obviously Tent ..
Post reply on HN