Load large deeplink contents from disk

[grctest]

Is your feature request related to a problem? Please describe.

Since there's a max URL char length to deeplinks, some possible blockchain operations won't be possible via TOTP nor Raw deeplinks.

Describe the solution you'd like

Rather than instruct the user to copy and paste large deeplink URLs into a firefox browser, allow loading an operation from the disk.

The contents of the operation would be like:

{
    "id": "5af9e1c7-60dd-4f8d-8c44-71dae8f65c60",
    "payload": {
        "method": "injectedCall",
        "params": [
            "signAndBroadcast",
            "{\"ref_block_num\":0,\"ref_block_prefix\":0,\"expiration\":\"2023-05-30T16:17:00\",\"operations\":[[57,{\"fee\":{\"amount\":\"5000000\",\"asset_id\":\"1.3.0\"},\"account\":\"1.2.4353\",\"target_type\":\"3\",\"amount\":{\"amount\":\"100000\",\"asset_id\":\"1.3.0\"},\"extensions\":[]}]],\"extensions\":[],\"signatures\":[]}",
            null
        ],
        "appName": "Airdrop tool creating ticket",
        "chain": "BTS_TEST",
        "browser": "airdrop_tool",
        "origin": "localhost"
    },
    "type": "api"
}

The user would be prompted to save this as create_ticket.json to a folder.

The Beet user would navigate to the local file prompt page, load the airdrop_1.json file into the app, and receive a Beet prompt after clicking a 'process input' button of sorts.

Describe alternatives you've considered

Instruct user to paste large deeplinks into firefox; this isn't great UX & it makes Firefox mandatory companion software.

Additional context

Clipboard contents can sometimes be exfiltrated, by instructing users to copy and paste deeplinks into firefox that increases attack surface area, contents of pasted text could be altered.

Clipboard attacks would be eliminated through use of TOTP as opposed to Raw deeplinks.

A greater airgap between airdrop calculation and beet prompting can be achieved, and saved files can be monitored for change by antivirus products.

The contents of saved prompt json could similarly be encrypted like TOTP deeplinks to avoid local files being altered by a background process, however if the code changed then the saved operation files would be rendered useless.

We already offer this feature via local QR code image file processing, however this would be json file handling as opposed to QR code image handling.

[sschiessl-bcp]

Can you describe an actual use case for this? What is the flow of a naive beet user coming across this feature?

[grctest]

This feature will enable creating Beet prompts for large operations which are currently impossible to create deeplinks for (both totp and raw deeplinks).

I'm creating a new airdrop tool in Tauri.

I'm unable to use websockets/socketio to connect and link to Beet: https://github.com/BTS-CM/airdrop_tool/issues/1

To workaround the above, we have deeplink functionality, which I can use successfully to create tickets, however creating airdrops with as few as 11 recipients (11 transfer ops), this exceeds Edge's URL limit for deeplinks. https://github.com/BTS-CM/airdrop_tool/issues/2

The workaround communicated by Microsoft is to write the data to disk, then have the secondary application parse the saved file.

So in the airdrop_tool we can now write airdrops to JSON, which can then be uploaded to Beet to trigger an airdrop transfer prompt to many users.

Alternatively, we could develop a Rust Beet client library to enable connecting/linking of tauri dapps, but I don't know Rust yet.

Edit: Further an alternative would be to switch back to electron from tauri..

---

The above is a happy path use case, it's a feature for advanced users.

If a naive beet user stumbled across this feature they could try uploading random JSON files but no prompts would render as the transactionbuilder will reject the contents of the JSON.

We could include warnings to the user that they shouldn't be following instructions provided by scammers, that prompts following the upload of JSON could be malicious.

To boost the security of the JSON files stored long term on disk, we could introduce an optional TOTP code, rendering downloaded airdrop JSON uneditable and useless outwith the code window. Though an antivirus monitoring for edits to these files could suffice.

---

This more or less functions exactly the same as uploading of a qr code image for beet prompt, however you're able to view the operations proposed contents in a text editor instead of being displayed an image.

[grctest]

The airdrop tool which utilises this feature for airdrop has been released: https://github.com/BTS-CM/airdrop_tool

[grctest]

Turns out the max url length issue which exists for deeplinks also may exist for us when passing data as url parameters between the electron windows, so to support say 2000 transfer operations in a single prompt we need to consider an alternative method of transferring this request data from the backend to the remote window without the use of url parameters..

[grctest]

local json prompt upload feature merged into develop