What would the application requirements look like for “minimum viable distributed Anoma coordination”? First, let’s define what this means. I define “minimum viable distributed Anoma coordination” as a hybrid setup where essential parts of the coordination mechanisms can be run on Anoma (and thereby distributed), while other parts still likely not run on Anoma (e.g. video calls) can be performed either with existing E2E encrypted centralized or decentralized software - and where all the key data required to continue coordination is distributed and autonomously controlled.
By this definition, essential parts include:
payments / compensation for work performed, e.g. scale-free kudos
promise tracking, e.g. promise graph
knowledge aggregation, e.g. knowledge graph
code management, e.g. git hosting and canonical reference tracking
ephemeral structured chat, e.g. multichat
Inessential parts include:
E2E encrypted video and audio calls, for which sufficiently secure/decentralized alternatives exist, and which we can easily switch (no long-term data or ontology)
Email, which will always be a legacy system, and for which sufficiently secure/decentralized alternatives exist, and which we can easily switch (no long-term data or ontology)
We should also consider that we may be able to hook up Anoma as a “distributed database backend” to existing frontends which have solved many of the frontend problems. For example, something like Anytype (which has their own, albeit less general, synchronization protocol), could potentially be a suitable frontend for Knowledge Graph.
An interesting question is whether these essential applications should have separate or unified frontends.
In my discussions with @Michael about anoma applications it became clear that composable applications or primitives would be a big upside.
E.g. a multichat primitive will come in handy for a lot of different use cases and it doesn’t make sense for every user facing application to roll their own.
So we should figure out how to make the above mentioned primitives as reusable as possible, which is feasible if we are only talking about APIs between components, but its not entirely clear to me how composition would work, e.g. on the UI/UX side.
We probably want to think more about what the commonalities of the objects which are used by the primitives you listed are and what kind of unification in frontend they need, e.g:
Should multichat always get presented the same way within apps that use it, or might app devs want to have lightweight views/abstractions on top of it?
Should kudos just provide a default context menu, or are application specific integrations that do not share common logic neccessary?
If the frontends always have a full anoma node running underneath, we should be able to realize the above and we probably want to draw inspiration from smalltalk or other similar systems (@mariari).
UI/UX and systems people will have a more nuanced perspective on that, but I think while building the first user facing applications should give us good information if the component and view boundaries that we picked make sense.
Here I generally agree that switching cost and permanence of data are good criteria for choosing which ones to focus on first.
I agree that composability is desirable.
Our engine architecture facilitates this.
Applications can be considered as user-facing engines.
After authenticating with a local or remote node,
an application can send and receive messages from engines relevant to them,
and various apps could also send messages among each other, if necessary.
uses a CRDT DAG that looks promising, protocol details haven’t looked at yet
concern: looking at their pricing page, the maximum number of editors supported per space is 10, which may be due to some severe scalability limitation in their protocol stack (unconfirmed)
If we think about the mobile user, in an ideal world, the user just downloads an “Anoma App” on their device, opens the application and can start making decisions w.r.t. customizations/ layout preferences. This is how many people use applications today.
The simpler it is to access Anoma applications, discover them, the quicker they will gain in popularity. Even if say in 5 years, the end user (non-crypto in particular) just thinks of Anoma assuper application, that’s maybe not a bad thing; towards unseating legacy tech startups. In fact, this is a common school of thought for many Asian tech startups I’m told. In addition, there could be a desktop/browser version.
Alternatively – thinking about MacOS. The initial primitives for any user before purchasing from the app store:
itunes
mail
safari
notes
calendar
This is the opposite of a super app. “Separate” applications which are composable.
Indeed, I think it is critical that developers can have their choice to combine or build only one of these essential parts as “standalone” application(s).
Agree 100%. Compossable primitives is table stakes.
Agreed. I wonder if we can draw some inspiration from the operating systems design (and operating systems UX design) literature here - a lot of what we would want to be standardized on the UI/UX side would be some sort of “object” - e.g. a kudo resource is an object with particular actions that can be taken on it (send, swap, …). It’s tricky though.
I do think that there’s a strong case for multiple views in the case of multichat. For example, one view of multichat could look like Discord, and another view could look like Discourse - ultimately, the actual logic of these different forums and chat platforms tends to converge, only the views and some specific details differ.
I think this is a safe assumption, although we will need to be specific about what we mean by “full node” - many edge devices would have an Anoma node running, but it wouldn’t be syncing all the data, probably only very specific pieces of data relevant to the applications of interest to the user.
I hadn’t been thinking exactly along these lines before, but it’s an interesting direction. If we do this properly we could achieve a very nice “device independence” property, where a user’s state w.r.t. the operating system (even “local application state”) is tied to their own trust domain (thereby e.g. automatically synchronized across devices). An interesting way to try this out is to see if we can write applications in a way which avoids any state outside of Anoma - e.g. web interface, native Android/iOS applications etc. are stateless and simply allow to query and write to Anoma in different ways.
Regarding compositionality and user interfaces, I want to highlight once more the library that I stumbled upon, when reading about alternatives to the Model-View-Controller (MVC) pattern (and that interestingly uses the Model-View-Intent (MVI) pattern):
Composable
Cycle.js has components, but unlike other frameworks, every single Cycle.js app, no matter how complex, is a function that can be reused in a larger Cycle.js app.
Sources and sinks are the interface between the application and the drivers, but they are also the interface between a child component and its parent. Cycle.js components can be simply GUI widgets like in other frameworks, but they are not limited to GUIs only. You can make Web Audio components, network requests components, and others, since the sources/sinks interface is not exclusive to the DOM.
It’s functional and reactive (it defines streams that components can listen to, which fits with Anoma’s pub-sub model) and the unidirectional flow ->model->view->intent-> is exactly how applications will work.
