Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We need a decentralized social graph. I should host and own my data not facebook or any other organization. Maybe browsers should innovate and solve this problem.


Many people have thought this too. A sort of p2p social network? You solve a handful of problems but create many new ones to overcome. For example, using Facebook on multiple computers is simple right now. Now lets consider a p2p model. How do you handle uploading photos from a computer that isn't your main/home one? You'll need to basically synchronize content between the computer involved and your main one. There's also the case where I want to share a photo and not store it locally at all. What happens when some of the computers involved in your friend network are turned off and those friends want to view photos? I'm not sure you can make it completely P2P. You might need a central 'cache' of new content which then just gets pushed down to your friends once they sign in. And since everyone is disconnected that sounds like everyone needs to have a copy of their friend's data. I'm not interested in storing their photos on my PC. Just some random thoughts that came to mind.


You'd probably like OpenLike: http://openlike.org/

or OpenSocial: http://www.opensocial.org/

Not that OpenSocial took off or anything. And I'm not that confident in OpenLike, either.


opensocial isn't doing too bad. It is supported by Yahoo, Google, MySpace, LinkedIn, and many more networks.


I actually architected something for this on the last airplane ride I was on. Here's the gist.

First of all, there is a basic protocol that any social application can adopt to. It basically consists of a few URIs like /user/login/, /user/register/, etc.

Secondly, since "virality" is key in getting something like this implemented, I propose that there is a form of global identity database that is accessible by anyone. Only email, user_id (depends on provider), and provider_id information is stored (I'll get to the provider bit in a second). Any identifying information is hashed to protect private information. The issue is making this database publicly run (similarly to Bittorrent) and being able to publish the hashing algorithm used. It would obviously have to be more complex than MD5 or SHA1.

Thirdly, there are what I call "providers". Providers are basically apps like Facebook and Twitter. They are capable of deciding what information is public. There aren't any privacy "settings" for each provider. Each provider's privacy policy is static and will not change. I.e. provider A will display to the world your SS#, name, and phone number, whereas provider B will display just your name. This is done to eliminate any gray areas.

Thirdly, the idea of "notifications" and connections. Connections are one-way (like Twitter). So, you might be wondering, how do you connect between two "social networks"? You search for the person you're looking for by email and are given their user_id and provider_id. Your provider then has all it needs to connect with this person (it sends a message to the friend's provider to a notification endpoint, and the friend's provider then can do whatever it wants with that information).

Notifications consist of updates, connections made, and other things (possibilities are endless).

Rules:

1) Users can only use one provider at any given time.

2) Users can choose to delete their profiles on demand.

3) User data can be exported so that provider migration is quick and easy.

I should write a blog post about this. There's way more. I called it OpenConnection.


You've mentioned several restrictions without any enforcement mechanism.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: