You are reading content from Scuttlebutt
@andrestaltz %fM1lmCv5YTEUIBQOw/zOlZsb8jjb7ltzncDJ+/uoQng=.sha256
Re: %z28ZLyE7O

I love unpopular unsolicited polemic opinions, it forces us to think honestly and avoid self-reinforcing group thinking.

Talking about restrictive gossip does nothing more than closing the eyes and hoping the problem goes away. It won't. All this does is to give a misleading sense of security/privacy to nontechnical users, who will then suffer the hardest when data gets inevitably leaked.

What is "the problem"? Is it "fake privacy", vulnerability to leaks? Is it weak replication resilience between clusters (seems like the opposite problem of small-world privacy)? Some of these problems are specific to some cultures, and should have configurable solutions. E.g. I know that germans are very concerned about privacy, yet americans not that much. Americans are very concerned about censoring the bad people, other cultures (scandinavians?) aren't that much. We shouldn't promote a culturally specific problem to global scale. I'm not so concerned about culturally specific problems as long as they have configurable solutions (e.g. hops settings, restricting gossip, etc). I'm more concerned about the global problems in Scuttlebutt, and those surely exist, and I think they are related to the issues Aljoscha is raising.

I've been thinking a lot about forgetability in Scuttlebutt, and whether we actually need sigchained messages for unforgeability. If you read up the security properties of secure-scuttlebutt and the sigchains in specific, it says:

Security properties

Secure-scuttlebutt maintains useful security properties even when it is connected to a malicious secure-scuttlebutt database. This makes it ideal as a store for peer-to-peer applications.

Imagine that we want to read from a feed for which we know the identity, but we're connected to a malicious secure-scuttlebutt instance. As long as the malicious database does not have the private key:

  • The malicious database cannot create a new feed with the same identifier
  • The malicious database cannot write new fake messages to the feed
  • The malicious database cannot reorder the messages in the feed
  • The malicious database cannot send us a new copy of the feed that omits messages from the middle
  • The malicious database can refuse to send us the feed, or only send us the first N messages in the feed
  • Messages may optionally be encrypted. See test/end-to-end.js.

See the part in bold. It assumes the peer is untrusted (malicious)! This thread was started by Mix recommending to only gossip with trusted peers. So by definition, you would not connect to malicious peers attempting to write fake messages, or reorder, or omit. This to me is very interesting, because I think as we start to recognize Scuttebutt's unique strengths, we also begin to recognize those YAGNIs that we couldn't have foreseen since the beginning. For instance, I believe we should transition to a much less Pub-centric topology, we should explore Rooms ("dataless Pubs with ssb-tunnel installed") and DHTs for relay P2P. Connect only to actual friends. I also am started to suspect that we should get rid of unforgeability guarantees of the sigchain, because it would buy us forgetability, ephemerality, which are very natural for human interactions, and one of our goals and principles is to have the technical layer reflect the social layer in the most natural way possible.

... continues

Join Scuttlebutt now