My proposal for a distributed social networking protocol

http://dlo.github.com/2010/05/07/openprovider-a-distributed-social-protocol.html

by theli0nheart • 16 years ago

22 26 16 years ago

dlo.github.com

Qz5• 16 years ago

What's the point of the id? Coordinating this across multiple providers seems like a big headache.

warfangle2• 16 years ago

What if the ID were similar to a domain name? They stay the same, but the IP address (in this case, the sha1 of the email address) can change.

What if the DNS model were taken in order to find which social provider a given user was on? That combined with a trust metric (automatically gleaned?) between providers would go a long way, I think...

Qz5• 16 years ago

That seems like building an internet within the internet, which sounds like a lot of redundant work.

theli0nheart6• 16 years ago

Sounds like a pretty interesting idea...can you elaborate a bit more?

arethuza5• 16 years ago

You would presumably need something like an MX record - but MX records are for all email addresses using that domain. You could probably create individual DNS domains for each user though.

So I guess you could give your email provider the ability to publish your social networking provider - but not sure what problem that solves...

theli0nheart6• 16 years ago

When I first drafted this out, the id was provider-dependent. The more I think about it now, the id does seem kind of irrelevant. I'll remove it.

Qz5• 16 years ago

My thinking would be to have the email/hash be the id, which enables people to have multiple profile's accessible from one account, use one email for friends, one for business, one for all those shady black hat things people do in their spare time...

chrischen• 16 years ago

Email is already distributed. And two people are linked together simply by knowing each other's email addresses. Might as well build on top of that.

Qz5• 16 years ago

So what differentiates 'social networking' from email? Anything besides making some/all connections/messages automatically public?

alanh• 16 years ago

Something I have found interesting and useful about Facebook is that it outlasts email changes as a way for people to stay in touch, and connects friends who don't even know each others' email addresses.

TomOfTTB• 16 years ago

The flaw in your proposal is that the problem here really isn't a technical one. Your argument seems to be "once you can export your connections that solves all other problems because companies will have to listen to you". But that's not true.

Right now you could easily create an export system using the e-mail addresses of your connections. But once you do that you can't interact with Facebook members.

That's the problem with Facebook and it's root is in a business reality not a technical issue. Facebook and other social networks realize they lose their greatest (and maybe only) customer retaining mechanism if they become inter-operable. Once that happens they become a cheap commodity (much like e-mail servers are today).

So becoming inter-operable means the end of companies like Facebook being major players in the industry and they aren't going to do that willingly. THAT is the problem.

arethuza5• 16 years ago

That is true, but I'm pretty sure back in the old days there were multiple proprietary email systems that didn't interoperate and they eventually all did end up supporting SMTP eventually.

Raphael• 16 years ago

Ah, but the other networks risk a fate much worse than commodity if they don't band together. Notice the widespread adoption of OpenSocial, including MySpace, Hi5, and Ning.

underscore2• 16 years ago

I like the protocol-agnostic (and locally-stored) connection information, but I don't like the fact that I (I'm assuming) have to manually synchronize them between my devices -- if I understand right, if I friended someone on my phone, I'd have to somehow synchronize that information to my laptop if I wanted to use it there. Probably the provider would keep that information locally, and then prompt my browser to accept a new copy -- I know I wouldn't want to deal with anything much more fiddly than that. Is there a compelling reason to have that (edit: where "that" is the connection information stored in the browser, as suggested in the article when I wrote this) instead of a defined-in-the-protocol way of on-demand data export?

I guess the hash is just to fool spammers? It seems to add a fair amount of complication to the protocol to address just that one use case.

How do you define privacy? How does your protocol protect it?

edit: clarify clumsy wording

theli0nheart6• 16 years ago

Regarding your first point, yes, I agree it doesn't make much sense to manually synchronize between devices. Providers would probably need to store that information to begin with, and you would have the option to export that information at your leisure.

Yeah, that's the primary use of the hash. It does add a bit of complication, but I think it's necessary for widespread adoption.

Privacy is provider-specific, therefore it's not up to the protocol to say what and what shouldn't be private. It's up to the provider.

underscore2• 16 years ago

I assume that your centralized repository of (email, id, provider) tuples wouldn't just spill out all of its contents to the world, preventing mass email harvesting. Instead, it would reply with the appropriate (email, id, provider) tuple when asked for an email (hashed or not) that it knows about, and return nothing or an error or whatever when asked about an email that it doesn't know about. In either case, as arethuza points about elsewhere in this thread, it is essentially an email address validity oracle for emails that it knows about -- hashed or not -- since a spammer can sit there all day and ask it about random email addresses and record its responses. If you hash an email address, the only thing you buy is to make the spammer add a line of code to their script. In short, I think that using a hash is functionally equivalent to not using a hash, at least for spam purposes. What do you think?

(note that a partial email validity oracle isn't necessarily a deal killer; PGP/GPG keyservers, for example, are partial email validity oracles, and have not only existed for years but have also gained acceptance amongst (some of) the security conscious and the paranoid)

(also note that a hash would be a safeguard (whose effectiveness is dependent on how resistant the hash function is to first preimage attacks and other factors) against disclosure following a compromise of the central database/authority, in addition to its questionable utility at fighting spam in normal situations)

arethuza5• 16 years ago

"That value you see is not reversible"

Strictly speaking, that is true. But with a brute force dictionary attack all you do is generate likely email addresses (and these are often very easy to predict) and apply the same hashing process (which has to be public) and look it up in your local copy of the database.

theli0nheart6• 16 years ago

True, but why would a spammer do that if he already had the address to begin with?

Qz5• 16 years ago

It's about matching an possible email to an actual email. But I don't think it would really make a difference as the same thing applies to email addresses in general.

arethuza5• 16 years ago

Actually, I just realized this would be a horrible thing as it provides a means of checking validity of email addresses - presumably a spammers delight.

petercooper• 16 years ago

I never got into it when it had a brief spell of popularity, but hasn't similar stuff been attempted with FOAF? http://en.wikipedia.org/wiki/FOAF_(software)

xtacy• 16 years ago

You might find some more information about such architectures that the research community is currently looking at: http://prpl.stanford.edu/ is one such.

My proposal for a distributed social networking protocol

Related Stories