New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wallet Feature request: bis:// url #199

Closed
EggPool opened this Issue Feb 5, 2018 · 15 comments

Comments

Projects
None yet
3 participants
@EggPool
Contributor

EggPool commented Feb 5, 2018

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

This comment has been minimized.

Owner

hclivess commented Feb 6, 2018

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

@EggPool

This comment has been minimized.

Contributor

EggPool commented Feb 6, 2018

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

This comment has been minimized.

Contributor

EggPool commented Feb 6, 2018

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

@flyfire100

This comment has been minimized.

flyfire100 commented Feb 6, 2018

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

@flyfire100

This comment has been minimized.

flyfire100 commented Feb 6, 2018

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

@EggPool

This comment has been minimized.

Contributor

EggPool commented Feb 6, 2018

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

This comment has been minimized.

flyfire100 commented Feb 6, 2018

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

@hclivess

This comment has been minimized.

Owner

hclivess commented Feb 6, 2018

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

This comment has been minimized.

Contributor

EggPool commented Feb 6, 2018

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

This comment has been minimized.

Owner

hclivess commented Feb 8, 2018

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

@hclivess

This comment has been minimized.

Owner

hclivess commented Feb 17, 2018

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

This comment has been minimized.

Owner

hclivess commented Feb 17, 2018

added a proposal here 7db0c82

@EggPool

This comment has been minimized.

Contributor

EggPool commented Feb 17, 2018

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

This comment has been minimized.

Contributor

EggPool commented Feb 17, 2018

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

@hclivess

This comment has been minimized.

Owner

hclivess commented Feb 23, 2018

Basic implementation finished

@hclivess hclivess closed this Feb 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment