[ARC-62 ] Add ARC-82 URI discoverability

[cusma]

Following the feedback of the Developer Council, given the finalization of ARC-82, the spec has been updated with a Circulating Supply App discovery method based directly on ASA URL, as:

algorand://app/123

Deployed example.

This approach improves the responsiveness of the client's discovery process, as it needs just Algod (and not the Indexer or IPFS, which may introduce delay, resulting in bad UX).

I'm still thinking if an "ARC specific" prefix should be added to provide more clarity in the discovery, as-in:

arc62:algorand://app/123

Tests, deployment, and examples have been updated to reflect the new spec.

[emg110]

I want to propose:

• let's use URI params for asset under app as algorand://app/123?asset=ASSET_UUIDV4 (Compatible with ARC82)
• For Asset UUID V4 , in smart contract, we can use timestamp(Big Endian low and high) , txn Sender(byte Slice of it), CurrentApplicationID(byte slice of it), UUID V4 needed constants as bytes and sha256 opcode to consruct a valid and unique UUID V4 inside the contract when or prior to minting asset.
• Asset UUIDV4 can be used as box name that stores asset metadata , Circulating Supply,...therefore both asset full mutability and Circulating Supply can be achieved.
• We can also use method param to specify what we need arc62_get_circulating_supply or get_metadata (default to metadata if no method provided)
• With this approach these asset UUIDs can be integrated into asset DIDs (already available through allo.info and ThisDID.com) in alsoKnownAs section as DID:ALGO:MAINNET:ASSET:ASSET_UUIDV4 for further use-cases. This enhances Algorand assets identifiability as well.
• With this approach ARC 19 will not be needed to achieve asset mutability and reserve address stays ready for ARC62 circulating supply implementation.
  Note: the implementation for circulating supply, metadata or both will be optional for development time as well.

I think @SudoWeezy as well had something similar (using box refs for Asset URLs) in mind for asset mutability beyond ARC 19.

I can provide a rapid ref implementation if you are interested @cusma.

[cusma]

@emg110 thanks for taking the time to make a proposal. IIUC, this is a new general way of declaring mutable ASA metadata, which requires deploying App and Boxes. Is yet another standard that Explorers and Wallets need to adopt (and it's a bit convoluted IMHO). I'm trying to achieve an ASA:App biding just using ASA (no ancillary external registry, like App boxes). I'd like to be able to just add a "method" optional query parameter on the App ID, following existing URI standards (like ARC-82 does), so something like: algorand://app/123?method=<method_selector>.

[cusma]

@emg110, following up on ARC-79, it could be a solution, but the ARC specifies a transaction rather than an "entity" on the ledger to point to.

IIUC ARC-79 mandates:

• Specifying the sender of the transaction (but in ARC-62 we have no Sender)
• Specifying the args of a method call after the method signature (but in ARC-62 I can not specify the args associated with the ASA ID, since the ASA URL is set on asset config before the ASA ID generation)

So something like:

algorand://app=123&method=arc62_get_circulating_supply(uint64)uint64

Does not conform to the specification.

@SudoWeezy I think the problem is that ARC-82 specifies how to "query an entity" from the Ledger, while ARC-79 defines how to "interact with an entity" on the Ledger. I'm operating in a middle grey area between the two (since I need to point to the entity, specifying a generic interaction).

[SudoWeezy]

@cusma

algorand://app=123&method=arc62_get_circulating_supply(uint64)uint64

This almost conforms to ARC79
You are just missing the algorandaddress = *base32 param.

algorand://any?type=appl&app=123&method=arc62_get_circulating_supply(uint64)uint64

You can replace any with any address, or we can put the app address.
@emg110 do you see any issue with this use of ARC79?

[cusma]

@SudoWeezy right! The args value after the method signature are optional, right?

[SudoWeezy]

@SudoWeezy right! The args value after the method signature are optional, right?

I think they can be omitted if they are not needed when you call the app.

[cusma]

I think they can be omitted if they are not needed when you call the app.

The args are needed because the are in the method signature (which does not admit "optional" args). The problem is that I can not specify the value of the args at ASA creation time (since it's equal to the ASA ID). We can specify this in the specs (e.g., the value of the uint64 in the call specified by the ASA URL MUST be equal to the ASA ID) but I'd like to be sure this does not violate the ARC-79 specs (cc: @emg110).

[SudoWeezy]

The args are needed because the are in the method signature (which does not admit "optional" args).

We can use a template approach like args=<asa_is>. The issue we will face is the max size of the URI is only 96.
If we respect the ARC79, we need to use the zero address to template the app call
algorand://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY5HFKQ?type=appl&app=123&method=arc62_get_circulating_supply(uint64)uint64&args=<asa_id>.

If we can avoid naming the method and just read the value from the box(or global) it could be solved with something like this:
algorand://app/123?box=arc_62_<asset_id>

[cusma]

In my opinion, relying on Boxes, GlobalVar, etc., to publish metadata on-chain is not in scope for this ARC since it starts resembling a dedicated ARC to publish an AppSpec on-chain.

Imagine an ASA that relies on a single App ID supporting different ARCs, for example, a Smart ASA (ARC-20) that exposes an ARC-62 getter for its circulating supply.

Off-chain metadata (e.g., ARC-3) would look like this:

{
  //...
  "properties": {
    //...
    "arc-20": {
      "application-id": 123
    },
    "arc-62": {
      "application-id": 123
    }
  }
  //...
}

Then, clients will use the ARC-20 and ARC-62 AppSpecs. I assume that clients like wallets and explorers already have the AppSpecs on their side.

The on-chain case is not different, we just need to formalize this on-chain: "This ASA ID is linked to this App ID, which implements ARC-62" (I don't care about how the client got the AppSpec).

• ARC-82 solves "This ASA ID is linked to this App ID" part;
• While the "which implements ARC-62" is the missing bit (the full method signature is already in the AppSpec).

[cusma]

I’m closing this PR due to a lack of agreement.

The scope of the proposal was an additional method to declare the ASA-AppID relationship on chain, to avoid external dependency on IPFS, which is suboptimal since it forces explorers, wallets, and clients in general to rely on external infrastructure (with maintenance, costs, and latency).

I DO think we still need a better way to declare simple information like the ASA-AppID relationship without IPFS (ARC-3, ARC-19) and Indexer (ARC-69).

This becomes even more crucial considering the work @joe-p proposes in #341.

My proposal would still use an ARC-82 URI on the ASA to point to the App unless there are better options.

I want to push this discussion forward in the Developer Council before re-opening a PR.