A socialist network: encrypted, insurveillable, unmontizeable, and self-governing. App is written in Python. (Calling all socialist programmers for help!)
I've been thinking more about a 'web of trust' concept. Say I start a group account, @portland. I mark it as a group instead of an individual account, but this doesn't have much of an effect at first (I still choose a password, etc). But if I (@elon) want to invite @zuck to join @portland, I can 'vouch for' them. I simply write to my local hard drive that I vouch for @zuck and agree to forward all messages to @portland (which I the founder have access to) along to @zuck (and encrypt it me->him along the way). So, rather than ever ever transmit @portland's private ID, everything remains end-to-end encrypted between individuals, and no private IDs need to be sent over a network.
Rather than ever be stored in a centralized placed, then, group messages and data can simply trickle through the web of trust, encrypting themselves end-to-end each time between between different people in the network. This trust graph doesn't need to be 1:1 either. It's a directed graph, X --(vouches for) --> Y. But A, B, and C could also vouch for Y. In that case, any message Y sends to group G is actually sent to inboxes for X, A, B, and C.
But now say @zuck, vouched for by @elon, wants to invite @donald to join @portland, too. Instead of @zuck being able to do that immediately, @zuck could send a(n automatically composed?) message to the person who vouched for him (@elon), asking whether it's ok if he starts to pass on the mail to @portland (which @elon has been forwarding to him) along to @donald. If @elon agrees, @zuck writes to his hard drive his commitment to forward @portland's mail to @donald; and does that whenever @zuck logs in and receives mail to @portland from @elon. If @elon disagrees, then the app will prevent @zuck from writing to his hard drive that agreement; if @elon now suspects @zuck's judgment, @elon can withdraw his vouching for @zuck, and no longer forward mail to @portland along to @zuck in the first place.
Of course, you can't just engineer trust. After @zuck is vouched for by @elon to join @portland, there's nothing to stop him from just copy/pasting @portland's messages to @donald personally. I suppose in the end trust is just a social relation between humans.
I've been thinking more about a 'web of trust' concept. Say I start a group account, @portland. I mark it as a group instead of an individual account, but this doesn't have much of an effect at first (I still choose a password, etc). But if I (@elon) want to invite @zuck to join @portland, I can 'vouch for' them. I simply write to my local hard drive that I vouch for @zuck and agree to forward all messages to @portland (which I the founder have access to) along to @zuck (and encrypt it me->him along the way). So, rather than ever ever transmit @portland's private ID, everything remains end-to-end encrypted between individuals, and no private IDs need to be sent over a network.
Rather than ever be stored in a centralized placed, then, group messages and data can simply trickle through the web of trust, encrypting themselves end-to-end each time between between different people in the network. This trust graph doesn't need to be 1:1 either. It's a directed graph, X --(vouches for) --> Y. But A, B, and C could also vouch for Y. In that case, any message Y sends to group G is actually sent to inboxes for X, A, B, and C.
But now say @zuck, vouched for by @elon, wants to invite @donald to join @portland, too. Instead of @zuck being able to do that immediately, @zuck could send a(n automatically composed?) message to the person who vouched for him (@elon), asking whether it's ok if he starts to pass on the mail to @portland (which @elon has been forwarding to him) along to @donald. If @elon agrees, @zuck writes to his hard drive his commitment to forward @portland's mail to @donald; and does that whenever @zuck logs in and receives mail to @portland from @elon. If @elon disagrees, then the app will prevent @zuck from writing to his hard drive that agreement; if @elon now suspects @zuck's judgment, @elon can withdraw his vouching for @zuck, and no longer forward mail to @portland along to @zuck in the first place.
Of course, you can't just engineer trust. After @zuck is vouched for by @elon to join @portland, there's nothing to stop him from just copy/pasting @portland's messages to @donald personally. I suppose in the end trust is just a social relation between humans.