hivewallet / hive-js Goto Github PK

Have started testing on mobile now and a couple of things have come up pretty quickly. One of them being the device asking me to increase localStorage over and over again. I understand that this might be necessary for first time visit on a device - but it seems to ask me every time I refresh the page, even after I've set "increase".

[EDIT]: Can only notice it on mobile safari on my iPad now... but I swear it happened a couple of times in safari on my iPhone as well. Chrome seems unaffected on both.

As far as I can tell this might be due to:

a) A bug in the device/browser app itself?
b) Because I'm on a local IP?

Will have to test on heroku as well once the latest master branch is online? If it's not either of those things then we need to find out what's happening and fix it. Is there even a reason we need that much localStorage? I thought we were only caching some hashed strings for the server to authenticate?

For people who are not worried about this specific security layer and want the convenience - we should allow them to open the wallet on a given device without a PIN once the passphrase has been entered.

I think this should be a localStorage reference per device, rather than setting it for all devices the way we set the PIN.

As discussed in hivewallet/discussions#9

https://www.flinto.com/p/153ce6b3

• Upload geo info, name and email(for profile pic) when clicking on "Search Nearby" button
• Find & display known users in the 1km radius
• Prevent unauthenticated request to geo endpoint
• Delete data when user leaves the page
• Make it pretty

If the discoverability turns out to be reasonably good, we'll proceed with the "Send Bitcoin" part of the workflow.

Any chance of getting support for older iOS / mobile Safari versions?

I can't tell if I managed to click the button or not...

Also allow entering fiat amount, which will trigger bitcoin amount update

I've logged in to the wallet with the passphrase that I've used before. I can see 1.6 mBTC that I've sent to that wallet before, so this is the same wallet. However, the address in the settings tab shows "1HXo1H3ocLYq8Csn8XrHCSk6D6T6YXuqzA", while it should be "1Cdt3VAH2xuDdH8KUNHqLbByS7PSNrwGT5"...

Depends on https://github.com/weilu/bip39 generateMnemonic

• numerical
• 4 char
• server
• client

placeholder says: "type to search". While user types, a dropdown will appear with filtered results.

Searchable fields: name, email, address

Support the same set of fiat currencies like hive-osx. Again, it's a per-user system-wide setting

Possibly caused by pouch error:

First noticed this on my refactored auth branch, so though I did something there. But have now confirmed it's occuring on master both locally and on heroku.

The error shows up in console when I create a wallet and when I log back in to a wallet - but doesn't seem to stop me from doing anything. It isn't seen on any wallets I created previously, however, just new ones.

I have found a couple of weird things with the gulp build, nothing major - but you might notice the following:

1. When you first gulp (watch and run the server...) if you make a change to any of the scss files, it will also run the asset task, which causes a refresh. After that though the css should live inject (avoiding refresh).
2. If you update the index.html file, gulp will do two refreshes.

I think (2) might actually be related to (1), but I can't for the life of me figure out why either of them are happening. The watch commands seem to only look at the right files/folders.

¯_(ツ)_/¯

Currently I noticed following issues

• the size of all 4 boxes (choose to create new or open existing, open existing with pin, enter passphrase, set pin) are different. As a result the box jumps around from screen to screen
• the progress status text is missing for creating new wallet and opening existing wallet
• when opening an existing wallet, after entering the passphrase, it says "set pin". It should be "enter pin"

Looks like I can log out by closing the tab, but it's not obvious at first ;)

Depends on bitcoinjs-lib wallet.js

• create tx
• broadcast tx
• update balance immediately
• update transaction history immediately
• newly sent transaction should be flagged as pending

