You could argue that could be handled via versioning, with the latest version being ‘nothing’. As long as you can get the previous known-good version, then you’re in business.
I think the idea of a ‘shredded’ delete is powerful though. Destroying something is some how more tangible than making it impossible to find. I suppose that is the human thing David was talking about though. For group access, I’d fear accidental/malicious data loss more though.
It feels more like a shared ownership model to me. You either have one owner or many owners, each with full control. Ofc, there are limitations to that, but it feels like that is what it is.
It is, but you can have private data with many writers and also many readers. Public data is of course readable by all, however it can also have many writers.
Yip, sry bout that.
Kinda, so we have read/write permissions, so that’s OK. We also have immutable links/references etc. that can be transmitted in messages (so we are on the right path). The data types themselves have some properties, like causal references or partial order (logic clock). So also good. We have data that follows rules for adding more info.
So yes we do Object Capability type design here, but we lack one part to truly allow this in full IMO. The missing part is the business logic of those operations, this would be where we could add stuff like only allow X from Y and X amount of times etc.
That’s still not a great/complete answer, but I would argue we are on the right path here and as @Traktion says, I think we have a way to go after stability/launch, but that’s good as the foundation won’t change, we will only add functionality.
Yes thanks, and you shook off the politician epithet by not stating several times that you are being clear, when in fact you have been very clear. I can’t wait to get my head around what you and the team are cooking.