From f8dcef24195839ea05ee83249e5c2ceeed1d9b7e Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Fri, 15 Jul 2011 03:04:28 +0200 Subject: [PATCH] projects: sketches for federated social network with strong cryptography --- projects.mdwn | 8 ++++--- projects/crypto-fsn.mdwn | 46 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+), 3 deletions(-) create mode 100644 projects/crypto-fsn.mdwn diff --git a/projects.mdwn b/projects.mdwn index 9bbf245..f8d1334 100644 --- 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 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 + -- 2.20.1