--- sn_wot.txt.01 Sat Mar 20 09:50:14 2004 +++ sn_wot.txt Sat Mar 20 09:52:06 2004 @@ -1,12 +1,21 @@ -An idea for distributed secure social network +An idea for distributed secure/reliable social network by Vasil Kolev, vasil(at)ludost(dot)net - + + 0) Disclaimer (all rights reserved, blah blah) This is heavily influenced by orkut, so I might be missing something -important, you can correct me at vasil(at)ludost(dot)net +important, you can correct me at vasil(at)ludost(dot)net + + Thanks to all the people in orkut, that came with a lot of +suggestions, and special thanks to Bine. + + The latest version is available at +http://vasil.ludost.net/pisaniq/sn_wot/sn_wot.txt, at +http://vasil.ludost.net/pisaniq/sn_wot/ you can find previous versions +and diffs. 1) Prerequisites @@ -34,14 +43,29 @@ Public/private key pair - a key pair in PKC sense. Every single entity in the system has a pair of it's own. Keys can be signed with -other keys, to ensure their authenticity. There also can be levels -of trust of the signatures, e.g. to approve a key, but not the keys -signed with it. +other keys, to ensure their authenticity. Every private key has a pass phrase to protect it. This phrase is used to encrypt the key with some standard symmetric encryption algorithm, and the key is only usable to the person that knows the pass phrase. This prevents misuse of stolen keys(without their -pass phrases, of course :) ). +pass phrases, of course :) ). + + Key signatures - these are a part of the key, and are used to +verify it's authenticity. It has the following parameters: + 'level of trust' (LoT) - this parameter tells how trusted a key is. +For example, a low level of trust means that this key is trusted, +but every key, signed with it, is not. + 'friendship level' (FL) - this tells the relation of the signer with +the key owner. This has a meaning that's similar to the level of trust, +but it's from the other direction, e.g. LoT tells you how much +can you trust keys signed with this one, and FL tells other people +how much they can trust your signature. This makes possible to +have a friend that other people can trust only when they agree +with this implicitly. + Timestamp - it's the exact time when the signature was made. +This can be used to distinguish which event is the latest, which +signature should be used, etc. + End user - A user in the system, that has his own profile, friends, and other attributes, that are visible to others on the user's will. @@ -91,6 +115,7 @@ 4.0) Prerequisite Every request here, unless stated otherwise, is signed _and_ encrypted. +Every received request is acknowledged by the receiver. 4.1) Joining the network @@ -149,9 +174,62 @@ secure connections to be used with other applications, using a standard procedure for key exchange. The client , again depending on user's preference, will support receiving requests on a TCP port, or other public method. + + +5) Some interesting questions + +5.1) What can you do with a community? + + This deserves a part on it's own, because it's one of the pieces that +makes the system really expandable. Through the interface for a +community, you can run any service that has user participation, can +authenticate it's users, and authenticate itself to them. + + One of the possibilities is to make a normal forum. It can +have restrictions of all kinds, like who's able to view what, who +can post, or who can join, based on trust from it's current users' +keys, or some equivalent indication. It then can implement anonymity, +by stripping users' signatures (if they desire, or if that's policy), +and leave only it's signature. Of course, it should be noted that +it's not _full_ anonymity - you can never be sure what the implementation +of the community server will do, and all your requests are ultimately +signed and traceable to you (or to be exact - to your key). + + One other possibility is anonymous ranting system, equivalent to +that in orkut. It's anonymity again will depend on the service itself, +but the difference here is that all your ratings have to be kept +in their original form, so when you decide to modify any rating, +the system can find your old, and replace it. + + +5.2) How exactly is it decentralized? + + This is easy to explain and understand - the system _can_ be +centralized or decentralized, depending on the preference of the +users and people that run it. It all depends on the communications +method. The example given is with email, which makes it unnecessary +to have anything central, you'll just need a working mail servers, +to be able to send and receive the requests from other people (and +that can fully be automated). You can also use something that has +irc-like structure, of connected servers (hubs and leafs) to propagate +information through the network (in fact, you can use irc for that :) ). + + The only exclusively central points (e.g. points that aren't +(easily) distributable) are communities, and there is NO requirement +for all the communities to be in a particular place - you can have +them in different countries, on different machines, using another +transportation method, or whatever you think. + +5.3) Why not use full decentralized peer-to-peer infrastructure? + + Because in peer-to-peer you can't have a good reliability, if +the information that you need isn't available at more than one +node, and because there is a general problem with discovering +nodes in such a network. And, you can always use email exclusively, +which gives you the same benefits with enough reliability. -5) Why? +6) Why? Why should you use such a system, if there are a lot of ones that do almost the same job, as orkut, and FOAF? @@ -176,7 +254,7 @@ still use FTP to update, which is real easy to sniff). And of course, you have FULL control about what you give to whom. -6) Problems (that I've seen) +7) Problems (that I've seen) There is NO full anonymity in this system, because you can always be traced through the signatures of your friends. Also everything you