# Resource Machine Applications **URL:** \ **Category:** ART\ **Created:** [June 11, 2024, 11:33am UTC](https://forum.anoma.net/t/resource-machine-applications/606 "2024-06-11T11:33:54Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![degregat](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/degregat/32/449_2.png) [@degregat](https://forum.anoma.net/u/degregat)\ **Post date:** [June 11, 2024, 11:33am UTC](https://forum.anoma.net/t/resource-machine-applications/606/1 "2024-06-11T11:33:54Z")
This report will contain motivations and definitions of applications of the anoma protocol. ## v1 In v1 of the report, we will focus on applications that function as “primitives” the system needs for its operation. ### Kudos [Thread](https://forum.anoma.net/t/scale-free-kudos-brainstorming-thread/217) ### Governance [Thread](https://forum.anoma.net/t/sketch-of-possible-anoma-governance-system-intent-centric-governance/486/2) For both of the above, we should focus on anything relevant to the implementation and try to at most sketch the mechanism design problems, to be researched in followup reports, if we can not cite pre-existing results. ## v2 I propose to move multichat and public signal into v2 of this report [(contrary to this thread)](https://forum.anoma.net/t/basic-kudos-multichat-and-public-signal-applications/561) and start work on it as soon as all more potential engineering blocks have been resolved. This could be immediately after the release of v1. ### Multichat [Thread](https://forum.anoma.net/t/draft-rfc-dreaming-of-multichat-a-chat-application-built-with-anoma/515) ### Public Signal [Thread](https://forum.anoma.net/t/public-signal-brainstorming-thread/218) ## v3 I propose to also work out details of modular logistics, since it is a great example to show a more complex, user facing application that leverages intent matching and kudos. ### Modular Logistics [Thread](https://forum.anoma.net/t/modular-logistics-brainstorming-thread/219) ---
**Author:** ![Michael](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/michael/32/434_2.png) [@Michael](https://forum.anoma.net/u/Michael)\ **Post date:** [June 11, 2024, 5:11pm UTC](https://forum.anoma.net/t/resource-machine-applications/606/2 "2024-06-11T17:11:06Z")
After a brainstorming session with @cwgoes, we defined the scope for the Applications ART as follows: The goal is to - provide a clear understanding of how applications practically work - define initial versions of applications and implementations Accordingly, we want to first explain the general structure of applications - resource logics - resources (state) - transaction functions aided by diagrams visualizing intent/tx flow (in particular for apps having state in multiple places). In this context, we also want to explain how applications connect to other components in Anoma’s architectural topology - Storage of resource logics and resources in the data availability domain - persistent vs. temporary - incentivized - conditional (e.g., store data until the transaction has been executed) - Indexers (which could be another node role) - computes properties of application state, (e.g., the sum of unspent kudos resources = kudos balance) - ideally composable (e.g., to index the balances at block 105, I can use an already indexed balances from block 0-100, and just index the remaining 5 blocks) - Composition of applications - e.g., the intent of user A: “Increment a counter and send a Multichat message with the new value to user B” in one transaction - Interaction of UIs with applications Before defining applications, we introduce common primitives/patterns - Resource Initialization - Counter - Account - Expressing ownership - Token (fungible + non-fungible) - Dynamic code loading On the application side, we focus on - Kudos - Multichat with the following feature set: - Channel resource kind - Channel has publishers who can post messages - Channel has subscribers who want to read messages - A transaction to send a message simply - Increments the counter in the channel resource (consumes old channel, creates new channel) - Channel resource logic can check that a signature over the message from one of the publishers is included + valid - Stores a message which is a data blob encrypted to the subscribers associated with this counter - Proof-of-stake - Public Signal In order to be able to provide concrete Juvix examples, Chris asked @mariari if we can fix the [discrepancies between the Anoma node implementations and the ARM](https://hackmd.io/@heliax/Hyt-Kc-rA#Wrong-definitions-of-Resource-and-Transaction-fields) (that translated into the `juvix-anoma-stdlib`) soon. ---
**Author:** ![Michael](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/michael/32/434_2.png) [@Michael](https://forum.anoma.net/u/Michael)\ **Post date:** [June 13, 2024, 4:53pm UTC](https://forum.anoma.net/t/resource-machine-applications/606/3 "2024-06-13T16:53:10Z")
I’ve added “resource initialization” as a pattern because this is not straightforward. Let’s say we have a token `T` with a fixed supply of `100`. The RM makes sure for each transaction that the number of consumed and created `T`s balances to `0`. To initialize the supply of `100 T`, we consume an ephemeral `100 T'` resource, allowing us to create `100 T` after encoding this special case in the resource logic function. However, how can we make sure that this special case can happen exactly once and not be repeated? Am I missing something here @vveiln? A simple solution could be to require a specific `r.cm` to be present in the transaction via `T`s logic function. Since resource commitments are unique (because of `nonce` and `rseed`) this would guarantee that this can only happen once. I haven’t thought about the implications for the shielded case yet. As this resource initialization has its caveats (also the use of `ephemeral`), I wonder if it could make sense to have an abstraction for this. ---
**Author:** ![vveiln](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/vveiln/32/60_2.png) [@vveiln](https://forum.anoma.net/u/vveiln)\ **Post date:** [June 14, 2024, 9:08am UTC](https://forum.anoma.net/t/resource-machine-applications/606/4 "2024-06-14T09:08:53Z")
> However, how can we make sure that this special case can happen exactly once and not be repeated? One simple way to do that is to require a signature from e.g. a controller for the init case > A simple solution could be to require a specific `r.cm` to be present in the transaction via `T` s logic function I think you cannot hardcode the commitment in the resource logic because you would have to know the commitment in advance and you can’t know it before you create the resource, for which you need the logic I think [Forall / negative checks in resource logics](https://forum.anoma.net/t/forall-negative-checks-in-resource-logics/336) might be a helpful thread to read ---
**Author:** ![Michael](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/michael/32/434_2.png) [@Michael](https://forum.anoma.net/u/Michael)\ **Post date:** [June 14, 2024, 10:11am UTC](https://forum.anoma.net/t/resource-machine-applications/606/5 "2024-06-14T10:11:36Z")
Yes, the commitment would need to be done in a previous transaction, which is less than ideal. ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [June 14, 2024, 10:45am UTC](https://forum.anoma.net/t/resource-machine-applications/606/6 "2024-06-14T10:45:05Z")
You don’t necessarily need a signature from the controller. Maybe we should have some kind of standard sentinel resource of which each controller has one that you can read / insert map entries into (in some referenced storage), and for this case simply check the non-existence of a map entry (the first time the 100 T’ is initialized), and write the map entry so that it cannot be initialized again. ---
**Author:** ![degregat](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/degregat/32/449_2.png) [@degregat](https://forum.anoma.net/u/degregat)\ **Post date:** [June 26, 2024, 10:20am UTC](https://forum.anoma.net/t/resource-machine-applications/606/7 "2024-06-26T10:20:15Z")
Some more notes after a discussion with @cwgoes : ## Report Goals With v1 of the report one of the goals the examples should be in service of is to render the models as clear as possible. @Michael has been making great progress so far on outlining the developer workflow, including identifying and specifying common patterns that will be used, which is a great basis for introducing and explaining the examples. Some of the needed patterns are still not clearly defined, and e.g. in authorization there are some choices to be made, but for now it seems most useful to figure out solutions that are straightforward and useful for the concrete example applications. We might figure out different types of authorization are going to be needed in the long term and its fine to iterate on the model we come up with now. Also, the initial scope seems a bit ambitious, so maybe something like the following makes more sense: ## v1 ### Kudos For Kudos we want the following functionalities: - create - send - swap - calculate balances of identities, subject to available information given a users view of the network. With these, we should be able cover initial use cases and we can refine if we notice anything is missing after a few examples. ### Multichat: Given the featureset @Michael [described](https://forum.anoma.net/t/resource-machine-applications/606/2), we want to clarify how the application model deals with heterogenous trust and how that increases optionality. For example, why and how is this qualitatively different from existing chat solutions? ### PoS @vveiln specified PoS already, which we can just include in v1 ## v2: ### Governance We should figure out a minimal useful example for e.g. voting which is sufficiently non-trivial to clarify the application model. Voting could look like this, in a first order approximation: - propose and action and encode it as a resource - have specific identities vote on it within some specified timeframe ### Public Signal ---
**Author:** ![Michael](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/michael/32/434_2.png) [@Michael](https://forum.anoma.net/u/Michael)\ **Post date:** [June 26, 2024, 1:39pm UTC](https://forum.anoma.net/t/resource-machine-applications/606/8 "2024-06-26T13:39:01Z")
> the initial scope seems a bit ambitious, I would appreciate limiting and locking the scope a bit. I noticed that I am moving between too many topics currently. Related to the kudos feature set, we should be specific. Does the following sound reasonable? - `create`: creates an amount a of Kudos A for another address (that can differ from the address of the creator). - `send`: sends an amount a to an address, where a can be the full or partial quantity of a resource. - `swap`: Sends an amount a of Kudos A to an address and requires another amount b of Kudos B to be sent from the receiver address. - Multiple `create`, `send`, and `swap` calls can be part of one transaction. The latter is not straightforward w.r.t. resource logics and required signatures. However, I would like if we can get the functionalities in v1 to be atomic and composable. > calculate balances of identities, subject to available information How can we do this currently? ---
**Author:** ![degregat](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/degregat/32/449_2.png) [@degregat](https://forum.anoma.net/u/degregat)\ **Post date:** [June 26, 2024, 1:43pm UTC](https://forum.anoma.net/t/resource-machine-applications/606/9 "2024-06-26T13:43:58Z")
If you feel the scope should be tighter, that is probably the right call! Your `create`, `send` and `swap` definitions sound reasonable. For balance calculation, it depends on data retrieval, so its fine to postpone this until after retrieval is clarified, or use it as a guiding example to clarify the retrieval interface. ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [June 26, 2024, 3:26pm UTC](https://forum.anoma.net/t/resource-machine-applications/606/10 "2024-06-26T15:26:35Z")
@Michael The scope reduction and your proposal for kudos makes sense to me as well. > [@degregat](#): > > For balance calculation, it depends on data retrieval, so its fine to postpone this until after retrieval is clarified, or use it as a guiding example to clarify the retrieval interface. I think we should be able to cover this one - balance calculation just requires adding all the amounts of the kudos of a specific denomination owned by a specific identity.