As far as I know, private/incognito mode renders the app useless on mobile Safari (can't write to local storage). Attempting to generate a PIN presents this error:

This problem may be limited to mobile Safari (desktop browsers still let you past this step in private/incognito mode), but we should probably caution those who do manage to get past that if they want to use their wallet again they will have to enter their passphrase every time they open it.

This requires talking to bitcoinaverage api. This should work for balance and the send box

Right now it looks like I could put any-damn-length thing in there.

• Move mnemonic decode into a web worker
• Show progress bar

getUserMedia http://www.html5rocks.com/en/tutorials/getusermedia/intro/
It's not well supported across browsers though, especially on mobile: http://caniuse.com/#search=getUserMedia

I don't have any funds in my hive-js wallet at the moment so I can't test, but what do we currently have in place as far as confirmation goes? Something the lines of, you're about to send [amount] to [person/wallet ID]... send/cancel, presumably.

Furthermore, will we be asking for the PIN before the transaction can be sent? And should you only be prompted for the PIN if the transaction is over a certain amount?

User should be able to click on a link/button on contacts page. We present a form with:

• name
• email
• address

Upon successful add, the contact shows up on the list.

Also make sure that setting changes reflect on waggle

Getting consistent fail at the pin screen for new, or existing accounts on mobile devices:

Once a pin is entered and I either hit "return" on the keypad, or tap the yellow button to submit - it gives me the Saving pin message (which I set up, otherwise there is nothing during this wait).

Might be related to this issue: #29 (localhost IP on mobile device stops pin from being set on local server db)?

To the best of my knowledge, I fixed the error by clearing all the caches... restarting... and then re-gulping the project. In case this crops up again, here's a reference to the behaviour on stack overflow and some instructions on how to xhr locally with firefox:

http://stackoverflow.com/questions/5005960/xmlhttprequest-status-0-responsetext-is-empty

As discussed with @haustraliaer, currently to refresh the transaction history and balance one needs to log out and back in again. This feature provides user a way to refresh without logging out. Moving forward we probably want #13 + some UI for notification? cc @jenbennings

Nokair has this really nice little pop-up on their mobile site. Can we have something like this, too? If you start scrolling around it disappears.

When I click "search" I get a system alert asking for access to location. If I refuse, I see an error in Hive, but the button is locked in "Searching..." state.

In the case that someone tries to open an existing wallet from the landing screen of hive-js they are presented with the message "Set your pin".

In the case that they have already set a pin previously, it should instead read: "Enter your pin". A subtle difference, obviously, but important none the less. We'll need to have some way of detecting whether the user has indeed set a pin or not.

@weilu mentioned this would be a server side task for detecting a set pin (as you could potentially open on a new device with no knowledge of the account locally, but have a pin stored on the server).

I propose we use gulp for building the project and watching for file changes. You can see an example on the following branch: https://github.com/hivewallet/hive-js/tree/workflow/gulp

Happy to discuss and change this as needed - this is simply the quickest I could think of to bring in our existing sass/js workflow together & get up and running on the project.

Setup:

Pull down the workflow/gulp branch and run the following commands:

npm install
gulp
open http://localhost:8080

Notes:

• All editable files should be in the 'app' folder now - compiled files are put in 'build', which is ignored completely by git.
• The gulp command runs a small sever via connect and livereload, if you just need to build you can run gulp build.
• I've modified the aperture script to simply open and link post npm install (we're no longer using npm start with the gulp setup.
• We will likely start again with the styling once we get going with the brand, but until then (so you can at least see the project working) I've dumped the existing css in a file called old.css, which is just copied across with other generic assets by gulp.
• I have no idea if the tests still work, so apologies if I've broken anything.

Again - happy to work around any of the above decisions if they impact in any serious way (eg, testing, gulp/folder setup, etc).

Currently the user cannot navigate to previous step once they are past the 2nd auth screen (the screen after choosing create new or open existing). Per discussion with @jenbennings and @haustraliaer, here is what we propose:

1. User should be able to click the browser history back button
2. We should also implement a button in the interface that does the same thing (for homescreen apps)
3. On every screen in the auth process except the set pin and enter pin screen, "back" should just go to the initial landing screen
4. For new wallet set pin screen, back should go back to the "review passphrase" screen (in case they want to check it again)
5. For existing wallet set/enter pin screen, back should go back to the "enter passphrase" screen with passphrase prefilled (in case user wants to double check the passphrase entered)

This should probably be a modal - maybe the same whether an error or success - but with different content.

After the successful message, perhaps it should jump the user to the history tab where they will see the pending transaction?

We want to prevent user from using arbitrary mnemonic seed phrases (or brainwallet). We do not open any wallet with mnemonic that failed the check described in bip39

Q: "if I don't enter a passphrase it still lets me create a wallet, is that intended?"
A: "yes that's the point. It generates a seed phrase for you"

The following is an outline for the opt in feature of having your chosen username and address details made public at a human readable url, eg: hivewallet.com/mattinnes. If anyone has any serious concerns with this now is the time to voice them, otherwise we will proceed with the understanding that the public url/profile system will work in this way.

After the lengthy discussions last night and in an effort to keep things moving, I'm proposing we ditch any ideas of this url being able to generate unique addresses - which seemed fraught with potential abuse of the technical limitations in HD wallets.

Instead the address will be static and made clear to the user that it is a public address. See the attached diagram for further notes on this proposal:

Implications for hive contacts

The second point worth bringing into this discussion is how two hive-js accounts might leverage this system to connect to one another. Obviously I could just send coins to my friend's public address, or ask him for a unique address. However, if we were both using hive we gain the advantage of "pairing" our accounts and creating a unique address for each of our two wallets to send transactions through. The clear advantages being:

a) I don't have to generate a new address for sending coins to this contact
b) The only people who know of the transactions are myself and the contact
c) I would go so far to say that the actual addresses could probably be hidden from even the hive users, to make things simpler on their end.

From a UI perspective, there might be a prompt on the public page - hivewallet.com/mattinnes - to simplify this connection (which could send non-hive users to a sign up page). We'll be looking at the issue of connecting contacts in more detail as we go along, but I thought it would be worth mentioning here as the public url system will likely be coupled to the contact system.

Captcha of some sort. Maybe: http://demo.visualcaptcha.net/

Currently errors are displayed in alert boxes. Let's prettify it eh? @jenbennings :)

Store locally and sync with server. PouchDB looks ideal for this purpose

Support BTC, mBTC, μBTC. Default to mBTC like hive-osx. This should be a persisted, per-user system wide setting.

Can I have support for the ESC key on the login screen, so for example if I go to "auth existing wallet" and want to go back to the main screen, I can just press ESC?

I've boiled this down to it breaking if you load the app from a URL other than the root, eg:

http://hive-js.com/#/transactions -> will cause the transactions route to fail.

I'm going to try and sort out a way to clear the route on load to http://hive-js.com/ no matter what the user has in their address bar. I don't think the application will be complex enough to require loading of specific routes on entry (and if it does then we can figure out how to handle those entry URLs later).