002 Proposition actor
I decided to dedicate my second note to authorisation. The reason for that is straight: I’m simply well too tired to think about it any longer. It’s been on my mind for far too long, and I can’t stand it.
For the specification of Logos, a language language my team designed to truly
model arbitrary discourse, I came up with this wonderfully cryptic definition of
its only companion in existence:
// 14. Actor is a iota of the people. // actor := iota. // 15. This is the currently speaking actor. // this := actor.
actor is not a trivial iota like
boolean, but is used to differentiate
something outside the structure of text. Actor is supposed to be a human being, but I’m
yet to see a reason to explicitly exclude robots. As you can’t quite fit a living person
into a computer, we use cryptography to generate special “keys,” or so-called “wallets.”
The idea of actor is hardy ever defined, yet it’s the most real of all elementary propositions.
I find this very ironic. There’s also this one cool thing about
iota is how “infinitely small”
and simple it is. In fact, it’s so small the values of iota-propositions such as
actor actually coincide with
void, the so-called “infinitely large”, completely. This should
make sense, go ask the theoretical physicists.
// This will NOT panic because `this` is actor-proposition. if this is void, then panic! // But this will because `actor` is a iota-proposition. if actor is void, then panic!
So far, so good, but it’s all theory, and quite predictable at that. To be fair, I’m not
trying to impress anyone, just desperate to point out why for a grammar like logos, there
must be an elementary proposition for authorisation. The logic behind
actor is very simple:
all actors are different, therefore their corresponding propositions must all be different too.
At the same time,
this always to the currently speaking actor proposition, which by definition
never can amount to
In real-life situation actors would constantly need to pass messages through a cloud, for Avtivka virtual machines to validate, execute, and if successful, apply the transaction both to the real-time model and the transaction store. During the validation stage, Avtivka verifies that all incoming messages are authentic. To do this, different organisations would apply different solutions. Public organisations should stick to public-key cryptography, such as 4096-bit RSA, while some enterprises, which already make employees wear security cards, could easily integrate their security infrastructure with some authorisation service, either via one of the supported services or an API. The cloud should not insist on any particular solution for either the object, or the transaction stores. Our in-house offering Échos does, however, insist on the graph store, which it uses for all real-time modeling of discourse: Dgraph. So basically Échos can be deployed in a small corporate environment, with a silly FTP server on HDD in the basement serving as the object store for your Kubernetes cluster, while your MySQL database, set up in phpMyAdmin, shall be busy with the transactions. On the other hand, you could do it the right way: use IPFS for the object store, and Hedera for the transactions, just to be safe! Or maybe Storj/Arweave for the object store and something like IBM’s blockchain on K8s. That said, AVM (Avtivka VM) will probably compute much faster on MySQL and FTP.
If you were to describe the schema of the aforementioned messages in logos, it would end up looking somewhat like this:
Message :: Transaction := byte list. Signature := enigma.
I will explore the peculiar proposition of
enigma in one of the following notes.
Actor is a flexible abstraction, that leaves user authorisation completely up to implementation, which allows to integrate a cloud system with any authorisation scheme as long as an adapter for it can be done reliably.
Tuesday, 01 Oct 2019