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.
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.
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.
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 :-)
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.
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.
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.
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.
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 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?
(2) ... 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
This would be especially bad if the server you're using is hacked and they stop everyone from leaving :/
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 interesting problem to solve.
EDIT: Another big problem, how do I search users? A DNS-like solution would be feasible?
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.
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.
Personally, I don't like the network address as id, for two reasons; firstly, you don't control it, your network provider does (whoever that is - the server or ISP does). So if that entity wants, they can boot you off and pretend to be you.
Secondly, it ties you to them; what happens if you switch servers, or ISP, or whatever? I mean, right now I'm planning on switching to a cheaper, faster offer from another ISP, but I wouldn't do it if I were to lose all access to my accounts on the different services.
I think the id should be both controlled by the user and portable; that mostly leaves public keys and their fingerprints as ids.
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.