Skip to content
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

General Idea about unified functional "URL" for bitshares mobile client #775

Open
pluswave opened this issue Nov 30, 2017 · 31 comments

Comments

@pluswave
Copy link

commented Nov 30, 2017

original post:

https://bitsharestalk.org/index.php/topic,25379.0.html

Is there any general "URL Schema" defined for BitShares mobile client ?  
In my opinion, general means "self described", so the mobile client can do 'smart things' by scan a qrcode based on a real "URL".

for example, the following types are useful:
  1  an account address
  2. a private key
  3. a payment request = an account address + asset + amount

Slavi La Libertad suggested: I suggested bitshares://account?asset=BTS&amount=2.00&memo=description via Telegram.

@abitmore

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

@wmbutler wmbutler added the question label Dec 1, 2017
@wmbutler wmbutler closed this Dec 1, 2017
@abitmore

This comment has been minimized.

Copy link
Member

commented Dec 2, 2017

Why closed?

@abitmore abitmore reopened this Dec 2, 2017
@abitmore

This comment has been minimized.

Copy link
Member

commented Dec 2, 2017

The document I link above was about the old BitShares 0.x wallet. The feature has NOT been migrated to the new (light) wallet. I think we do need it. We can start by reviewing the document, and perhaps make a revised one to fit current wallet as well as mobile wallet products better.

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Dec 2, 2017

Bitcoin uses:

bitcoin:1BTCAddress?amount=1&label=label&message=message

Bishares could use:

bitshares:account?amount=1&asset=1.2.3&memo=memo

static_qr_code_without_logo

@pluswave

This comment has been minimized.

Copy link
Author

commented Dec 3, 2017

payment request is just ONE use case. it should be like this:

bitshares:payment/request?account=account&amount=1&asset=1.2.3&memo=memo

for adding to address book

bitshares:add/to/address/book?account=account&memo=memo

we should list all possible use cases and define their paths and query params.

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

Or we can break them down into their tasks and execute them one at a time. One thing I'm curious about, it's interesting to me that the standard revolves around the full name of the asset rather than the abbreviation. Any thoughts on this as far as being universal?

For each symbol, is there always a single word equivalent and do we have a relibale way to crossreference?

bts:// vs bitshares://

I'm curious more than anything.

@pluswave

This comment has been minimized.

Copy link
Author

commented Dec 8, 2017

2017.12.19 revised definition of payment request :

   bts://r/1/account/asset/amount/memo
part definition
bts:// URL schema, all BitShares client use it.
r path part 1: command, r for payment request
1 path part2: current schema version for this command
account path part 3, target account name or id (1.2.xxx) . mandatory
asset path part 4, asset symbol abbreviation, like 'BTS'. according to BitShares ,upper case only. mandatory
amount path part 5, amount, float number. optional.
memo path part 6, memo.optional.

for amount and memo , if provided, then user shall not change; if not provided, let user input.

for amount , if it exceed the precision of the specified asset, client should reject it.

amount not provided:

bts://r/1/account/asset//memo

memo not provided:

bts://r/1/account/asset/amount

neither amount nor memo are provided:

bts://r/1/account/asset

for general:

  1. if empty params are in the last, omit it and it's preceding /
  2. otherwise, leave the empty param in the final url with preceding and following /
@xeroc

This comment has been minimized.

Copy link
Member

commented Dec 11, 2017

I wod like to emphasize that you want the data to be as 'short' as possible to allow generation of QR code from them.

That said, i would not use 'payment' as a string in the query, but suggest to think about something shorter.
Also, the 2.0 is irrelevant as there is only one bitshares chain.

How about

bts/1/r/account/asset/amount/memo

The '1' would indicate the version of the qr code content that is specific for the bitshares/bts chain

@pluswave

This comment has been minimized.

Copy link
Author

commented Dec 11, 2017

@xeroc

great idea, how about the optional params (amount, memo) ? I suggest following:

amount empty:

bts/1/r/account/asset//memo

memo empty:

bts/1/r/account/asset/amount

both empty:

bts/1/r/account/asset

for general:

  1. if empty params are in the last, omit it and it's preceding /
  2. otherwise, leave the empty param in the final url with preceding and following /
@pluswave

This comment has been minimized.

Copy link
Author

commented Dec 12, 2017

One thing I just reminded, the url should be standard, which can make it more general: I.E. other apps can jump to the correct app. For this reason, slightly longer version of payment request:

bts://1/r/account/asset/amount/memo
@abitmore

This comment has been minimized.

Copy link
Member

commented Dec 12, 2017

I'd suggest that put the version number (1) after the command (r), since we may upgrade version of individual commands, for example, bts://r/1/account/amount/asset/memo for transfers, bts://a/1/account for showing account info, and etc. Once we want to upgrade the info URL, we go with bts://a/2/account/history.

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2018

I think we should comply more closely with the existing standards in a parameterize url . I think your concern about the amount of data that can be shown in a QR code is unfounded.

static_qr_code_without_logo

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2018

