The previous note dealt primarily with the object of discourse.
In this note, I decided to have a go at subject of discourse straight away. The reason for that is trivial: I’m simply too tired to think about it any longer. It’s been bothering my mind for far too long now, to the point I can no longer stand the thought of it. Let’s talk authorization.
For the Standard discourse of Logos, a language language designed for the purpose of modeling arbitrary discourses, I came up with the following cryptic definition of actor and its only companion in existence, this.
{ 10. Actor is a iota of subjectivity. }
actor := iota.
{ 11. This is the currently speaking actor. }
this := actor.
this <- { current speaker }First thing you should notice, actor is not a trivial iota like boolean, but a more sophisticated one. Instead of plainly differentiating between different possibilitiess, it something outside the structure of text. I currently think of actors as human beings exclusively, but I’m yet to find an argument against robots, for example. You can’t quite fit a living person into a computer, so most modern cryptographic systems rely on special “keys,” sometimes referred to as “wallets.” The idea of actor is hardy defined, yet in some sense it’s the most real of all elementary propositions in logos; this is rather ironic.
{ It will never panic, because `this` is always defined. }
if this = void, then panic!
{ This, on the other hand, will. The `actor` sign itself
can never be defined. }
if actor = void, then panic!
So far, so good, but it’s all theory, and quite predictable at that. I try my best not to impress anyone with this, just desperate to point out why it’s important logos offers an elementary proposition for authorization. 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 void.
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 authorization 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 consensus, just to be safe! Or maybe Storj/Arweave for the object store and something akin to IBM blockchain, powered by Kubernetes.
That said, Avtivka virtual machine will probably compute more efficiently 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
Signature (enigma)
Transaction ::=
Version (integer)
Nonce
Payload (byte list)
{...}
Nonce := integer.
I will explore the peculiar proposition of enigma in one of the following notes.
Summary
Actor is a flexible abstraction, that leaves user authorization completely up to implementation, which allows to integrate a cloud system with any authorization scheme as long as an adapter for it can be done reliably.
(powered by Disqus)