I’ve been hearing about Secure Scuttlebutt (ssb for short). It’s not immediately obvious but one thing is key, I think. The ssb documentation doesn’t mince words: “Secure Scuttlebutt is a database protocol for unforgeable append-only message feeds.” I kept wondering: what about expiring and deleting content? Does that work at all?
No, it doesn’t. "Once you publish something here, there is no way to ever remove it again from the public." This thread talks about the thing that has been bothering me for a while. @ckeen calls ssb messages “eternal messages”. And he’s right.
I like some things about sbb:
But I don’t like systems where I cannot delete things. I don’t need non-repudiation since I’m talking to people, not signing contracts. Basically a “unforgeable append-only” system is similar to a legal set of contracts and not at all like conversations in real life. But that’s what people claim. They’ll say that ssb works like conversations work in real life. What’s been said cannot be unsaid.
But this is precisely not how it works in real life. The memories might not disappear, but the insult is not repeated every time we meet. The newspaper disappears from the stand, the books get impounded, the graffiti is painted over. Secure Scuttlebutt is an example of a the kind of software design that doesn’t follow human nature even though the words used to describe it (“gossip”) try to paint it that way. Once again, we design systems to never forget but the human thing is to forgive and forget. That web page where I am called a dick still makes me angry, years later. That’s why Oddmuse has Kept Pages instead of a version control backend. I want the system to forget.
As it is, sbb is not for me. If somebody writes something illegal there is no way to effectively retract it. If you’re sorry you wrote something, you can only say you’re sorry and you didn’t mean it and you want it undone but there’s no way to actually do it. I don’t think that’s the kind of service I want to use. How do you deal with this? Assume that *mores* will change? I don’t think so.
People will also say that it’s impossible to assure you that deletions are honored. And even if you can delete messages others will make screenshots. This happens and it makes people angry, and we can’t stop them, that is true. But it doesn’t follow that the tools we develop must prevent us from doing the things that cannot be guaranteed. After all, our locks are not perfect and yet we still use them to lock our doors. The law and norms take care of the rest.
I don’t like to design a system that doesn’t allow for any take backs. Human lives, our legal systems, or social conventions – they all allow for take backs wherever possible. It’s the humane thing to do. Our software should reflect this.
#Cryptography #Social Media #Scuttlebutt
(Please contact me if you want to remove your comment.)
⁂
In court, we will find some people who have embedding a crime in the blockchain, merkletree, or whatever it is. Then what? Eventually the crime will make it worth it for law enforcement to confiscate your equipment and impose daily fines until you’re done for. Until then, it’s legal uncertainty for all. Thus I claim such a system will never work in practice.
People will use it, and problems will occur, I’m sure. But no big player will want to use it. And if your Mastodon instance is full of hentai then many will block you. I think the legal frame of mind is absolutely the way to see these issues. It can be as powerful as code.
@ckeen dug up this paper: A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin, by Roman Matzutt, Jens Hiller, Martin Henze, Jan Henrik Ziegeldorf, Dirk Müllmann, Oliver Hohlfeld, and Klaus Wehrle.
A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin
– Alex Schroeder 2018-07-03 07:07 UTC
---
@kensanata
First of all, I totally agree with your post: having immutable messages is not a great idea.
Scuttlebutt is not an internet protocol. You can basically use it on a mesh topology or in a post-internet world. To me, this is it’s main and most interesting feature.
Because of this property, you cannot rely on a 100% uptime (unlike AP), you won’t get the message directly from the source but from another user (gossip).
This yields a lot of problems regarding delivery reliability and message ordering.
While this is not technically totally accurate, you have two kinds of objects (over-simplification, don’t want to write a book):
Each message posted on the feed can be either public (not encrypted, just signed) or private (encrypted with the recipient’s private key).
This yields two problems:
The blobs are currently used to store images and videos. This helps keeping the feeds in a somehow manageable size.
The community want to fix these problems.
Instead of inlining the private message in the feed, we may store them in a blob encrypted with a session key[out-chain]. The feed would just contain an encrypted link to the blob.
This is a pretty good idea which would permit us to introduce the idea of a private groups: groups which could share a secret and could discuss outside of the chain[groups].
This comes with some unsolved challenges: you need to agree on a session key asynchronously.
Because of the disconnected nature of the protocol, this is pretty tricky: you regularly end up with a RTT of several days. This excludes out of the box double ratchet and similar protocols we usually use.
I’m not a crypto nerd, I have not idea how they plan to fix this, but I know a lot of people are working on it.
[groups] %gVFvcYy2aknKuYwThI+dD2BKr5LfNN5CA4FglEPqnow=.sha256 , %xAlzJXkpPcZZhRLRFixVjm6HFeJezhDCkeXfY9ddcQU=.sha256
[out-chain] %QJEpN8LN1t3BrIkUQ3WoOMWRsMArbVUZCpTeBYcuqfw=.sha256
— @Ninjatrappeur