andytudhope/statusseekers

An initial proof of concept for part of an interactive artwork with the Ethereum community and the wonderful Jessica Angel.

Status Seekers

This is an initial proof of concept for interacting with a very simple set of smart contracts as you explore an upcoming artwork by the Truebit team and an amazing artist named Jessica Angel.

The basic idea is to create a number of smaller installations - quite literally just QR codes - that people will need to find by exploring the much bigger piece being created by Angel et al. The whole idea is to bring into the physical world a tactile, interactive space which represents the radical shift now underway in the way we organize through decentralized networks incentivized by tokens. If we can get people to explore that space with deep attention to it's minute details, that will be a great success. We need better and bigger metaphors if we are to form properly the sorts of intentions that will make networks like Ethereum truly world-changing.

Moreover, we think that being able to illustrate that all it takes in order to interact with and benefit from using thse networks is a piece of technology that already exists in your pocket and with which a growing majority of the world is already familiar, then that will be the cherry on top.

As always, this is about The State of Us.

Instructions

Easiest setup ever!

First of all, make sure you have Status installed. The latest android builds can be found here. If you require an iOS TestFlight invite, please join our chat and ping me @cryptowanderer and I will add you to our list of testers.

Once installed, open the chat with Console and select the @browse suggestion just above the keyboard input. Naviagte to https://andytudhope.github.io/StatusSeekers/ and play to your heart's content.

We have not yet implemented the NFT collectible part yet, and are looking for help with rendering images in the frontend, on resource-restricted devices using js. There are essentially 2 approaches we can take, depending on ease and performance.

1. Use processingjs to render the images on the frontend. Each new level corresponds to a new dimension or attribute to the virtual creature being created as you wonder through the physical structure.

2. Use the seed drawn by the user that is used to construct the first 40 bits of the tokenID, and then put that through a program like DeepDream 12 times with certain features turned on/off depending on the info returned from the new tokenLevel.

Getting Set Up Locally

Once installed, open the chat with Console and select the /debug suggestion just above the keyboard input. Turn debugging on.

You will also need to make sure you have status-dev-cli installed, which you can clone from here and that you have either testrpc or Ganache installed. I happen to be using Ganache right now to illustrate more visually to my friends what is going on. You can get it here.

Run status-dev-cli scan to ensure that the cli tool can talk to your device/emulator. It should return the device's IP address, which we'll need later.

Start Ganache once all of that is done (or testrpc, or just truffle develop depending on your preference).

Clone this repo and do the necessary node things:

git clone https://github.com/andytudhope/StatusSeekers.git && cd StatusSeekers/
npm install

Make sure that the rpc port listed in truffle.js is pointing to the correct place. Currently it is set up to talk to port 7545 because that is where Ganache is listening. Change it if you need to.

truffle compile
truffle migrate

Now, we need to make sure that Status is listening to the network onto which we have just deployed our contract with the migrate command. If you're using an Android phone like me, you'll also require some adb magic. If you're on iOS or in an emulator, you can skip the last two steps below:

status-dev-cli switch-node "http://localhost:7545" --ip <DEVICE-IP>
adb reverse tcp:7545 tcp:7545
// The next line is required because this example is set up to serve the web frontend on port 3000
adb reverse tcp:3000 tcp:3000

We're finally ready to run the actual app and have it talk to our simple smart contract so that we can start seeking the words required to unlock the reward! Make sure that you pass in your device's IP as an environment variable, otherwise the start script will fail.

IP=<DEVICE-IP> npm run start

Happy hunting!

Sketch of The Seeker Game

Step 1: Show up at the event and download Status.
Step 2: Draw a seed and take a photo of it using the Status Seekers DApp. (Step 2a: This gets submitted to our NonFungibleCollectible contract and is used to set the first 40bits of your unique token)
Step 3: Explore and interact with the #ArtProject structure (a klein bottle!)
Step 4: Find QR codes hidden around it.
Step 5: Scan the codes you find
(Step 5a: First thing that happens is that you get a keyWord back directly from the StatusSeekers contract. Collect all 12 and you can use them to reconstruct a private key and get access to our reward account. Hints to the order are also in the structure.
Step 5b: Scanning the QR will also send a message to our server, where we handle off-chain signing and verification, as well a the gas costs involved there. Using this setup, we can return to the user the next "level" of their collectible and use the information contained in tht level to render another attribute/dimension.)
Step 6: Gaze in wonder at your 12-dimensional crypto-creature-creation after having a mind-blowing experience exploring the interwoven klein bottle bridge mapping Dogethereum transactions. Yes that is a valid sentence. What a time to be alive...

You'll notice that the StatusSeekers contract is fully reusable. Essentially the idea there is that the owner can add any 12 keyWords they like. We can then add the rewardKeyWords, which are hashed (with a 256-bit nonce), in the correct order and - when someone thinks they have the right order, they can submit it for verification to the contract. The #ArtProject is about a really cool bridge, sure, but the vision is definitely longer term and revolves around setting up a whole decentralized artistic community and we want to play this game all over the world, in all kinds of structures!

Please take a look through our unit tests for the NonFungibleCollectible contract and let us know what you think. We are also very keen to hear ideas about the best way to actually render images on the frontend in a slick and nevertheless artistic way.

statusseekers's Issues

Add Smart Contract to Handle Receiving Digital Art Pieces (NFTs) in Physical Art Work

Currently, we have only one simple smart contract that returns 1 of 12 key words which can be used to unlock a Status account that is preloaded with a reward.

The inimitable Will King has suggested that we add the ability to find unique NFTs in addition to the simple key words - i.e. we want to make it possible and easy to get your own digital art pieces from within the larger, physical artwork :mind_blown:

