Yes @cusma , avoiding other transaction types for app calls was intentional to avoid much unneccessary complexity and just have ABI calls in full supported by ARC 26 , which is long over due IMHO

It looks generally a good and useful addition.

I'm wondering, given that we are updating this spec, if wouldn't be a good opportunity to add not only a support for AppCall transactions but also for other transactions types (e.g. KeyRegistration).

Also, this makes me think that this spec does not clearly define a "transaction type" under which certain arguments are forbidden (e.g. trying to specify an method under a Payment transaction request).

EDIT: I have a lot of point TBD, like references to things that may change at runtime (depending on the execution path or the implementation), like: apps, boxes, accounts, assets, fees, etc.

I see these are being discussed on other channels, so I will defer my comments there.

I 100% agree but scenarios during which these ABI call URIs become useful are the ones in PR description: SOA interoperability and user-chain interaction. Example: A service or a dApp creates those in runtime based on a requirement and shows the QRCode to get user mobile consent during an interrupted flow (Like walletconnect itself) for security purposes.
I need to bri ng your attention to templating section as well! Using templating (ZeroAddress as Sender account address) any recipient wallet or dApp can replace connected user account and reconstruct a transaction from it which makes an ABI call.
Since the use case for ABI call URIs dictates it being created by the owner of the service/dApp which knows runtime requirements, it is safe to assume all those used params are known to URI issuer.
The issue with people in the channel is that when it comes to service architecture they see only a few scenarios and not the the whole story.

This PR especially can give rise to offline/indirect communications possibilities between dApps, services and users.

Another great example would be Authenticate with your mobile device:

• User logs into a dApp on desktop using NFD name (account address behind does the login to smart contract)
• Now user wants to login on smart TV or another desktop without re-entering credentials
• Smart TV creates an Algorand URI to an ABI call for user account with smart TV serial number as arg to dApp and pops the QRCode
• User scans QRCode with wallet which is compliant to ARC26+this PR
• The transaction gets generated on mobile wallet , signed with account in URI if availabel on wallet and sent
• dApp on Smart TV or another desktop (subscribed to ASC events) listens and receives the TXN on ledger and checks serial number and user account and lets user in

Please add network attribute with genesis name
Please add more examples mainly how to use the note field

Lets please create arc260 for QRs with the protocol definition avm+web://arc260?txs=base64url([tx1,tx2,..]) where tx1 is the uint8 of the algosdk signed or unsigned tx.

This will solve the issues

• any app call can be signed using qr code - pay,axfer,app,keyreg, unreg...
• multiple transactions can be requested to be signed at once (pay, and call appcall)
• note field issues
• restriction to specific round
• restriction to specific network
• sender not defined

Please add network attribute with genesis name Please add more examples mainly how to use the note field

adding examples for the note field is out of this PRs scope but sure I will add those during weekend.
The rest of the comments should be under a separate topic as those are not the subject of this specific PR. I add those to the general ARC26 discussion.

There is an arc26-like implementation in the wild that implements keyregs, which would be good to standardize in light of incentives rolling out soon.
Now that arc26 will cover more than just pay and axfer types, it would be good to have an explicit type= or txtype= parameter to disambiguate (as opposed to figuring it out from fields present/missing.)
For backwards compatibility, this would have to be optional for payments and asset transfers, but imo app calls and keyregs should require it.

Thank you so much @tasosbit. Great point and it will be added to this PR as soon as possible.

There is an arc26-like implementation in the wild that implements keyregs, which would be good to standardize in light of incentives rolling out soon.
Now that arc26 will cover more than just pay and axfer types, it would be good to have an explicit type= or txtype= parameter to disambiguate (as opposed to figuring it out from fields present/missing.)

I very much agree! @emg110 I had the same request in my previous comment.

100% agree and WIP. It will be done ASAP. Million thanks @cusma

Closed in favor of ARC -79