Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Tent - the decentralized social web

tent.io

Post reply on HN
Print view View original

161–170 of 229 posts

Re: Introducing Tent - the decentralized social web

#161

Post by jancborchardt »

danielsiders wrote: post #71
ivansavz wrote: post #27

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

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.

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

Re: Introducing Tent - the decentralized social web

#162

Post by e12e »

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…

Just FYI: With facebook now (for quite some time) integrating/implementing Jabber/XMPP -- OTR (Off the record messaging) works fine with facebook messages right now, if both users connect to facebook chat with something like Pidgin.

I guess the deniability part is sort of out the window, seeing as how facebook will be logging the traffic pattern(s) -- but you might at least claim that "no, that wasn't what I said".

Re: Introducing Tent - the decentralized social web

#163

Post by e12e »

Titanous wrote: post #17
gjulianm wrote: post #12

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.

You might want to have a look at federated wiki for this:

http://wardcunningham.github.com/

Re: Introducing Tent - the decentralized social web

#164

Post by cyarvin »

falien wrote: post #141
cyarvin wrote: post #126

Earlier quoted context omitted.

(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 (ba…

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

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.

Re: Introducing Tent - the decentralized social web

#165

Post by flatline3 »

cdcarter wrote: post #145
ynniv wrote: post #91

Earlier quoted context omitted.

Port numbers are not protocols.

Yes, but many open wifi hotspots at commercial institutions only have 80 and 443 open.

I believe his point is that you can generally carry whatever protocol you want over port 443 (and often port 80).

Given how many other things are broken by networks that foolishly only open port 80 and 443, and their (in my experience) relative rarity, I'd suggest that it's not worth bothering with, except possibly as a fall-back to measure the actual number of people trying to use your service behind such a network.

Re: Introducing Tent - the decentralized social web

#166

Post by e12e »

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…

I've yet to go read the op page -- but:

  * for messaging why would you not use xmpp and/or smtp?
As for using http -- I'd say http makes good sense for getting, sending and receiving documents -- like text and images. It makes it fairly easy to implement a REST-like architecture.

As for things that have been tried before, we have ping backs -- that IMNHO never really worked. And there's Diaspora that have yet to come up with a stable protocol -- and have an implementation that is pretty badly broken.

It's also a good illustration of going the "full http" route: publishing becomes easy; interaction (server to server) becomes hard if you want to have any kind of security in place.

Re: Introducing Tent - the decentralized social web

#167

Post by e12e »

danielsiders wrote: post #24
Torgo wrote: post #18

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

We considered the protocols you're mentioning. There are a few huge problems for our use cases: PSH is built on Atom which means all feeds are public. That's fine for your public feed ala Twitter, but unacceptable for private messages. We also think it's critical for users to be able to take their relationships with them when they move to another server/provider. OStatus and PSH don't make that possible. They also do…

How does using atom make things public? Just use client certs over https -- and it's as private and secure as anything over http(s) ever is?

Alice gets her updates from Bob via something like:

.rss" rel="nofollow">https://bob.example.com/private/alice/.rss

You'd of course need to synchronize access passwords/keys/tokens somehow -- but that could be part of "friending" someone?

Integrate with something like cacert.org so you don't have to manage certs (as part of this project). A friend request includes the requesters cert (could be self signed, or via a trusted authority, like cacert), encrypted with the public cert of whomever the request is sent to.

When a friendship is accepted on the other end, store the cert, and use that for authentication. Add your own authorization rules (Alice is a close friend).

It might be a benefit to set it up as follows: everyone has a personal cert. They generate and sign a proxy cert for their tent server. The public "top" cert is used for user management and federation -- numerous such "downstream" certs could be generated, along with revocation certs.

Re: Introducing Tent - the decentralized social web

#168

Post by notatoad »

mbreese wrote: post #7

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…

Http gets let through firewalls. Other protocols don't.

Re: Introducing Tent - the decentralized social web

#169

Post by fpgeek »

danielsiders wrote: post #79
arscan wrote: post #68

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

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…

Oh, that's beautiful. The minute you get any nontrivial amount of data flowing, Google et al will want to crawl/index/search you. If they subscribe like any other client it is a win-win: You get a search service, they get real-time data feeds.
Post reply on HN