My feeling on this is that we write a smart contract that can hold an array of NFTs and can send them to whoever sends the correct signed transaction to them first.

The required function(s) would take as parameters some random data included only in the QR (which poses some interesting security challenges) and the receiver's address, check if it has already been sent (and prob fire an event if it had so we could gracefully display Art already claimed to the slower seekers), and if it hasn't pass on ownership of the NFT to the first person to find it.

This particular issue is only for the smart contract itself to feel out if this is even possible. Would love some feedback from @JasoonS, @3esmit and @shrugs (and others that I will mail) before setting up a bounty on this and then getting the frontend side of thing set up (will be done under separate issue & bounty).

Biggest and most immediate issue is how to do this without incurring gas costs for users who have just installed Status...

NFT contract that adds attributes

Refactor the NFTCollectable contract to handle a slightly new direction for our NFTs.

1. We have decided each person will only get one NFT, with 13 levels
2. This NFT will be generated based on an image the person draws
3. Scanning additional QRs will cause more levels of the NFT to be filled (bitwise shifts)

For my own reference, each new level will cause the UI to generate another part of the image procedurally.

Gas costs of stub vs. 12 small contracts vs 1 contract with array[12] and events

You will notice that this PoC just has one contract - StatusSeeker1 which stores just 1 of the 12 words that will be required in the artwork itself.

The next step here is to figure out what the gas costs of deploying 12 contracts exactly the same to the one example currently in this repo are, versus using some sort of stub (which I don't know a lot about and plan on bugging @3esmit about), versus stick all 12 words in an array in one contract:

pragma solidity ^0.4.18;

contract StatusSeeker {
    string[12] public keyWord = ['cradle', 'race', 'tree', 'wave', 'wind', 'high', 'sit', 'dog', 'cat', 'full', 'art', 'rocks'];
}

and simply pass in the correct key as part of the data generated by the QR so that participants can't guess where in the array that particular word comes from:

web3RPC.eth.getAccounts(function(error, accounts) {
      console.log(accounts)

      statusSeeker.deployed().then(function(instance) {
        statusSeekerInstance = instance

        // Get the key word for this contract
        return statusSeekerInstance.keyWord(3, {from: accounts[0]})
      }).then(function(result) {
        // Update state with the result.
        return self.setState({ keyWord: result.toString() })
      })
    })

But that does not seem to be working currently. Looking into it further.

Improve KeyWords Smart Contract to Use Hashes and Nonces

Fairly self-descriptive: we want to improve the KeyWord smart contract such that it uses hashes of the words rather than the words themselves being stored directly on the chain and potentially add some nonce protection too, just to make it that much harder for any potential attacker.

Basic DB to store NFT associated with account, level and IPFS hash of image

Title is descriptive enough here - we just want to have more certainty than localStorage can provide that the user will always be able to find and see the NFT they made-found.

Add redux state management for authenication setup

Use redux to manage the back and forth messaging between user and server to verify their address and issue them a session token (JWT)

LevelNFT initialization based on image drawn by user at start of event

(This fits in as number 2 from issue #9 )
This will be used to create the users initial token:

1. Add Javascript to commit a photo submitted to the server to IPFS.
2. Use the first 40bits to seed the users token.
3. Save this IPFS hash in the database with the users address.

Initial NFT implementation and verified distribution mechanism

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.

Add Button and Display Image associated with NFT

Put in a new button that will spoof scanning a QR code meant to return an NFT rather than 1 of the 12 key words.

This will involve a call to the server (a simple Express API) that will take the tokenID found by the user sign the transaction, submit it and return to the user the new information regarding their token which we will use in another issue to render an image in the webView associated with that level (each level translates to a new "dimension" or attribute of the token.

Extra points here for some javascript the can generate procedurally a new part of the image when further attributes are added to the NFT on additional scans.

Verify a user is the owner of the address they claim to have via signatures on the server.

Essentially this will authenticate the user with the server.

A nonce, challenge response, salt etc can be added to strengthen the security, but all of this will go through this single authentication function.

Store found words in a drag n drop component

Type

Feature Request

Description

Currently, call()ing the smart contract will return randomly one of the 12 words required to unlock the Status account with a reward in it. However, it does not store them anywhere.

I would like to:

1. implement a Redux store for this,
2. split App.js into more bite-sized components and
3. have a simple div that will display the words and allow users to drag around and re-order the words into what they think is the correct order to unlock the reward account (based on cues provided on the art work itself).
4. They should also be able to easily copy all 12 words once found and reordered so that they can submit them to the bot to be checked.

Simple version of this might be achieved with react-dragula

A more complete version, and the one I think I am really after would likely be best achieved with react-dnd in tandem with the touch backend.

Requirements

1. Remove the explanatory text currently there as a placeholder.
2. Move the Get Key Word button to the top of the page and change it to Scan QR Code. This has not been implemented yet though, so keep the current logic the same for now (issue for this is here)
3. Implement steps 1 through 4 outlined above so that each word returned after pressing the button is stored in a new div where it can be easily dragged around and re-ordered.
4. Refactoring App.js into separate, more modular components, and using a Redux store (or some other efficient way of passing data between components) is actually the crux of this bounty. PRs that don't do this will not even be considered.
5. Extra points for animations.

Notes

In case you're thinking, "It would be awesome and even more intuitive if, instead of a copy button at the bottom there, we could just submit the words directly from the DApp to the bot", the answer is: "Yes, it totally would be. But that functionality does not yet exist and is on the list of things to do along with QR code scanning."