The distribution idea is glorious, but we'd all be better off with an application like it built on top of Syncthing ( https://syncthing.net/ ), ala DecSync ( https://github.com/39aldo39/DecSync )
You can "delete" things in an append-only ledger, in the sense that you can update the state with e.g. a tombstone marker.
On a higher level you can't delete things anyways, because as soon as you has shared them with a third party the control is out of your hands anyways. Just because current social networks try to hold up that facade doesn't make it a reality.
Sure you could make tombstoning past messages and making their contents inaccessible a more central feature, but there is nothing inherently wrong with append-only social networks.
Most things are readily forgotten once removed. No one cares enough about someone like me to keep a public archive of everything I've ever posted anywhere.
Maybe we shouldn’t use real names at all on the web.
Caches and archiving sites do exactly this.
If I delete something from FaceBook, there's no way anyone (other than FB) can prove that I have said the things I deleted. With a signed append-only log, you'll have to disown your entire log and your keys. This is the problem.
B: You can't prove that I said X! Here's where I published private key used to sign that message.
A: Do you normally publish the private keys of your messages?
B: No
A: Okay, while I agree I do not have cryptographic proof that you said X, I think it's extremely likely that you said X and then later attempted to retract it by publishing the private key. So I'm going to go ahead and act as if you said X.
It also doesn't solve another part of the problem with append-only, accidental oversharing. Even if we take this 'publish the keys' process as actually working the data is still out there so if you publish info you shouldn't like locations or PII it's always out there.
That's true no matter what, purely by virtue of being shared with others.
I believe there are point-to-point protocols that publish every private key after the recipient receives the message, but I don't see how it generalizes to publish-subscribe.
I'm missing something..
That's why the key should be published as soon as possible. In a point-to-point protocol, it would be published as soon as the recipient confirms receipt of the message. That's why I'm not sure how it generalizes to group chat protocols.
Since when is deleting the same as marking deleted?! I have a piece of rubbish on my desk, so I'll just mark it in my head to throw it in the bin, and done?!
The problem that remains is that for everyone who doesn't follow the tombstoning request and keeps the old value, they can still "prove" that what they claim was the original value is correct because its signed, unless you do more complex stuff with non-repudiation constructions etc.
That's the part that's not possible with an append-only ledger.
The article you linked is full of misunderstanding of the technology anyways, just because the underlying tech is append-only, doesn't mean you can't delete stuff from your local store or hide stuff you don't want to see.
With p2p more than with anything the age old adage of being careful with what your publish online is true.