The idea that we would create a URI that cannot be easily visually understood is, I believe, a mistake. What you have proposed required proper order and, without labels, it prone to misuse. It's also nonstandard as we look at almost every other major cryptocurrency. To be standard with the rest of the world, we should adopt the following. Since we are naming each parameter, order doesn't matter. with the exception of the schema and the account.

bitshares:<account>?asset=<asset>&amount=<amount>&memo=<memo>
part definition
bitshares URL schema, all BitShares client use it.
account path part 3, target account name or id (1.2.xxx) . mandatory
asset path part 4, asset symbol abbreviation, like 'BTS'. according to BitShares ,upper or lower case. mandatory
amount path part 5, amount, float number. optional. full precision of asset
type transfer (optional)
memo path part 6, memo.optional.
@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 24, 2018

@wmbutler almost "every other coin" has only a transfer operation, but we have more. At least we should add "transfer" in the url, otherwise it will prevent us from enabling other features via URL.

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2018

So maybe we add a type parameter and make it optional so it defaults to transfer?

@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

@wmbutler It's a bad idea to use account as the first part of the URL, if done so, it will be hard for apps to render other functionalities, for example asset info, market info and etc. If you really want that kind of URL, please use another prefix, e.g. bitsharespay:account_name?asset=&amount=, so other apps can adapt this as well.

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2018

Argh. But then we are breaking form with other currencies. I'm trying to understand what other operations lend themselves to a QR code. Can you give some examples of why people would care to have a QR code for anything else?

@pluswave

This comment has been minimized.

Copy link
Author

commented Feb 27, 2018

@wmbutler there are many ,like

  1. to login to some server
  2. to add some account to local address book
  3. to create a limit order
  4. to co sign a partial signed transaction
  5. to vote for some proposal

MagicWallet version 1.5.4/1.5.6 has implemented the schema for payment request according to my proposal: both generating a QR code and scanning to transfer. In my opinion, although it is not good enough and error prone, it is about the implementation / test cases , but not the definition itself. MagicWallet can change to whatever better defined later, but we need the feature to be widely used ASAP (to promote BitShares).

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2018

@pluswave I think your desire for flexibility will jeopardize the reliable use of the QR code. There is no real business purpose for 1, 2, 3 or 5. 4 is a possibility but even those are very simple binary operations not requiring a qr code.

I find it disappointing that MagicWallet has used a schema-less pattern. It goes against everything the modern web has to offer, particularly restful API's that describe themselves.

@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 27, 2018

@wmbutler MagicWallet IS a mobile app, it's the most popular mobile app for BitShares, IMHO it knows the best what a mobile app will need. The features listed above will most likely be added into the app sooner or later. I don't understand why you can't see it but insists that nobody wants those features. When MagicWallet team was implementing the QR code feature, we have no standard, so they made their standard, it's all legit. @pluswave already said if we come with a better standard they're willing to change. However, they can only do it if our new standard can fulfill their needs. It would be disappointing if you're unable to cooperate with the mobile app team.

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2018

Gotta love a community effort that can't look at a standard across..... um every single cryptocurrency in existence and adhere to it....

bitcoin, litecoin, ethereum all use a very simple understandable URL and we, BTS have to be the special snowflakes....

Bob: Every website uses https:// to denote a secure web page
Fred: Fuck that. Let's use web.secure
Bob: Fred, you are a true innovator.

@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

As a product manager (I think you are), please think bigger.

Before car is invented, everyone can only travel with carriages. Before mobile phone is invented few people can image how much convenience the huge amount of mobile apps brought to us nowadays, nobody knows QR codes at that time.

I'd say, the poorly designed URL schema that can only do transfers has been greatly limiting every other coins' usage, preventing them from becoming mainstream.

  • scan this QR to pay
  • scan this QR to verity the payment in your own app
  • scan this QR to login to a website with your BTS account
  • scan this QR to subscribe to this service
  • scan this QR to claim your gift
  • scan this QR to share this to your friends
  • ...

However, I'm stopping here. If you want to use your URL schema, go ahead. Since account names in BitShares must have at least 2 characters, a smart mobile app can identify both your URL schema and the one proposed by @pluswave. Then it's up to the apps to decide whether support both, up to the merchants to decide to use which one.

@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

By the way, perhaps off-topic here, process of the bitshares-pay project is far slower than expected, I guess MagicWallet team won't wait for it, but will develop and promote their own merchant tools. They're real business with real money involved, not a toy or experiment, they can't wait.

@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

Quoting some messages from Telegram group:

looking at other cryptocurrencies is wrong....a) there is no reason to believe they got it right b) bitshares is different in so many ways that it would limit functionality c) it's not like anyone actually types it out so exact format is relatively irrelevant
in any case, the scheme should provide deep linking within the app and should pretty much be able to cover ALL possible API operations
implementation specifics at this point would be up to the app developers
the prudent business decision...would be to not only set and describe the schema...but also provide a "Bitshares mobile SDK" so to speak
to handle this stuff in a more predictable manner and allow mobile app devs to focus on their own value added functionality
we should be talking about a Universal Link/Android App link setup
that would require a) the reference UI to support the routing scheme
b) a reference mobile client
the idea would be to have somethign that works universally / prompts for app installation if not installed etc.
so the link in the QR code would be something like : http://wallet.bitshares.org/whatever
with whatever being outside the normal UI routes
that would trigger a Download Bitshares App / Continue to mobile version dialog
which is the way most businesses handle it these days
seeing as it would be hard (and to be honest quite pointless) to actually create a reference mobiel client
this needs to be thought out carefully
perhaps the reference wallet would handle the routes and allow gateway implementations etc. to register their own app link?
so wallet.openledger/whatever would give the dialog with a link to OpenLedger Mobile Wallet (if OL creates one)
wallet.cryptobridge/whatever set up by CB to point to THEIR mobiel client etc.
reference could simply notify the user they dont have a relevant application installed and fallback to mobile web
the QR code insistence is unfounded
ideally we should be able to handle all relevant web links
i.e.
I set up a worker proposal with a web URL explaining the worker
at the bottom
i'd like to have a "Vote Now" button
this "Vote Now" button when clicked on mobile should prompt me whetehr I want to continue to the mobile version of the wallet (Worker Voting Section) or handle with my Bitshares App
so its not limited to scanning qr codes

@wmbutler

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2018

"you've got to think bigger"

Size has nothing to do with it. Standards win over flexibility every single time. This is proven over and over again. JSON is a wordy standard but because the schema is built in, it has become the overall standard.

A self-describing parameterized URL has withstood the test of time as well and this is the pattern being followed by millions of websites. The only reason some websites choose to hide the parameters in the URL is to obfuscate their controllers. We are an open platform with no need to obfuscate.

I keep seeing a full domain being brought up in conversations. This is completely offbase. A URI should never rely on DNS from a third party. Rather, a URI should refer to an application. In this way, if your device has say 3 bitshares wallets on it, you would be able to choose which application should be the default for that URI scheme.

My only disagreement with other cryptos is that I think they should have used the 3 letter symbol for the start of the uri rather than the full name since the full name can be unambiguous or unavailable...

bts: rather than bitshares:

@abitmore

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

I'm not against using ?,&, = and etc. I'm against putting account name after :, since it's not best practice, by doing so will be only able to do things related to an account. Better practice would be protocol:action?parameters.

@Tamizhanstalin

This comment has been minimized.

Copy link

commented Aug 7, 2018

is there any bitsahre api to craete wallet for new user along with login
https://github.com/carlo-fontanos/bitshares-api-cli-wallet
This is not working for me, perhaps i think i am running in a wrong way any guide pls

@jhtitor

This comment has been minimized.

Copy link

commented Nov 21, 2018

I really, really want to implement BitShares URLs for the QT client.

After reading this whole issue, I have to agree with @abitmore, the protocol:action?parameters is the best way to go. I propose to extend this with the following:

Transfers and other operations:

bitshares2:operation/transfer?to=...&amount=0.5&asset=BTS&memo=...

Here, paramterized values should match the Transfer operation inputs (e.g. asset for asset symbol and not symbol or anything else, memo for message, etc).

This way, the scheme will stay consistent even as new bitshares operations appear. Plus, such URLs could be easily parsed, and the proper operation objects constructed in memory. Note, that URL parameters support arrays and nesting (via the weird "?foo[][]=bar" syntax), so in theory, every complex operation could be constructed this way.

Raw objects:

bitshares2:object/1.7.273745

(The regular X.Y.Z graphene object id is expected here).

Block / TRX / Operation path:

bitshares2:block/2333/6777/0/777 (the ints are block_num, trx_in_block, op_in_trx, virtual_op, in that order).

Could be shortened, e.g. bitshares2:block/2333 for whole block 2333, etc.

Transaction by hash:

bitshares2:trx/0123456789AABBCCDD...

(bitshares2 for protocol is not something I insist on, it could easily be bitshares or bts).

@ThomasFreedman

This comment has been minimized.

Copy link

commented Nov 21, 2018

I applaud any and all proposals to establish useful conventions and standards. Consistency is also important and helps people learn new things faster. Glad to see this effort being made.

@sschiessl-bcp

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

My suggestion would be to account for the standard and allow flexibility, all still possible using

prefix:action?parameters

where

  • prefix = bitshares
  • action has two parts type[details].
    • type:
      • operation/ or op/
      • object/ or ob/
      • block/ or bl/
      • transaction/ or tr/
      • someaccountname, important that this string contains no /. This is an abbreviation for op/transfer?to=someaccountname
    • details is optional and contains more arguments, dependant on the type, see comment from @jhtitor above.
  • parameters is a list of ?=/&= values specific to the action

Convention could be that details contains necessary information for get, and parameters necessary information to post.

Who would like to formulate a BSIP? :)

@jhtitor

This comment has been minimized.

Copy link

commented Dec 12, 2018

@sschiessl-bcp, thanks for your input!

I've bit the bullet and wrote a BSIP draft bitshares/bsips#131 for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.