Questions I want to see researched

[mariari]

@concordance

Architecturally, it sounds like you describe a client-server architecture, where developers run an Anoma client node, and a unix/windows machine with FFI mechanisms and sockets for relays. (Please correct my understanding, I am not sure if you are stating that the Anoma client can act as a genserver using Erlang)

I do think because of Anoma’s structure, there is an alternative; a client-blockchain architecture.

There are many ways this can be implemented, but my current imaginings is a verifiable client-side system that proxies directly to the Anoma client. (I building the client-side isolate, almost like a runtime environment.)

The first diagram isn’t quite right, Genservers are abstractions over a light weight process that can send and receive messages (called an actor model), if you are familiar with the Java world, Akka took this idea and applied it to the JVM. So for the Anoma case, you’d be able to spin up your own Genservers (we call them Engines) inside of the Anoma client. The Anoma client also has storage so it is a database of sorts as well.

So I’d imagine it is something like this

This model can work as however you see fit, so for example the client blockchain architecture would fall out of this, as this model doesn’t prescribe any forced way of working, you can with some code inside of the Client setup your client-blockchain architecture and then work outside the system.

However, I suspect if one is building tools up from the ground at that point it would be simpler to just build inside of the Anoma OS itself, since it should be trivial to spin up various chains and just do general operations. Much like how we get a lot of benefit from working within Erlang with genservers and their supervision architecture. This becomes harder to use when we have to mix a lot of things into the mix and we’d typically reach for other tools.

I’d be curious on the particular benefits of the runtime that you imagine, as the Anoma Client is basically a runtime of the operating system, I explain it in a bit more detail in this presentation I gave:

On the System of Anoma - Anoma Research Day - Jeremy Ornelas

Looking at your four points I believe this should all be easily possible from within the Anoma Client (from here on out I’m going to call it the local domain), since it is the local anoma operating system, meaning you have 1 unified language to work through everything.

@concordance

This dual model exists in cloud offerings. You can run your own server instance in the cloud, or you can run serverless functions, which execute without you having to create a server instance. It feels like you describe the former, and I describe the latter.

I believe we are describing the same thing, a lot of the power of Anoma comes from the local domain I believe.

@concordance

Does this mean developers define the ports and connection between the Anoma client and other ‘server-side’ systems so that their application code can call the Anoma client and change the resource state? And the Anoma client can act ‘asynchronously’ because of the multi-threaded long-running processes?

This means that inside your local domain you can have certain engines (genservers/actors/processes that accept messages) that subscribe to certain controllers you are interested in. If you are interested in talking to a system outside of Anoma (some legacy codebase, or any other system), you’d then have that engine send a message out via port or FFI to the application outside of Anoma. Just the same as how you’d have any programming language talk to another programming language inside of Unix.

@concordance

I am still having trouble bifurcating the controllers vs the engines vs machines in Anoma.. Any references for this would be much appreciated!

So engines live inside of the local domain, I think they can potentially live inside of controllers as well (no consensus here), you can have millions of them in one local domain (much like genservers). The controller is the distributed state machine. The local domain is your personal Anoma operating system where data is private to itself (however you can send this data over controllers. Even ones you fully control).

@concordance

I will continue to look into FFI, but I imagine making the threshold for outside systems meld to Anoma compute, so although computation is happening outside of the Anoma ecosystem, the traits and benefits of blockchain-based compute are extending into that environment.

Yeah I like this line of thinking, one huge selling point that I view of the project is that we are offering a computing platform that offers easy to get custom computing between untrusted parties (much like how the innovation of Erlang was to offer a simple model for doing parallel computation among parties that trust each other).

@concordance

I used this to guide my understanding of the system I put in the motivation section above. It looks like Eric and the CPP program are trusted operator(s) in this dominion? As in, members of the dominion trust Eric’s unix system to participate in the process, and trust that Eric’s changes were computed and performed honestly?

The fun part is, nothing about the CPP program has to be trusted. The truth condition of the objects we are making insist that everyone’s time is satisfied for them to be considered valid. Meaning that if Eric’s program had a bug and computed the wrong result, the pickup game intents would not be solved and a different solution must be given!

@concordance

Yes! I see these machines together (user machine and Anoma client) essentially emulating a web2 server environment. I would love to see the demo.

I believe this was me referring to mapping objects down to resources, as how I do operations, lets most computation vanish with only the results and important state changes being posted.

@concordance

Yes, yes, I imagine a very similar interface for developers to view the object structure.
I want to understand more about the short term plan to hook Anoma into existing tools, as I was planning to create this platform.

We have 2 plans for the short term:

The first being An operator dashboard where one can run Juvix, Anoma Level, and Elixir and operate the entire system from within.

• This would be done with Phenoix and be a web application for the web.
• I don’t think we can get any good presentation systems here… we can but it’d take work (Konrad’s Hinsen’s HyperDoc demo comes to mind https://hyperdoc.khinsen.net/)
  The second being that in my free time I’ve been experimenting with hooking up Elixir to Glamorous Toolkit. GT is a pretty decent environment in that it allows other languages to get graphical view

This can be seen for python here:

gt4python: Working with Python inside Glamorous Toolkit

Adding gtViews to the existing Python pandas DataFrame and Series class

And my incomplete experimentation can be seen here:

• 
• 

Above I have messages being sent from my Elixir Image locally to the GT environment. I haven’t finished it yet, but if it goes well and we get some nice guis for Elixir, I plan on implementing an Anoma<->GT bridge, by implementing a bridge for the Anoma Level programming language/environment, which should be quite simple given that Anoma Level is a lisp and that Anoma level is live. Namely we can take advantage of the fact that the local domain allows ports to be opened to open up a TCP port and hook it up with GT.

This means that our dashboard from 1. can have a desktop version with enhanced visuals for objects while people program and debug and a web version which is a less moldable/observable experience. The main benefit of this approach is that we can reuse a rich environment that makes it easy for people to write tools for any object they care about, and offer the first image based editor for Anoma.

I plan to have with this connection, have the GT environment be able to browse the code storage of the Anoma OS and be able to visualize all the code that is there without having to go to a website and find out what libraries are stored where, meaning that all this can be done from within the user’s operating environment that they were already writing code from.