[ARC-90] Consolidation of URI schemes + network handling

[SudoWeezy]

Summary

• Consolidate ARC-26/78/79/82 into a single ARC-0090 document with full metadata and shared context.
• Introduce a unified ABNF overview that defines common tokens (network selectors, query primitives) once and reference it from each scheme section.
• Add network selection guidance (gh/gid/net) with resolution rules, examples, and ensure every scheme documents the shared selectors alongside its specific parameters.

[cusma]

@SudoWeezy I think consolidating all URI-related ARCs is a good move to avoid fragmentation.

I would suggest the following improvements:

• I would avoid using the Genesis Hash (GH) as query parameter, I would prefer something like algorand://gh:<testnet_gh>/app/...
• The gh MUST be omitted for MainNet (to preserve backward compatibility)
• Since the Genesis ID is just a human readable label, which does not offer any uniqueness guarantee, I would make use it as an informational label (not authoritative) which must not conflicts with the gh parameter
• I would add a section for ARC declaration in the URI pointing to data or apps conforming to specific ARCs, I propose to follow the ARC-3 approach using a suffix and + to declare multiple ARCs in the same URI. In ARC-89: ASA Metadata Registry #356 I'm proposing #arc89+arc3 to declare the Asset Metadata ARCs in the ASA Metadata Registry URI. I don't know if we should mandate that ARCs label must be ordered by ARC number (so #arc3+arc89) in this case. It would also be good to add a Regex for clients (and SDKs) to extract the ARC labels from the URI suffix.
• Wouldn't be a good time to extend also the URI for other transaction types (axfer, afrz, etc.)?

[SudoWeezy]

I added the following:

Algorand URIs that need to declare conformance with multiple ARC MUST encode that declaration in the URI fragment using the pattern #arc<A>+<B>+<C>

[scholtz]

can we use official genesis name like mainnet-v1.0 please? or if testnet is the algorand testnet-v1.0 can someone create mapping for known netlables to genesis ids?

[scholtz]

ARC26 is missing the sender definition.. can we add one of the params to be sender please? The sender is important for QR code receivers - wallets so that they do not have to setup special UX to select account when they want to process the transaction. much better is if frontend is already connected to the wallet and knows who is the sender just to pass it in parameter.

[SudoWeezy]

We can consider adding a from parameter to ARC-90 as an optional, advisory field.
Something like:
fromparam = "from=" algorandaddress

from: Optional sender account address.
Wallets MAY use this to pre-select the account initiating the transaction,
but MUST verify that the provided address belongs to the user before constructing or signing any transaction.
If the address is not recognized or available, wallets MUST ignore this parameter.

It still needs to be talked about before it's included.