-
Notifications
You must be signed in to change notification settings - Fork 33
ERC725: Attestations and users #152
Conversation
This will allow it to be accessed from both ClaimHolder and ClaimHolderPresigned
The name `create` conflicts with a Truffle method (it conflicts with something anyway - I am guessing it's Truffle)
This one is different than the other resources. Takes in different config options.
We can predict where a contract will be deployed, thus presign claims for an identity that does not exist yet. See: https://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
origin-js should validate all attestations, and only return the ones that are valid.
This is required for now so that issuer will be passed in. We can refactor this later.
Now the user directly calls the identity contracts, and the identity contracts add themselves to the user registry. This seems cleaner and simpler, but the real motivation to refactor was to allow identity contract addresses to be reliably predicted before they are actually deployed (for creating presigned claims). If the identity contract is deployed directly by the user, then its address can be predicted safely. If it is deployed by a shared user registry contract though, that opens the door to race conditions where other people might be deploying identities at the same time.
We can and should just accept wallet as input - users of origin-js should not have to worry about the identity contract itself (for now). We're managing that behind the scenes.
ClaimHolder -> ClaimHolderRegistered -> ClaimHolderPresigned This way we can use ClaimHolder on its own without a constructor that tries to add itself to a user registry.
Instead of hard-coding a single key, we have a single "hard-coded" identity contract that can have multiple keys - so we can use multiple keys to sign attestations if we want to or need to. This complies with the design of ERC725/ERC735.
We shouldn't be loading json files and using truffle-contract in the tests. Depending on how the tests are run, the files may not have the correct network addresses. The tests should be able to be run in an isolated environment, regardless of the state of the json files.
We're using a master origin identity contract to keep up with issuers. No need for the config option now. (Eventually might allow people to pass in the address of one or more trusted attestation identities - for now we'll just manage that automatically.)
Once data leaves the attestation resource, we'll assume that it's been hashed
This results in double hashing if your data is already hashed. That was a bad idea in the first place.
This will allow consumers of this library to simply pass in the state that they want (both the profile and attestations). In other words, this efficiently replaces the existing user with whatever is passed in. (The only exception to this is removing attestations. We won't worry about that for now.)
Because we're just fetching from the logs, we want to make sure to get the most recent so that profile updates work. Sooner rather than later we should move away from using the logs like this.
Of course there's no real distinction between private and public, but it's easier to read if we keep the "public" methods at the top
This is a really nice library that lets us mock the fetch object for http requests. Makes it a breeze to write tests that make external http requests.
This carefully stubs out the server response and asserts that each request uses the correct method, url, and params. As long as we keep the test expectations in line with the actual bridge server, we get decent confidence that this code will work with the bridge server.
We can do this since we're on 1.0 now. :D
Just to be safe
It doesn't add any new functionality, strictly speaking. The same thing could be accomplished by creating a contract that does the same thing. I basically just created this as a convenience for clearing users between tests. We can refactor later if we think of a cleaner solution.
b05f3cc to
d18dddb
Compare
nick
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really awesome work!
| "babel-polyfill": "^6.26.0", | ||
| "bs58": "^4.0.1", | ||
| "cross-fetch": "^2.1.1", | ||
| "ethereumjs-util": "^5.2.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nick No I don't think it's needed. It's currently being used for attestation signature validation.
origin-js/src/resources/users.js
Line 189 in d18dddb
| async isValidAttestation({ claimType, data, signature }, identityAddress) { |
We should be able to do all this with web3. Created an issue for it so I don't forget. #153
| arguments: args | ||
| }) | ||
| .send(options) | ||
| .on("receipt", receipt => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we listen for the "confirmation" event instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nick I'm actually not that familiar with this API. I just looked at what we're doing in ResourceBase.contractFn with waitTransactionFinished and did the same thing here.
https://github.com/OriginProtocol/origin-js/blob/master/src/ResourceBase.js#L24
|
@tyleryasaka one nit-pick: when running |
|
@wanderingstan That output is coming from the new web3 version 1.0, rather than anything I changed in this PR. The various I think we should remove |

Checklist:
developbranch instead ofmasterDescription:
This adds 2 new resources,
AttestationsandUsers. They are extensively documented in my docs PR.Some other things going on:
Example usage in demo-dapp
Can use
attestationServerUrl: "http://bridge-server-test.herokuapp.com/api/attestations"in config. That's a heroku app that's up and running right now.Just to make this easier to review and understand.
Can stick this in
src/services/origin.js(indemo-dapp):