Brand Guide #34 (comment)

Current AccountSelect

start app -> write name wallet -> write account name and keys -> this error:

The reference UI always has the problem that it can't keep up with the scammers. Should we have an on-chain blacklist?

Open Beet, attempt to add account (add-account.vue), and observe the combobox

Task is to match this with the style guide #34 (comment)

Implement a Vuex store as a state container and remove unnecessary reference passing, globals etc. from the existing codebase.

Describe the bug
Load time for the app was roughly 75 seconds.
After it loaded, it flashed, followed by another window.
Maybe not an error (assuming flash is seeking a wallet) but the load time is notable.

To Reproduce
Steps to reproduce the behavior:

1. Downloaded, installed Beet. Reboot the system. See Gif for re-loading of Beet flash

Expected behavior

1. A faster load of the app
2. No flash with a second window.

• Windows OS 8.1
• Browser Opera
  

Is your feature request related to a problem? Please describe.
I want to be able to setup multisig system that consists of a client (beet) and a server. Both need to sign a transaction.

Describe the solution you'd like
The process I have in mind looks like this:

1. The server creates a raw (unsigned transaction)
2. Sever sends it to the client
3. Clients signs the raw transaction (one out of two require signatures) using beet
4. Client sends the partially signed tx to server
5. Server adds the second signature and broadcasts the transaction

Describe alternatives you've considered
The alternative would be to do it the other way round and let the server sign first. The difference should be minimal as you just have to keep track of a potentially existing signature in the to-be-signed transaction.

Additional context
We would like to be able to improve security by removing the potential of the server-installed private key to do anything without the approval of a local signature.

Describe the bug
No matter what I wrote the message was always 'text'.

To Reproduce
Steps to reproduce the behavior:

1. Go to http://www.bitsharesvotes.com/
2. Click on trollbox
3. Wrote text
4. Submitted it

Expected behavior
The text that I wrote appear as new message

Actual behavior
The text in new message was 'text'

Screenshots

Desktop (please complete the following information):

• OS: Ubunut 18.04
• Browser: Chromium Browser
• Version 73.0.3683.75

Style tooltips to match brand guide

Ideally, the developer must only call beet.get and beet-js recovers by itself unless a severe error occurs.

Assume that Beet and some app have linked, now user re-installs Beet and visits the site again. Site wants to authenticate using the existing link, but Beet does not know it.

Since the identityhash is deterministic, Beet calculates the idendityhash for all imported accounts that match the requested connection details. Two cases:
a) there is match with the client identityhash, user sees a popup in Beet, possibly with a refined message to notify the user of this anomaly, and connection is re-linked. Nothing changes for the developer on the client side
b) there is no match with the client idendityhash. Beet sends an error to the client, and the client has two choices: either destroy the local identityhash and re-link (can happen automatically), or notify the user there and give him a chance to import the correct keys in Beet

aka website that the app is running under

In case others have trouble with this, I solved this error by setting the NODE_ENV environment variable as follows:

set NODE_ENV=development

for more on this issue, refer here: electron/forge#367

Since Store will be split into multiple modules for maintainability, what was originally the complete BeetStore will now host wallet related stuff only thus should be renamed to WalletStore in the codebase.

• Wallet selecting
  
  Enter action: Select wallet and jump to password field

• Enter password
  
  Enter action: Euqal to clicking Unlock

• In general: If there is only one item in combobox, preselect

When an app connects to Beet for the first time , it does so over an unencypted method call.

Upon connection, client lib provides a unique PIN visible to the user in the browser/app as well as in the Approval of connection request inside Beet.

