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.
I am increasingly of the belief that we might need to build our own GUI that is not a web browser extension for the best UX.
people really like using applications that are not web browser based. Slack is a perfect example of this. And if you do some product testing with many of the newer wallets or their upgrades, they attempt to have a sidebar extension which makes the wallet feel like its own app, but low and behold still attached to the web browser.
the advantage i see here is customizability whereby the user could craft their intent similar to Uber, talk to an LLM, or just click colorful buttons which say send or swap or deposit for example. It appears that most infra projects that build networks do indeed focus on custom wallets, near wallet for example, or seed teams to build these things Solflare, Phantom, Backpack in the case of Solana. Rollups just seem to punt on this mostly because there is a plethora of EVM wallet developers with existing network effects like; Rabbi, Metamask, Safe, etc.
while I’m not sure if we would be able to build something like this in time for a go-to market as it requires time / testing / feedback cycles. It is definitely worth thinking about eventually. this was along the idea of Anoma as a super app we discussed previously.
in general, individual end-user facing applications could build their own. I think the idea of relying on the base layer for distribution is antiquated and that ultimately it will be more about access to cheap liquidity and custom features for developers.
for example, if you build on Ethereum today, the EF is not doing anything to help you with distribution vs. their venture funded counterparts.
What in your view is/are the best example(s) of this, that we could take as reference?
I’m not quite following here. Are you saying that applications will achieve distribution by access to cheap liquidity or custom features, that base layers will compete not on helping with distribution but instead on custom features, or something else?
To me “distribution” means roughly “a process that results in a user becoming aware of the affordances of and potentially using a particular application”. Liquidity or features might be part of that, but they would never be the whole story (since no “user” is included in either of those concepts). What concept of “distribution” do you have in mind here?
by distribution here i mean, if you build on my chain then i have ecosystem team, marketing, grants, hype campaigns, and general network effects to help you get users. this is what most if not all new application platforms promise to application builders either explicitly with programs or implicitly. different base layers choose different approaches. Let’s take Avalanche Rush, as an example. Ava Labs funded a program that incentivized applications to deploy there and subsidized usage of those applications with liquidity mining programs (extra staking yield in practice - on top of lending/borrowing products or LP rewards for AMMs). During this time the most popular application was a DeFi ponzi scheme called Wonderland, as well as Trader Joe, a DEX. Without the incentive programs neither of these applications would have achieved meaningful distribution.
looking forward, my claim is that – If the application you are building is abstracted away from the end-user through some type of meta- LLM interface then you will probably have to build your own otherwise whoever builds the popular GUI will capture all of the order flow and users. Traditionally front-ends (web browser) were part of building applications. In the future they might not be. to make things more challenging, if the meta-LLM GUI can access any application on any chain, then there is almost no reason to build a front-end (website) at all. So then how do you get distribution? You need to be discoverable. In particular, something like the apple app store is table stakes for mobile. but I’m not quite sure how you build a business unless you build your own GUI.
