You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
marxzuckerburg
changed the title
Conceptual/Technical Issue: How to have group channels or feeds (like @portland or @oakland) which are safe and encrypted, but also inclusive, as well as self-governing and self-moderating?
Conceptual/Technical Issue: How to have group channels or feeds (like @portland or @oakland) which are safe, encrypted, and self-governing?
Sep 28, 2020
marxzuckerburg
changed the title
Conceptual/Technical Issue: How to have group channels or feeds (like @portland or @oakland) which are safe, encrypted, and self-governing?
Conceptual/Technical Issue: How to have group channels or feeds (e.g. @portland) which are safe, encrypted, and self-governing?
Sep 28, 2020
marxzuckerburg
changed the title
Conceptual/Technical Issue: How to have group channels or feeds (e.g. @portland) which are safe, encrypted, and self-governing?
Conceptual/Technical Issue: How to have group chats/channels/feeds (like @portland) which are safe, encrypted, self-governing, and built on trust?
Sep 28, 2020
marxzuckerburg
changed the title
Conceptual/Technical Issue: How to have group chats/channels/feeds (like @portland) which are safe, encrypted, self-governing, and built on trust?
Conceptual/Technical Issue: How to have group chats/channels/feeds (like @portland) which are safe, encrypted, self-governing?
Sep 28, 2020
marxzuckerburg
changed the title
Conceptual/Technical Issue: How to have group chats/channels/feeds (like @portland) which are safe, encrypted, self-governing?
Conceptual Issue: How to have group chats/channels/feeds (like @portland) which are safe, encrypted, self-governing?
Sep 28, 2020
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.
The text was updated successfully, but these errors were encountered: