Standardization of Application-related Data

Applications
20

I want to summarize all the pieces of information I got so far (from this thread, but also by talking to @mariari, @paulcadman, and @cwgoes).

Indexing and Decoding

Context
Users using are interested in querying for unspent resources (i.e., “I want to know all Kudos resources that I own”). We assume that users will be offline sometimes. An indexer provides this information as a service to users.

This is how I understand that indexing works in v0.2 and as per Ray’s post:

  1. An indexer runs an Anoma node and stores resource objects being visible to them in their local storage.
  2. On user request, indexers query (scry) the set of all unspent resources, with a filtering function.
  3. The filtering function filters the set of unspent resources for certain properties (e.g., the owner information) and is written in Juvix. No gRPC calls need to happen, and no shell scripts or makefiles need to be written.
  4. The resource set after filtering is communicated to the requesting client of the user.

Problem / Constraints
In Juvix we cannot have a maybeDecode – as soon as a resource with a wrong encoding is encountered, the filtering-algorithm will crash. This is the motivation for the proposal by the Juvix team requiring a certain encoding format.

Furthermore, we wish to NOT specify (i.e., require in the RM specs) that resource and application-related data fields must have a specific format (e.g., to be a map).

Talking to @cwgoes, I confirmed that we want general indexers for the devnets in contrast to dedicated/specialized indexers for specific applications.

Solution
Indexing/filtering of resources requires a way to decode resource data without crashing.
For this to be possible in Juvix, @mariari told me that the proposal by the Juvix team is considered and something in this direction will be implemented as a first stab.
The discussions on how to make this decoding safer should be continued.

Solving and Decoding

General solving is, obviously, not possible, and solvers need to be implemented for specific use cases.
Nevertheless, the topic of decoding is important. Solvers need to filter the intent pool for intents (unbalanced transactions) to understand what the constraints are and how to solve them.
This means that solvers have to look for certain actions and resources within expressing those constraints. As for indexers, this requires solvers to decode resource object data to understand intent resources and constraints they carry. Specific intent formats have already emerged and we can expect more formats to emerge.

Documenting Standards

I still think that it is important to have a place where we write down conventions around topics like the above for specific versions. I would still call these standards as those can be temporary, deprecated, and superseded.

This includes questions like

that we haven’t discussed much in this thread.

1 Like