--- sn_wot.txt.03	Sat Mar 20 23:15:48 2004
+++ sn_wot.txt	Tue Mar 23 12:34:53 2004
@@ -1,8 +1,12 @@
 An idea for distributed secure/reliable social network
+version 4
 
 by Vasil Kolev, vasil(at)ludost(dot)net
 
 
+-1) Todo
+    Appendix A and B, email and native transport methods
+
 0) Disclaimer
 (all rights reserved, blah blah)
 
@@ -186,6 +190,26 @@
 procedure for key exchange. The client , again depending on user's preference,
 will support receiving requests on a TCP port, or other public method.
 
+    4.5) Key revocation and key expiration.
+
+    There are two ways to revoke a key. One of them is to make a revocation
+request signed with the key itself, and propagate it through the transport
+layer (there are some problems with this, that will be discussed elsewhere).
+The other way (if the key itself was lost, or there is something that makes
+it unusable, like forgotten passphrase), is to have it's LoT changed to it's 
+lowest value by everyone who has signed it, and have the new key of the 
+person/entity signed by them. Changing soneone's key means that the new key 
+has to be signed again.
+(note: the revocations request itself is a signature done with the private key,
+with the lowest LoT).
+    Revocation requests are final and terminal, after one such request the
+key becomes invalid.
+    Key expiration is done the following way: some time before the key expires,
+the owner generates a new key, signs it with the old one, and propagates it
+through the network as his new key, to have it signed by the people that 
+have signed the old one. It's up to them then to sign it and start using it.
+(It can also be mandated, that if you have more that one key for an entity, to
+use the one with the later expiration date).
 
 5) Some interesting questions
 
@@ -266,16 +290,32 @@
   And of course, you have FULL control about what you give to whom.
 
 7) Problems (that I've seen)
+
+  7.0) Misc social problems
 
   There is NO full anonymity in this system, because you can always be
 traced through the signatures of your friends. Also everything you
 send is provable to be sent by you, by the signature of the request, 
 because as a rule, a request can't be accepted if it hasn't got a 
 valid signature.
-  There isn't a really clear and simple way to revoke signatures. There
-are a few ways, to have all the signatures and revocations have a 
-time stamp, but the propagation of the revocation is still a problem,
-and may impose further restrictions on the transport layer. This, of 
-course, is fixable with a central revocation authority (or some of them),
-but that doesn't feel right for such system.
- 
+   Every normal participant in the system will be able to keep track of
+events, like new keys, changes of FL, changes in profiles (that he has
+access to), etc. This exists in current such networks, too, but here
+it's something by default, and some people may have objections about
+giving so much information so easily. 
+
+  7.1) Update propagation
+
+   This has always been a problem in WoT and peer-to-peer networks, and
+there aren't a lot of good solutions. 
+   One of them is to have a flood-type update (if you're using email or
+some equivalent off-line (e.g. not real-time) transport layer), and not
+to resend the update if you already have it applied (which will eliminate 
+loops). This would create a storm of updates on every major key expiration
+or revocation, and will give a mediocre guarantee that everyone will get
+the update. 
+   The other way is to have a keyserver-like structure that will take care
+of the propagation of this. The problems there will be the size of the
+database, the synchronization of the servers (one server will be a single
+point of failure, and the database will have trouble being split, because
+you won't be able to verify all the signatures).