Live data from Hacker News

Introducing Tent - the decentralized social web

tent.io

91–100 of 229 posts

Re: Introducing Tent - the decentralized social web

#91

Earlier quoted context omitted.

Corporate firewalls are the general boogieman, but in reality, I haven't seen evidence that they're much more than that. To test this, we implemented fallback-to-HTTPS behavior in a very widely used previously non-HTTP client. We then observed the number of clients that failed to connect via our custom protocol, but succeeded in falling back to HTTPS. The numbers were negligible. It's ridiculous that we'd seriously b…

Perhaps, but open wifi often only allows 443 and 80.

Port numbers are not protocols.

Re: Introducing Tent - the decentralized social web

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

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 on Emule is a working implementation of a similar system to what I described, but for files instead of users.

Re: Introducing Tent - the decentralized social web

#93
post #48

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.

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.

Re: Introducing Tent - the decentralized social web

#94
post #90

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

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

Re: Introducing Tent - the decentralized social web

#95
post #59

Earlier quoted context omitted.

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.

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

I think you had the wrong URL in your clipboard :)

Re: Introducing Tent - the decentralized social web

#96
"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/).

Re: Introducing Tent - the decentralized social web

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

Re: Introducing Tent - the decentralized social web

#99
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

Post reply on HN