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

[pluswave]

trafficstars

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]

There was a document: https://github.com/bitshares/bitshares1-core/wiki/XTS-URLs

[abitmore]

Why closed?

[abitmore]

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]

Bitcoin uses:

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

Bishares could use:

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

[pluswave]

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]

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]

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]

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]

@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]

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]

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]

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.

[wmbutler]

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]

@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]

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

[abitmore]

@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]

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]

@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]

@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]

@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]

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]

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]

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]

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]

"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]

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]

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]

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]

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]

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? :)