User must verify the same PIN is visible prior to approving as well as choose an account (see #10 ) to use with the app. Once approved, client lib and Beet proceed to a key exchange and use a HOTP implementation to identify all subsequent requests & responses.

this.holder.btscompanion.connect('BitShares Voting Widget').then(connected => {
                if(connected){
                    //this.btscompanion = btscompanion; Unbind from window and bind to your own state var to avoid extension hijacking
                    //window.btscompanion = null;
                    window.btscompanion.requestSignature({op_type: "transfer",op_data: {
                        "amount": {
                            "amount": 100000,
                            "asset_id": "1.3.0"
                        },
                        "extensions": [],
                        "fee": {
                            "amount": 10420,
                            "asset_id": "1.3.0"
                        },
                        "from": "1.2.386825",
                        "to": "1.2.386826"
                    }});

                }
            })

Executing the above will also trigger to access account ID

This popup should only appear when accountId is requested

I imagine a popover on the bottom above the footer saying

Transaction <type> successfully broadcast
<link to explorer>

That disappears after 5 seconds

When the user wants to update e.g. votes, the voting widget does not need to know the identiy stored in companion.

For that purpose a placeholder account id can be used, that the companion fills in when receiving a transaction, e.g. 1.2.0 (no one will sign as committee using companion).

Describe the bug
Cannot copy-paste my private keys into beet app.

Looks like hotkeys doesn't work when cursor is inside fields. I cannot even copy my username using cmd+a (after I typed it manually)

Desktop (please complete the following information):

• OS: OSX (.dmg)
• Beet 0.4.2

• currently does not work
  
• filename should be beet_<wallet name>_<timestamp>.json

Modify Beet so that each wallet can contain multiple sets of keys and accounts (as per reference UI wallet).

User can choose which account to associate with each requesting app.

When opened and at least two accounts present and the app requests "ANY" chain, user can't confirm the default selection

Linked should be shown also in selected item (in the screen the WhaleShares account is already linked)

Finalize or hide for beta

This is to ensure we do our best to stay connected to the best possible node.

Especially important on first use as we want the wizard to be very simple and avoid adding node-selection until wallet has been created and user is at Dashboard screen.

@sschiessl-bcp How easy would it be to port your node-selection code over?

This also solves the occasional hardcoded node failure as in #6.

Right now, the initial connection does no checks because each API action call is explicitly verified.

Upon completion of #9. Initial connection will request approval, connection of specific account and handshake but return no personal data. That will be left to the API calls.

This also modifies behaviour as discussed in #2.

Describe the bug
The signed message from beet is awkward. It appears to be key, value pairs, but really is not:

["from", "xeroc", "BTS5TPTziKkLexhVKsQKtSpo4bAv5RnB8oXcG4sMHEwCcTf3r7dqE", "time", "Fri, 29 Mar 2019 12:12:43 GMT", "text", "Login at bitshares.org on 2019/03/29 @ 12:12:40 UTC"]

The additional pubkey has no name.

To Reproduce
use the example in examples.

Expected behavior
I want the array to declare a name for the public key. E.g.

• from: xeroc
• pubkey: BTS....
• ...

Additional context
Additionally, I believe that timestamps are easier to parse than human readable strings. Ultimately, no one will probably ever look into those messages anyways.

My particular use case is for login into a website using beet's signed message.

Is your feature request related to a problem? Please describe.
Consider a Local Wallet check box on Step 2 allowing .BIN import from a back up or storage device.

Describe the solution you'd like
Ability to utilize Beet for both local and cloud wallet users.

version call returns ui and api version. Beet and client with same api level are considered compatible.

Ideally the user would first create a Beet wallet, and then go about adding accounts:

1. For creating a Beet wallet, I would suggest letting the user enter the wallet name and password on the same screen. Perhaps encourage a backup after the wallet is created. Then you can prompt user to add their first account.

2. For adding accounts, it would be helpful to have an "Add Account" title/header at the top. Also, I think you can let the user enter the blockchain and other info on the same screen.

By the way, is it really necessary (or even useful) to enter account name? Is it not the case that only the private keys are necessary (aside from bitshares cloud wallet) and the account name could then be be looked up?

See #91

To test the transfer open the corresponding example in beet-js while running beet.
https://github.com/bitshares/beet-js/blob/90b8ad8eb472af96ab59fc48e5785c9844343180/examples/transfer/eos.html#L4

The code in beet is found here:

I want to be able to support the transfer of any EOSIO token, and the action I implemented is probably wrong and only for EOS.

When creating an account the owner key must be entered, otherwise an exception is thrown after entering wallet password.

Furthermore, the default question should be to collect active and memo. The field to enter owner key could appear when a small button "Include owner key" or similar is clicked.

Of the four icons at the bottom, only two have a readily apparent purpose (gear and lock). Of the other two, one is unnecessary and the other is misplaced. I would put the settings gear and lock icons in the upper right. I would remove the graph icon since the user can just close the settings (with a "Back" or "Return" button) to go back to the main screen (where the accounts are listed). And finally, you can have a [+] add account button next to the accounts drop down list.

Alternatively, you can have tabs at the top where "Accounts" is one tab and "Tools/Settings" is another, and you can add additional tabs if/when needed in the future. Under settings you can have sub-items such as below.

Tab 1: Accounts
Tab 2: Tools/Settings

• Linked dApps
• Wallet back-up
• Wallet Timeout (hint hint)
• etc...

Assuming completion of #10 , allow users to directly load their .bin UI wallet backup into Beet.

Optionally, allow export of Beet wallet to UI's .bin format.

Describe the bug

1. Multiple Beet icons in the tray after first opening of Beet.
2. Clicking the maximum button tabs from right to left; clicking max again tabs left to right.
3. Clicking the minimum button reduces to the tray without the running in the background notification.
4. Clicking the "X" reduces to the tray; does not close the program. User must go to the tray, right click on the Beet icon, click quit to quit the program.

To Reproduce
Steps to reproduce the behavior:

1. Open Beet
2. Click to open the tray noting multiple Beet icons
3. Open Beet; click maximum window noting tabulation to the left; click max again noting tabulation to
   the right.
4. Click minimize window noting it reduces to the tray without the initial running in the background
   notification.
5. Click the "X" to end and close Beet noting that it did not close, but minimized to the tray. Clicking on
   the Beet icon in the tray merely re-opens the app. User must right mouse click on the Beet icon in the
   tray then click quit to exit the app.

Expected behavior

1. Clicking maximum to maximize the window, not tab
2. Clicking minimum button to minimize to the taskbar; if reduced to the tray, a notification would help
   inform the user.
3. Clicking the "X" to end and close Beet.

Screenshots
See Gif

Desktop (please complete the following information):

• OS: 8.1
• Browser Opera
  

Similar to the UI beet should be build automatically for tags on master branch. This is issue is to track progress on it.

The build process will be done by a separate github account made for that purpose @bitshares-ui-automation

Tasks & work prior to UI worker inclusion.

1. Initial research & planning
2. Development stack identification
3. App architecture planning
4. Dev stack and build process setup
5. Alpha functionality goals identified
6. Initial UX/UI design
7. Development of alpha version
8. Development of alpha version of beet-js client library
9. Alpha version testing
10. Voting widget integration
11. Alpha version distribution build
12. Future roadmap creation

Closed via e520d25

Currently claiming genesis Peerplays tokens requires signing into Peerplays core wallet using BTS private owner key (instructions below). It would be great if beet users could safely claim their Peerplays tokens using their BTS keys already stored in beet.

https://www.peerplays.com/wp-content/uploads/2017/11/Howto-Claim-Your-PPY-Tokens.pdf

Ref: https://electronjs.org/docs/tutorial/code-signing

We should look into this

Current routing is to / after restoring, which causes user to enter password again.

Routing should be to /dashboard after restoring, but getting the error

2019-04-13 23:06:16 GMT+2 - [ERROR] TypeError: Cannot read property 'chain' of undefined
    at VueComponent.selectedChain (/home/schiessl/Projekte/BitShares/beet/src/components/dashboard.vue:116:41)

Is your feature request related to a problem? Please describe.
I want to be able to setup an HTLC on bitcoin

Describe the solution you'd like
Use BIP199 to setup CSV/HTLC on bitcoin

Additional context
BIP199:
https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki

Some basic example code (unittest):
https://github.com/bitcoinjs/bitcoinjs-lib/blob/3588d1100f82af1718e0a2b0c91db1d33a4204b0/test/integration/csv.js#L38-L95

Some implementation (submorineswaps):
https://github.com/submarineswaps/swaps-service/tree/master/swaps

Integrate an i18n localisation library and move all strings to it in preparation for UI translation.

Run Beet from any branch (master/develop/Steem-Support) and run the new example from beet-js (bitshares/beet-js#10)

Notice:

• 1st load: account and chain gets linked
• refresh: msg encrpytion error
• refresh: hash mismatch error

  beet/src/lib/BeetWS.js

  Line 67 in 4d13827

  if (hash == client.next_hash) {

• refresh: like 1st load

Also see the uncommented lines in new example from beet-js. Put them back in to get a different strange id mismatch bug

Any ideas / pointers?

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

I was thinking a checkbox to "auto close the app after xx time" might be a good option. But, how could that be done in the event that a transaction occurs, a back up is mandated, but the user is either unavailable, device is lost, stolen, away from backup device, etc?
With that said, I am curious as to how Beet would currently handle an instance where a user accesses the app, makes transactions, and experiences a power failure, reboot, loss of connection, or back up needed?

Describe the bug

1. Active/Memo key input exceeds the window size; consider reducing the font size or enlarging the key
   input window size so that the keys fit within the window in entirety.
2. Unable to copy/paste the keys
3. Tooltips are generic; Consider detailed, simple directive tooltips to guide the user

To Reproduce
Steps to reproduce the behavior:

1. Open Beet; Go to step 2 for Active/Memo key input

2. Click in Active key window; attempt to copy/paste the key into the window

3. Note that copy/paste is disabled; Input the Active key manually noting it scrolls outside the window
   

4. Click in the Memo key window; attempt to copy/paste the key into the window

5. Note that copy/paste is disabled; Input the Memo key manually noting it scrolls outside of the window

6. Note that tooltips throughout are generic in terms of direction to the user

Expected behavior

1. Ability to copy/paste the key; if disabled, consider a copy/paste disabled notification to the user
2. Ability to input the Active/Memo key and see it in entirety.
3. Ability to hover over a field, utilizing the tooltip for concise, direction.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 8.1
• Browser Opera

Additional context
Best practice is never copy/paste keys, but eliminates human error entry.
Tooltip wording is crucial for the user to know exactly what is asked of them, especially when it involves keys.

We want you

Requirements

• currently there are no binaries available yet, so the minimum requirement is that you know how to install and run beet via npm locally according to the readme and are able to read javascript
• attention to detail and ability to report precisely

Tasks

• [0.25] Install and start Beet and import accounts for each chain that you have an account, at least 3 different chain
• [0.25] Check your accounts balance with external explorers
• are all tokens you have listed?
• is the balance correct?
• [0.25] Click around in beet, does something feel weird? Is the UX broken? Is something not self-explanatory?
• [0.5] Execute at least one example for each chain (must broadcast something) found here https://github.com/bitshares/beet-js/tree/develop/examples If using transfer example make sure the recipient is one of your own accounts
• [0.3] Use http://examples.get-beet.io/binance-dex to trigger transfers

Process

• Each click and every action you do needs to be reported via window screenshot in the issue
• When broadcasing, please post a link to the transaction
• If there are any errors appearing, report the console log of beet (push CTRL+SHIFT+I when beet is open) and the electron output (visible in the console where you started beet), if executing an example also the browser console log of the example

Currently connector it is always visible

Show connector only while connecting, and if it errored. When not present, default to purple background with a refresh icon that reloads current account balance.

Currently looking like this

Task is to match the style as seen in #34 (comment)

Due to a build process issue (couldnt get vue sass loader to work properly) npm run buildcss needs to be run to compile global sass files.

Styling the default combobox seems obnoxious (https://css-tricks.com/dropdown-default-styling/), switching to multiselect may be warranted (as seen here https://github.com/bitshares/beet/blob/develop/src/components/account-select.vue) and adjust it's styling to match.

Either solution is fine as long as the default combobox UX flow is maintained.

The UI design will be handled by the winner of the Beet logo contest (https://whaleshares.io/art/@pixel/beet-artcontest-bring-life-to-beet)

Beet UX is bootstrap based.

This is a list of things we're going to need:

• Primary logo with & without app name
• Logo in secondary color scheme with & without app name
• Mini logo/icon
• Main font
• Secondary/Headings font
• Button style
• Bootstrap theme colors x 8 (primary,secondary,success,danger, warning, info, light,dark )
• Form control styles (input textbox, checkbox, radio, switch)
• Status indicator (connected/not connected)
• Icon set suggestion (close, lock/unlock, save, load etc.)
• Modal/popup styling

Enable something like connection_list=await app.getChainConnection(['BTS','BTC'],true);

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

Other graphene-based blockchains are facing a similar problem that beet is solving: Trust in third party apps. Some other chains may even experience this as a bigger problem, such as PeerPlays Blockchain which would like to allow 3rd party game developers to develop custom games.

Describe the solution you'd like

I'd like beet to be able to not only speak/sign for BitShares, but also other chains (e.g. PeerPlays, SoundDac, Decent, ....).

Describe alternatives you've considered

Forking + Customization

Additional context

Basically, the app could have a slider of some kind to define which chain you want to talk to. Then, the app would load chain-specific plugins/jslibrary and offer chain-specific API calls.