Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial NFT implementation and verified distribution mechanism #6

Closed
JasoonS opened this issue Jan 13, 2018 · 7 comments
Closed

Initial NFT implementation and verified distribution mechanism #6

JasoonS opened this issue Jan 13, 2018 · 7 comments
Labels

Comments

@JasoonS
Copy link
Contributor

JasoonS commented Jan 13, 2018

The purpose of this is to allow users to claim NFTs (see discussion #5) that are 'found' while exploring the artwork. The key takeaway is that the user will execute the claim themselves with an Ethereum transaction via Status, rather than having it issued to them directly.

One approach would be to use the approveTransfer/delegateOwner function in the NFT standard, but this requires the server to execute a transaction first before the user can claim the token. This works fine, however it makes sense (since there is a server) to allow the server to sign this approval off chain allowing the user to claim the tokens immediately.

This method will use web3.eth.sign(account, hash) server side, and ecrecover in the smart contract.

The completion of this issue will include:

  1. the server side javascript to sign the transaction correctly.
  2. an implementation of the ERC721 standard (NFTs)
  3. a function in the smart contract to reward a user that has a correctly signed message.
  4. Truffle tests to verify this works correctly.
@JasoonS JasoonS changed the title Initial NFT implementation and Verified distribution Mechanism Initial NFT implementation and verified distribution mechanism Jan 13, 2018
@JasoonS
Copy link
Contributor Author

JasoonS commented Jan 13, 2018

(@andytudhope This is a very simple, single purpose issue, so it doesn't include a full server setup, or any UI on the DAPP yet. Do you prefer keeping the issues granular like this?)

@andytudhope
Copy link
Owner

Si signor, I do indeed. Will post a relevant bounty in a moment, thanks. How long do you reckon it'll take you (in hours) @JasoonS?

@JasoonS
Copy link
Contributor Author

JasoonS commented Jan 13, 2018

Ok great, I reckon 3 hours should be enough time, so 4 to be conservative.

@status-open-bounty
Copy link

status-open-bounty commented Jan 13, 2018

Balance: 0.000000 ETH
Tokens: SNT: 250.00
Contract address: 0xc04a24af0a32b4b1cd50a266cb6dcb0f625d9497
Network: Mainnet
Paid to: JasoonS
Visit https://openbounty.status.im to learn more.

@eordano
Copy link

eordano commented Jan 17, 2018

Hi y'all, I've been following this project and I think we've got pretty similar ideas. Are you doing this as part of Truebit's exploration of current project pains?

Also, I'd like to invite you to take a look at ethereum/EIPs#821 as a better proposal for NFTs. I see you mostly used OpenZeppelin's implementation and as "grandfather" of it I'd suggest you consider using https://github.com/decentraland/erc821

@andytudhope
Copy link
Owner

andytudhope commented Jan 17, 2018

@eordano first off, thanks for swinging by this lowly repo :mind_blown: Am looking into your suggestions now, thank you!
Not really about exploring project pains for Truebit - this is about making a DApp that will be usable in their #ArtProject initiative.
tl;dr they are building a massive physical structure to show irl the Dogethereum bridge and let people interact with it. We want to plaster QR codes throughout it that people can scan via Status, thereby being forced to interact with and explore the structure in order to:

  1. collect 12 keywords that can be used to unlock a Status account with a reward in it.
  2. collect cool NFTs made by all the artists who are flocking into the community as the #ArtProject is intended to spark off a sustainable artistic community on Ethereum, not just be a one time thing.

Full proposal for the Status involvement with this can be found here.

@JasoonS
Copy link
Contributor Author

JasoonS commented Jan 17, 2018

Hi @eordano, thank you, I'll definitely keep an eye on the progress of EIP821 and look into it's differences. And yes, I took that implementation from what OpenZeppelin are working on (still unpublished as far as I can see).

I think we'll stick to the current implementation, and update and refactor as necessary based on conversations around EIP821 and EIP721 (You're welcome to disagree @andytudhope ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants