joincolony / purser Goto Github PK
View Code? Open in Web Editor NEWInteract with Ethereum wallets easily
Home Page: https://joincolony.github.io/purser
License: MIT License
Interact with Ethereum wallets easily
Home Page: https://joincolony.github.io/purser
License: MIT License
As planned in the Roadmap, we are phasing out providers from this wallet library and offloading that functionality to the end user.
This library will not be responsible for communicating with the blockchain, it should function as an offline wallet.
This Issue serves to track the refactoring work needed to make this happen.
This Epic tracks improvements needed (or just nice to haves, but that are planned) for the software wallet.
The getRandomValues()
, if it can't find the built-in webcrypto
API (or is running in a node
-only environment) will fallback to using node
's own implementenation -- crypto
library.
The way it's currently set up, it will load the code upfront in the bundle.
This can be further optimized by lazy-loading the code only we really needed.
Even though the signMessage()
method is available to the user in the Software Wallet via it's inherited prototype
(Remember, we're extending ethers
's Wallet
class
), it's not easily visible trough Object
discovery or prop
enumeration
.
We should expose this method directly on the SoftwareWallet
instance.
Along the way we should normalize and validate both the input and the output.
This Epic tracks improvements needed (or just nice to haves, but that are planned) for the Metmask wallet.
To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:
.nvmrc
with the new oneIf you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.
Greenkeeper has checked the engines
key in any package.json
file, the .nvmrc
file, and the .travis.yml
file, if present.
engines
was only updated if it defined a single version, not a range..nvmrc
was updated to Node.js 10.travis.yml
was only changed if there was a root-level node_js
that didn’t already include Node.js 10, such as node
or lts/*
. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.For many simpler .travis.yml
configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
As planned in the Roadmap, we are phasing out providers from this wallet library and offloading that functionality to the end user.
This library will not be responsible for communicating with the blockchain, it should function as an offline wallet.
This Issue serves to track the refactoring work needed to make this happen.
This Epic is here to track the minimal features needed for this library to be useful and cover the features needed by the dApp.
This might not necessary cover all the features that are needed for a proper release into the wild, but at first we're concerned with integrating it in the dApp.
After all the methods to create a new Wallet instance are implemented in #8 (private key, mnemonic, etc...), a nice improvement will be a helper method that detects the way you want to open the wallet.
It has to detect if you passed it in a private key, encrypted json, mnemonic, brain wallet (?)
Since this is not a high priority it will sit for now in the backlog and not be implemented together with #8
This Epic tracks integration of the Metamask browser extension into the wallet library.
It should have the usual needed features:
Please merge all issue PR's branches into the main metamask implemenation branch (feature/59-metamask-integration
), and only after all of them are done, merge the main class into master
.
Ethers
have a number of methods available on the wallet that are used to send and receive transactions and manage various aspects of the wallet.
The problem is, they are hidden under the instantiated's wallet prototype
and cumbersome to use.
This issue is here to track which ones we need on our software wallet module, expose them via the SoftwareWallet
Class
and improve them where needed.
This should be treated on a case by case basis as for some of the methods it might make sense to even re-write them ourselves or set them up directly in the Wallet Object
(eg: getBalance
could easily be an async
getter prop)
This PR is here to track planned features, as well as to track new proposals. Just add comments.
sign()
, sendTransaction()
) #26signWithPrompt()
method. Done in #32localhost()
provider method #34balanceOfToken('tokenName', 18)
, keep a registry of well-known tokens, and have a way to "register" new ones)This issue serves to track implementation of hardware detection on the local machine, for the Ledger Wallet.
Currently this is not possible using the U2F transport.
This will become viable once WebUSB
gets mainstream adoption.
Even though the sign()
transaction method is available to the user in the Software Wallet via it's inherited prototype
(Remember, we're extending ethers
's Wallet
class
), it's not easily visible trough Object
discovery or prop
enumeration
.
We should expose this method directly on the SoftwareWallet
instance.
Along the way we should normalize and validate both the input and the output.
Branch | Build failing 🚨 |
---|---|
Dependency |
webpack
|
Current Version | 4.9.0 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 11 commits.
94cd709
4.9.1
5feb7e6
Merge pull request #7174 from JLHwung/revise-examples-build-readme
4cd0cf5
Merge pull request #7379 from xtuc/refactor-use-wast-in-tests
c513cac
Merge pull request #7403 from webpack/fix/7335
f22fffd
Evaluate arguments in function's scope
55ce143
Add test case
00eafa6
Update mem-access.wat
acc45fd
refactor: switch to wast
7184bb4
fix: keep decoding in wasm
a9d9fee
refactor: switch to tests to wast
64db306
docs(examples): add yarn add webpack-cli step
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
This is an Epic that keeps track of all the issues related to refactoring providers.
This Epic tracks improvements needed (or just nice to haves, but that are planned) for the Ledger hardware wallet.
It basically needs the call to the Trezor service to be wrapped inside a try/catch
block and have a nice error message presented to the user.
Both other methods, signTransaction()
and verifyMessage
have this, but apparently this one was overlook during initial development.
The library should provide a core wallet experience, without making assumptions about the environment, be extra opinionated or bundle in extra "features".
Although initially I thought they would be nice additions, I've came to the conclusion that they would only be extra weight to the library.
To that affect, we should remove from the software wallet library:
I have a hunch that the signature returned for a transaction will not be accepted into providers like Etherscan
.
This is due to the fact that the initial transaction object is not seeded with the signature's R
, S
components and the V
recovery parameter.
See the Ledger implementation for reference:
https://github.com/JoinColony/colony-wallet/blob/0298bd6087690394c18044c82f9de17914baa50d/src/ledger/staticMethods.js#L114-L130
Branch | Build failing 🚨 |
---|---|
Dependency |
eslint-plugin-flowtype
|
Current Version | 2.46.3 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
eslint-plugin-flowtype is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
<a name"2.47.0">
The new version differs by 10 commits.
45e86d8
Merge branch 'pnevyk-feat/array-style'
1d664d7
docs: correct documentation
a916617
Merge branch 'master' into feat/array-style
8f86c4b
docs: add eslint-config-flowtype-essential (#328)
6320bee
feat: Refactor array-style-...
rules
b95dd31
feat: Improve error messages
687f82b
feat: Change default array notation for simple types to "verbose"
4a6f03d
feat: Implement fixation in array style rules
afd4210
feat: Implement array style rules
1232069
docs: Add documentation for array style rules
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
This issue serves to track mostly adoption of the WebUSB
API standard.
Once that happens we can assign resources to develop a ledger transport based on that, which will make accessing the wallet a lot more easier.
This issue tracks implementation of the verifyMessage()
static method for the Metamask wallet.
This method takes in a SignatureObject
and returns true
or false
based on if the current address indeed signed the message.
This will make use of Metamask's version of web3.personal.ecRecover
method.
Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation
This issue tracks integration of the Digital Bitbox hardware wallet into the lib.
It should have the usual needed features:
PR #60 brings in a lot of utilities to validate, normalize, serialize and de-serialize the derivation path.
We should use them to provide safety checks for the derivation path in the Software Wallet as well.
This issue tracks implementation of the main Class and the open()
static method of the MetaMask wallet.
This will involve refactoring the core
module's genericWallet
class to support instating it with just the address
(currently it needs both the publicKey
and chainCode
to derive the addresses indexes)
Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation
As planned in the Roadmap, we are phasing out providers from this wallet library and offloading that functionality to the end user.
This library will not be responsible for communicating with the blockchain, it should function as an offline wallet.
This Issue serves to track the refactoring work needed to make this happen.
This issue tracks implementation of the signMessage()
static method for the Metamask wallet.
This method takes in a MessageObject
and returns a signature for the message, which than can be used to verify it.
This will make use of Metamask's version of web3.personal.sign
method.
Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation
While this is just a nice to have feature, I think there is a way to detect if the Trezor Hardware wallet is connected to the local bridge and, based on that, provide a status back to the user.
A rough idea on how to implement this, is to POST
a message directly to the trezor service (directly POST
not through the window
's Object instance post()
method) and listening for a response.
In not one of my proudest moments, I've named the method that connects to a json-rpc
service as localhost()
.
In retrospect this name choice is very poor and should be remedied.
Firstly because it's confusing and secondly because you can connect to json-rpc
server that is not hosted on your local machine...
Good names alternatives: jsonRPC()
or jsonRpc()
.
providers.js
autoselect()
methoddocs/api.md
)This issue is here to track small improvements that could be made to the software wallet module, but that are not currently urgent, so they are relegated to the backlog.
Improvements:
password
vs. pasword
. See: https://github.com/JoinColony/colony-wallet/blob/bb2d586374e30b03a108f418c742420757ae826c/src/software.js#L52-L58This was already implemented in the software
wallet module, since it works there, it should be brought over to the providers
module as well.
The idea is that the provider generator methods should instead of a number of arguments, accept only one, which is an object.
This helps with allowing the developer to pass in arguments (as that object's props) in any order, and won't require passing in undefined
or null
when wanting to skip an argument.
So, from this:
const etherscan = (network, token) => {...};
To something like this:
const etherscan = ({ network, token }) => {...};
This change should not take long to implement (mostly checks for object props), but the unit tests will take a while to change into the new format.
This is how the wallet object looks right now:
{
address: "0x75a..." // string containing the address
addressQR: (...) // async getter that returns a qr code image of the address
blockie: (...) // async getter that returns a blockie image of the address
defaultGasLimit: (...) // getter that returns the gas limit as a number
keystore: (...) // async getter and setter that returns the encrypted keystore (optionally sets the password for encryption)
mnemonic: "outer tissue..." // string containing the mnemonic
path: "m/44'/..." // string containing the mnemonic path
privateKey: "0xac2..." // string containing the private key
privateKeyQR: (...) // async getter that returns a qr code image of the private key
provider: (...) // getter and setter for the provider object
sign: (transaction) // transaction signer method
}
We have three main ways of opening a wallet: (return
ing a new instance)
private key
(will return
the whole wallet object, barring the mnemonic
and path
) -- currently implementedmnemonic
seed (will return
the whole wallet object) -- currently implementedkeystore
and accompanying password
(will return the whole wallet object) -- not implementedkeystore
encryption / decryption is a heavy operation (that's why the getter is async
and memoized
)
The software
wallet
module exposes two methods, open()
and create()
which both take in parameters in the form of an object (so they can be passed in any order)
Example:
import { software as wallet } from 'colony-wallet/wallet';
const newWallet = wallet.create();
const existingWallet = wallet.open({ privateKey: '0xac2...' });
Creating a new wallet is a synchronous operation, since anything that's heavy is deferred under async
getters until the user needs those values. (keystore, qr code images, blockies...)
Opening the wallet is as well synchronous (in the current implementation, using only private key
and mnemonic
).
The problem starts when trying to add the 3rd opening method, via keystore
/ password
. This is an async
operation and will return a Promise
.
Implemented naively this will screw with the expected return
value of the open()
method as in two cases it will return a wallet Object
, one case a Promise
, and a fourth case of undefined
in case something throw
s an error.
1. Implement via another method
Since we're using ethers
as a backbone for the software wallet, we can just do as they do and have another method.
But this really isn't an elegant solution
Eg;
export softwareWallet = {
create, //sync
open, //sync -- private key, mnemonic
openWithKeystore, // async -- keystore
};
2. Drop keystore support
We could just not support it, either temporarily (for the MVP) or permanently. But I don't want to cripple the library like this.
3. Partial asynchronicity
We can have the open()
wallet method be async
. This way we have a constant return
type when opening a wallet.
Eg:
export softwareWallet = {
create, // sync
open, // async -- private key, mnemonic, keystore
};
import { software as wallet } from 'colony-wallet/wallet';
const newWallet = wallet.create({ entrophy: new Uint8Array(42) });
const existingWallet = await wallet.open({
keystore: '{"address": "0xac2..."}',
password: 'decrypt-me-baby',
});
4. Full asynchronicity
While making the open()
method async
is nice for supporting all three wallet opening methods, it brakes consistency with the rest of the library which is mostly synchronous.
But making everything return a Promise
will solve that. And not just the wallet open()
and create()
methods, but extending this to the whole library, providers included.
(Actually for providers this is a nice thing, since it would allow me to improve the JsonRPC
provider and actually check the connection when initiated, not just when you want to have a transaction)
My gut feeling says to go with this since an fully async
library would actually make sense, especially in the context of ethereum.
Eg:
import { software as wallet } from 'colony-wallet/wallet';
const newWallet = await wallet.create();
const existingWallet = await wallet.open({ mnemonic: 'outer tissue...' });
@thiagodelgado111 @coyotespike @chmanie @JamesLefrere
If you managed to read through this, any thoughts, opinions or ideas are greatly appreciated 👍
This is due to the fact that all user facing method take arguments as a single Object
with varying number of props, and not the arguments directly.
We should warn the user that the arguments provided are not correct and maybe link to the documentation.
Most likely this will be done by creating a function factory.
There's an argument to be made that we should withhold the privateKey
(or the mnemonic
, or the keystore
) from the end user, from the standpoint of security.
The user will be able to interact with the wallet normally, but to prove his/her identity it must sign and verify a message (like all other wallet types expect you to do)
This will provide a more consistent mode of operation between all the wallet types.
On the other hand, the user already used one of those methods to open the wallet, so there's also the reverse argument that they are already known, so what's the point of hiding them?
When working in development
mode, we output a variety of warning or error messages to the console.
The way they are set up currently is they all reside in a message.js
file, which gets imported when needed to display them.
In production
mode the messages won't be shown anymore, as they are suppressed by the warn()
and error()
methods.
Problem is, those messages still get imported, and the methods are still called, even if they don't output anything. To make it even worse, all the messages get imported even if you tree-shake and just a use one module out of the library.
And as time goes on, this file will only get bigger.
Right know, I see three possible approaches to this:
development
mode (this would be best)This should be prioritized before the first release of the library.
At this point (after #56 and #57) we are in a position where we're able to write our own Software Wallet generator.
If we do this we remove reliance on external libraries like ethers
and all the extra weight that comes with.
While this is a nice improvement, it should obviously come at a later stage.
Trezor signs the message in a different format from the standard one, and as such, external services like MyEtherWallet
, MyCrypto
or Etherscan
can't verify the signature.
It can however be verified by the device internally since it uses the same algorithm to reverse it, which results in a correct signature validation.
Nonetheless we should warn the user about this when trying to call both signMessage()
and verifyMessage()
methods.
I'm putting performance testing in the backlog for now since it requires digging deeper into node
's and v8
's internals. (and right now the priority is to get the wallet up and running)
The way performance testing is supposed to work is to run through wallet methods (eg: create()
) a large amount of times and average the completion time. This way we can test when adding new features that the wallet creation process remains under a certain `.
Problem is different environments have wildly different results.
Examples (all values in the array
s are in ms
, for a number of 10
runs):
Chrome:
[ 153, 115, 96, 99, 97, 94, 95, 95, 90, 97 ]
Node:
[ 309, 272, 251, 242, 246, 247, 244, 244, 244, 244 ]
Jest:
[ 699, 684, 665, 660, 649, 662, 653, 659, 649, 665 ]
This needs to be investigated further, otherwise we won't be able to rely on these values.
Initially this was attempted during the #8 PR.
I've attached a patch
with the initial code setup so when we revisit this, my work won't be lost / repeated (but since Github doesn't allow patches for some reason, I had to add it to a gist)
https://gist.github.com/rdig/f80a4ca1a4a4d3fbc1c73a6543c8bff6
This Epic tracks improvements needed (or just nice to haves, but that are planned) for the trezor hardware wallet.
Right now the projects's type coverage hovers somewhere around 65
-70
%.
I want this to go over 80
%.
While this is not a big hurdle, in the interest of time, this is not a priority and will be backlogged (until all wallet types are implemented)
Also, this should add a flow coverage reporter (eg: flow-coverage-report
) and set that up as a CI
step.
Branch | Build failing 🚨 |
---|---|
Dependency |
ethers
|
Current Version | 3.0.15 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
ethers is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.
The new version differs by 1 commits.
3cb21dd
Added timestamp to EtherscanProvider history (#174).
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
Even though the verifyMessage()
method is available to the user in the Software Wallet via it's inherited prototype
(Remember, we're extending ethers
's Wallet
class
), it's not easily visible trough Object
discovery or prop
enumeration
.
We should expose this method directly on the SoftwareWallet
instance.
Along the way we should normalize and validate both the input and the output.
This issue tracks integration of the Ledger Nano S hardware wallet into the lib.
It should have the usual needed features:
Since we are relying solely on Trezor's servers to operate the Trezor Hardware, it's a good idea to make sure that the service is up and running before attempting to create the new TrezorWallet
instance.
This could be done by making a OPTIONS
fetch()
request to the Trezor service and checking if the reponse status is 200
.
This issue is here to track (and remind of) the needed changes that are required to the package in order to be released via Github and NPM.
package.json
entry (dist
was changed to lib
)readme.md
with colony logo / headerThis issue tracks implementing a static method to detect if the Metamask extension is available, and maybe, detect if it's unlocked or not.
This can be done by basically checking for the availability of the web3
global object. (injected by either Metamask or Mist): https://github.com/MetaMask/faq/blob/master/detecting_metamask.md#detecting-metamask
Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation
This issue tracks integration of the Trezor hardware wallet into the lib.
It should have the usual needed features:
This issue tracks implementation of the sign()
static method for the Metamask wallet.
This method takes in a TransactionObject
and returns the transaction's signature, in hex
string format. This can then be sent to the blockchain via a provider.
Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation
Most likely this will be a hard blocker!
This is because Metamask doesn't trust it's users to sign they're transactions without also broadcasting them.
Metamask currently only allows us to boardcast the transaction when signing it. We can't just sign it, and then broadcast it some other way.
This is a limitation for us since this library is an offline wallet (well, with the exception of this anyway...)
This is issue is here to keep track of Metamask's development, and when (or if) it gets implemented, bring the functionality in.
Issue to track: MetaMask/metamask-extension#3475
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.