projects: sketches for federated social network with strong cryptography

diff --git a/projects.mdwn b/projects.mdwn
index 9bbf245..f8d1334 100644 (file)
--- a/projects.mdwn
+++ b/projects.mdwn
@@ -9,11 +9,13 @@ Ideas for new software projects
 
 Here I collect sketches for software that I still need to write (or that I 
 would like to be seen written by someone other... ;-)), and features that 
-IMHO still need to be implmented in existing software. 
+IMHO still need to be implemented in existing software. 
 
-This section should serve as a source of inspiration for people that have too 
-much time on their hands.
+This section can also serve as a source of inspiration for people that have too
+much time on their hands... ;-)
 
+* [[Sketches for a federated social network|projects/crypto-fsn]] with full control
+  over your own data by using strong cryptography
 * [[OpenStreetMap editor for mobile devices|projects/osm-mobile]]
 
 JOSM: Nice-to-have

diff --git a/projects/crypto-fsn.mdwn b/projects/crypto-fsn.mdwn
new file mode 100644 (file)
index 0000000..3e22088
--- /dev/null
+++ b/projects/crypto-fsn.mdwn
@@ -0,0 +1,46 @@
+Sketches for a federated social network using strong crypto to protect the user's data
+===================================================================
+
+Network structure
+-----
+
+The network structure is decentralized; status updates, posts, etc. are 
+transferred between endpoints. Users are identified by addresses that 
+follow RFC 822. Protocol is unclear:
+
+* XMPP: wide-spread and allows easy implementation of a chat, has integrated
+  authentication, however not very light-weight to implement
+* OStatus: used by Diaspora, StatusNet, identi.ca
+* Salmon?
+* RSS/RSS Cloud?
+* PubSubHubbub: pull-based, apparently not used frequently
+
+Concept
+----
+
+All users have a private key and a keyring of public keys. "Friend" 
+requests are directed, the inquired person has to approve friendship.
+Positive acknowledgement of this request leads to addition of the inquirer's
+key to the user's keyring. All status updates, pictures, ... the user posts
+are encrypted with the keys in his kearing, so only the followers can actually
+encrypt and see it. NO PLAIN-TEXT COPYING OF CONTENT!
+
+Pro:
+
+* encryption prevents accidental data leakage
+* the user has full control about who can see the data
+
+Contra:
+
+* encryption makes the process slow, needs additional cpu cycles
+* advertising encryption could lead to false security, as the content can 
+  still be distributed through explicit downloads by trusted users
+* encryption for every single person in keyring leads to much traffic
+
+Problems:
+
+* "Reposts"? If so, content can't be encrypted => checkbox: repost yes/no?
+* Groups? Generate public/private key for each group?
+* How is the data stored on disk?
+* Private keys must be very well protected on the endpoint
+