--- /dev/null
+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
+
projects / www-rohieb-name.git / blobdiff