[theanzelm]

Right now, we're not doing complex validation very well, we basically rely on all clients having the same schema or backwards-compatible schemas and prevent errors at the type level.

But because the schemas are runtime constructs as well, we might be able to do more complex stuff in the future. Basically any rule you can express as a function of (previous history, new transaction) -> is new transaction valid? can be a rule in theory, and each client will verify it in an eventually consistent way.

For the time being, the Group abstraction with it's reader, writer and admin roles, plus composition of CoValues in different groups is sufficient for most permission-like rules, which is what most apps need most of the time.

Let me know if that makes sense

[somishere]

Hey, thanks for the response. This does make sense. The group roles do seem relatively powerful.

I guess what I'm probably getting at is how does it hold from a threat perspective? What is to stop an actor distributing something extra large or unscrupulous between nodes. TS is notoriously hard to use for validation within types (e.g. string of max length, number between), but clearly covalues go beyond this.

Anyway, I'm writing this having not yet tried the framework. So I'll do that first and then do some further reading, and then jump onto the discord if I have more questions. Cheers.