Wallet Feature request: bis:// url

[EggPool]

Add some kind of bis url, to request a payment.
Could be generalized to other operations than pay

Ex:
bis://pay/recipient/amount/openfield/checksum

checksum is a small hex or b64 checksum of the params, to guarantee the whole info is there, not cut.
Then, from a wallet we just paste this url, it auto fills all fields and ask for confirmation.

• This would make it easier for exchange to provide a deposit link (only one field to copy, less errors)
• This could be used on websites for donation links and such
• small enough to fit on a qrcode
• Generalize to other ops, such as token or messages management

[hclivess]

How do we approach this? What kind of hooks and integration does it require?

[EggPool]

I think there are 2 parts:

1/ Manually paste those urls in the wallet, via a new field. It's just for convenience: only one string (with embedded checksum) instead of 3 strings to copy/paste.

2/ See, at OS level (maybe large diff win/linux) if the wallet can directly register those urls and act upon a browser click. Will have to research if a python module does this.

[EggPool]

Or, step 1 could be just a button "paste bis:// url".
Copy link/text from the website, click button => confirm popup => done.

[flyfire100]

that's cool , and this is my idea
https://github.com/flyfire100/DARKNESS/tree/master/Doc
DARKNESS.pdf

[flyfire100]

the master node is public IP, this node can be NAT node , messages can through diff NAT nodes to client.

[EggPool]

Thanks @flyfire100 for your link and proof of concept, but I don't see how this relates to this issue.

This issue is about a single string that would embed all necessary info to send a transaction, and assurance that all info is coherent.
This string is then fed into the wallet and initiate the transaction without pasting multiple entries and risk errors.
What you describe on your github is something entirely different and independent, unless I missed something.

[flyfire100]

@EggPool I misunderstanding ,sorry, I think you are talking about use URL as BIS address.

[hclivess]

Aaaah, I see! So basically this is about a coherent string that means transaction. There already is something like that on the functional level: (amount_input, recipient_input, openfield_input), so it could be bis://10:edf2d63cdf0b6275ead22c9e6d66aa8ea31dc0ccb367fad2e7c08a25:msg=684654

I will add this to the wallet, if you agree on the format, might have to use different separators

[EggPool]

Yes, whatever the format, but with the added value of a checksum that makes sure the string was unaltered.
This is critical.

bis://COMMAND/PARAMS/CHKSUM
params may depend of COMMAND
or rather set CHKSUM at start to allow for more liberty with params

bis://CHKSUM/COMMAND/PARAMS
CHKSUM is a short checksum (4 to 8 b64 chars are way enough) of the rest of the string, so any alteration is detectable.

Then on this base, transactions are ok,
bis://chk/pay/amount/dest
but it can be extended later on
bis://chk/msg/DEST/message content
bis://chk/csg/DEST/message content (will send, but encrypted)
bis://chk/stok/token/amount/dest (send token)
bis://chk/reg/eventname (register to an event)
aso...

It's a generic abstraction for all wallet related functions, safer because of the format and checksum.
/ separator makes it look like regular url, could be useful later on also.

[hclivess]

I see you have put a lot of thought to it, checksum is definitely a good idea

[hclivess]

checksum needs to be something else than b64 because of the short static length for different strings (no hashing, no shuffle), suggesting MD5 (open to suggestions)

[hclivess]

added a proposal here 7db0c82

[EggPool]

Sure. b64 is not a hash. I was thinking of a hash, crc32 or md5, but we don't need the full length hash.
Only a small part of the hash is enough to detect a change in the chain.
So the start of the hash, b64 encoded, is enough and shorter than it's hex version.
(hex = +100% of bin size, b64 = +30%, z85 = +25%)
z85 would give the best bits/size ratio.

[EggPool]

Proposal Looks almost good, added a comment to shrink the size further.

[hclivess]

Basic implementation finished