adz

Thank you for pointing this out @edbaskerville ! I was not aware of this. Do you know about any best practices for this or recommended licensing models? LGPL would also...

> or.... separate it more, moving the `schema/validate` module to `operation/plain/validate` might be nice. Intuitively I don't expect schema validation to be outside of the schema module, but I can...

> yeh, i know what you mean, but that whole module is actually `PlainOperation` validation... but of course, it's against what we expect a schema to look like... I see...

We can also run schema validation against operations and documents (later) 👍🏻

Small thought on the change to make timestamp mandatory: Could be actually nice to still not have `timestamp` as an argument on the `OperationBuilder` constructor, and set it by default...

> Yeh, cool, it would be nice if the methods in `schema/validate` we're generic over some trait (maybe we already have a suitable one 😅) I think the trait is...

> This might be unavoidable though, you need some kind of app state to be able to guarantee incrementing timestamps are provided. I guess the question is whether it's a...

> > @adzialocha our current spec for header has moved away from using extensions for any of the fields we need for this PR. In that case I suggest removing...

We should consider the same for our `-js` library

Superseded by new crate naming scheme, for example via https://github.com/p2panda/p2panda/pull/535