You actually want to view possible economic or administrative exchanges as just being literally partially applied anonymous fucntions that only counter parties can import, partially apply and if not fully applied, re-export for further steps.

You kinda want dependent types so you can express stuff like “this has been signed and accepted by Bob or some designated delegate on his/her behalf”

First class signed values get a title subtle because you’ve gotta have a robust way to talk about a canonical binary serialization that plays nicely with cryptographic signatures. The simplest way is to require every signed value have a globally unique nonce pubkey counter for each new thing signed by that identity. I’m saying that a little bit imprecisely and I mean the weaker per pubkey sense of that. This also is a sane approach because it’s the same as requiring per identity sequential consistency OR explicitly coordinated nonce sharding.

Basically: if you just add first class identity and signatures as values to like anyyy dbms and have strict validation for any db transaction to commit, the whole needing an api barrier around your application db kinda goes away!

AFAICT, pretty much every api wrapper around a db is mostly because pretty much every db has no native way to model and enforce an application specific identity authorization and resource ownership model.

Allowing your full dbms to be exposed over an api while respecting application state and security is a pretty mind blowing perspective shift, and maybe I should revisit working on that.

There’s a lot of other cool pieces that I’ve not touched on that make it pretty fun/interesting/useful, but I think that partially expresses stuff