OAAAAA - Obyte Autonomous Autonomous Agent Address Agent is working

Last week, I submitted a preliminary version of OAAAAA which was not working yet. This time, I am submitting a working version and I am going to explain here why I think why it deserves more attention.

From users perspective:

It is simply not feasible to constantly keep track of when and where, the Autonomous Agent (AA) they had previously used; has been updated due to a new feature or worst due to critical bug fix.

Not knowing this, users might continue to send payment to the already compromised agent. If they are vigilant, one thing they could very well do every time they wish to use an AA is to at least check with the author. However, as more multi-layered agents get used, this will becomes unmanageable.

From the author's perspective:

Even if a mistake in the code has been founded and corrected, there is no way to halt (kill -9) the old AA.

It's not too hard to imagine losses starts racking up, and problems cascading without end in sight.

OAAAAA was created with these kind of scenarios in mind.

To keep everyone up-to-date seamlessly and allowing the author some control, so damage is manageable and reputation / trust can be saved.

Another way to think of OAAAAA is that its an AA App Store which will keep track of the latest version submitted by the app developer. User or AA calls OAAAAA with the last AA address they trusted and it will automatically route to the latest address.

At this point, some will argue that AA is suppose to be autonomous and immutable, and I agree; but in the same breath I pose a question as to how confident a developer or a user that everything is correct and how much that confidence extends to other AA dependencies? If the confidence is high, then OAAAAA should not be used. Otherwise OAAAAA balances this with users giving more trust to the authors (whom I tend to trust to know what they are doing). There is still the option for user to not use OAAAAA and there is even an option for developer to assign authorship to a non-existing author, so the AA is effectively locked when the code is final and development has stopped.

The system is actually conceptually like a DNS registry where AA address is mapped to the latest AA address and only the author of an AA can transfer from old address to a new one. For more clear picture of this, take a look at the diagram above.

Since we're talking about a system like DNS registry, we can also consider OAAAAA as a property registry that keeps track of ownership of a property (perhaps implemented as a Prosaic contract) as it get passed from one owner to another, see how the diagram below is exactly like the one above.

Hopefully, AA developers and Address property owners now have to little better understanding on how OAAAAA generally works, and I hope they will consider using OAAAAA as an entry point and linker within their system to help manage code and property changes. A little bit of control in an otherwise non-controllable decentralized system might be helpful in halting damage and saving trust.