Thanks for the radical transparency, and I appreciate that we're going to collaborate on the work necessary for deleting local content. I'm going to be frank, as I usually am, but I mean only what I say and nothing beyond that (i.e. I don't "imply"), and I mean good even if I'll be very direct.

There are lots of assumptions behind these plans that show a misunderstanding of Scuttlebutt. For instance, "delete" was used conflating two different kinds of deletes: global deletes ("instant", distributed, and total) versus local deletes (rm -rf on one device). "Delete content from the platform" means you think SSB is a platform, when in reality each device is a platform. "Potentially, ability in the app to refuse to let a user continue to use the platform until they delete." This assumes the platform is not a local software experience. Another thing that stood out to me is the implicit assumption that Verse would be a primarily online experience. Simply the expectation of upper limits on the time allowed for "deleted content" to stay available means that you're not thinking about the offline capabilities of Verse. If you design with deliberate offline support, you'll notice that if Alice goes offline with Bob's content, but Bob subsequently asks everyone to delete content X, Alice could be hiking or could be on Mars under a global dust storm, and could unknowingly keep Bob's content X for years. And what does "control my own content" mean when other users can be offline?

When I say "misunderstanding of Scuttlebutt" I don't mean that SSB is meant to be used in a way that accidentally allows abuse, and that you would have to make a tradeoff between "complying with the SSB ethos" and "handling abuse". This is not a tradeoff, you can actually do both, but only if you clearly separate the responsibilities. You cannot build a computer system that enforces good, you can only build a people system that enforces good. This is something I address in a FAQ video I'll release in a few days, but SSB makes clear design decisions to let computers handle computer problems, and let people handle people problems. That to me is brilliant, and also surprisingly works in practice, we already have proof that it scales, in hospitality when people host others in their homes.

By mixing these two realms together, creating a hybrid computer-people system, hybrid decentralized-centralized system, you don't reap the benefits of both at the same time, you would create something fundamentally incoherent. As a business, the decentralized part would only bring you headaches and you would be incentivized to build centralized. I can already see these tendencies with plans to augment pub infrastructure. If you actually want to be "successful" in the typical Silicon Valley sense for internet software, then just build centralized. It'll be much less headache, most people, specially the media, just want Facebook/Instagram but without Zuck's horrible social judgement (that have led so many execs and acquired founders to leave FB). If you want to build something "successful" but still truly decentralized, then start a hardware company. Apple is actually a decentralized computing company, their stuff works offline, local-first, even off the grid. More on that in this blog post I wrote: https://staltz.com/layers-of-the-internet-economy.html

But you also have the choice of building something coherent if we take a moment to think through what are our assumptions:

• Offline-first, local-device-first (also suppose Alice could go offline in Africa for 5 years)
• End to end principle
• Computers solve computer problems
• People solve people problems
• SSB is like USB drives or Email, not like Instagram

And how to build on top of centuries of knowledge in "village moderation" to build something that feels new to the tech world, but familiar to pre-internet socializing.

I'm 100% for building local deletion features, and am actively pursuing it (I was just talking to Dominic and Keks about exactly that the other day), but it must be done the right way.