Feature request: Hook namespace settings for special Xaman handling

[zgrguric]

To more empower devs to make most of Xaman and xApps and with addition of Hooks to the ecosystem I suggest adding functionality to Xaman which will allow it to read predefined (let say hashed xaman) namespace with set of predefined hookstate keys which can be added by hook developers to make Xaman display/handle that account in specific way.

Xaman SDK is integrated in most websites which offer transaction handling, and this method of adding additional information to account would instantly be handled globally.

Xaman will scan and react only on specific namespace and specific keys in that namespace (you decide which functionality offer to devs), i will suggest some sample naming below, but you can decide if there might be better naming.

Note: suggested namespace keys might be terrible named but it will convay intent behind this feature request.

Now there is probably infinite use cases we can think of using this but here goes one specific:

Use case 1: Open transaction in specific xApp

For this behaviour to be activated account requirements are:

• must have "xaman" namespace on account
• in "xaman" namespace there has to be "tx_open_in_xapp" hookstatekey with eg "acme:somexapp" value
  If conditions above are fulfilled when user scans QR on website or push notification arrives for that account, Xaman would not open transaction sign pop-up but open "acme:somexapp" (if is active/exists, or show notice/offer native sign pop-up) and sends payload to that xApp. xApp now have opportunity to do additional processing of that payload before invoking real signing in Xaman.

Some concrete examples where this would be needed:

• There is a Hook on account which allows only Invoke tx. Installed hook can execute inteneded Transaction by sending it raw to Hook via HookParams, plus additional stuff xApp adds. Hook then takes that Invoke and checks conditions xApp sent, executes or rejects inteneded tx.
• There is a Hook on account installed which requires iether additional transaction (for example send activation/allow invoke tx to acc to unlock it) then xapp in next step offers original eg Payment tx to be executed after it.
• There is required fulfilment to be added to tx body (hook on acc requires it)

What I personally would like to do is TOTP authentication Hook, lets call it "GuardHook" which will HOOK_REJECT incoming transaction if that transaction is missing 6 digits or they are wrong. This requires additional SDK support by Xaman to allow GuardHook-enabled users to seamlessly be pointed directly to "acme:somexapp" middleware xApp to do that step.

Use case 2: Transaction type blocking?

This one might be little drastic.
For this behaviour to be activated account requirements are:

• must have "xaman" namespace on account
• in "xaman" namespace there has to be "disallow_tx_types" hookstatekey with eg "Remit OfferCreate" value
  Instead of starting transaction pop-up in xaman it will not do that, but show message "OfferCreate" transaction is blocked by Xaman account settings. This can be probably done native or might not be good idea, but we are just exploring use cases here.

Use case 3: Special account labeling/category/info which shows in Xaman

Use case 4: Disable signing on websites, allow only from Xaman

In conclusion
There are Hooks, hooks go hand in hand with special interfaces (websites, etc) due to different use cases. Xaman offers xApps, great! Using xApp functionality from Hook vendors in some cases requires creating "middleware" xApps, some hooks as one above requires special interface to work, and to offer interoperability with all websites which offer Xaman signing this is needed.

You can extend offered functionality later on, I would like to be able to define "xaman" "tx_open_in_xapp" in account and allow users to do additional step in xApp before.

Thanks for listening.