The way engines have been thought of so far has been entirely at the meta level, nothing in terms of design has communicated to me how we can have engines at the user level. I have some ideas myself with long living processes in the client, but I think this is currently far away. Further if we are thinking in terms of the system of anoma, then we’d likely consider other means which are “already native” to implement this, which is what the post highlights.
Every feature we write about ought to be connected to user flow in some way, even if only indirectly (Engine A gives some value to engine B which gives some value to Engine C which interacts with the system and user in XYZ way). The reason for this is that we are building an operating system and each feature we consider has an effect on the overall operation of the system. If we consider a feature which does not interact with the user in some way, then how can we realize it’s value?
I find this to be a massive issue, as this means we haven’t considered how the system comes together at all. I.E. we have not considered how the features we are writing about come together in a cohesive way. From my point of view there are two parts in which the system comes together which is in the node and client and I’ve expanded upon the details here:
If it exists within the system you can potentially read it yes. However this isn’t grounds for concern, as if I have keys on my Unix device my unix machine can read them, or keys on my ledger they can read them with some new fangled cryptography. Sometimes on my unix device I store keys in an encrypted manner, I.E. it requires another password to decrypt things and thus anyone snooping on my Unix box besides me can’t actually read those sensitive files
An object system will likely be written ontop of resources within AL. This will be done through a protocol, and I’d like resources to be the key point of abstraction for how data in Anoma is spelt out.