dob / tap Goto Github PK

Fork metamask and add some of our attestation data for specific transactions to the UI. More on this ticket TBD.

Right now we have a contract/function level page that shows the attestations. Create the contract overview page with high level contract metadata and a list of the functions. This can be generated for a contract after it's been verified.

When TAP becomes hosted, we'll need to make sure the initializer does the right thing. Can't expect every user to be running a local IPFS node.

We had talked about using an on chain registry to map method names to hex method IDs, since users will want to use names like endAuction(uint), but the contract will need to receive 0xb3a3348a.

I think this logic should probably just remain in the frontend for now. The ABI lives on ipfs, so the frontend should just have a convenience library which parses the ABI and generates a js object with keys as the 4 byte methodId and values as function signatures (types only, comma separated, no spaces). The frontend can use this to populate human readable names where necessary, but will always submit the IDs to the contract transactions.

Is there any use in the contract itself for having the human readable names accessible? Maybe it would make for an easier interface for 3rd parties to submit or lookup attestations...however it's also error prone to typos, since on chain they're really only referenced by ID.

TAP will be more self sustaining and useful if there is an incentive to provide attestations. This incentive can be in the form of reputation that you earn for providing valuable attestations, but it can also be economically driven, in the form of Bounties. A bounty would work as follows:

• Whoever verifies and contract can optionally provide a bounty for providing attestations for that contract.
• Whoever wants to use the contract can optionally add to the existing bounty.
• Bounties would be distributed to attestations at certain time milestones depending on quality of the attestation as deemed by the community through voting, weighted by reputation of the voters and authors of the attestation.

The final statement is easier said than done. It's hard to come up with a scheme for reputation, voting, and distribution that isn't gameable. We welcome input on using any existing on chain contracts that handle reputation and voting protocols, or pointers to specific designs that work well. Steem protocol, actually does a good first pass job at this, however implementing all of the complexities that it has accounted for is well beyond scope for a first pass alpha of TAP.

Right now there's no way to look up all attestations for a given user.

The homepage should...

1. Link to featured contracts
2. Link to "verify contract" page so people can submit other contracts for attestations.
3. Provide a way for people to navigate to a specific contract or contract/method combination if they know it. Probably via a search bar.
4. Show off the consumer use case...aka metamask integration...so that consumers know how to get value from our service.
5. Link to the about/FAQ page that describes in detail what's going on here.

Right now we only store the verification result on the blockchain. Is there a way for the contract to make sure the verification JSON is valid? (For example, right now I can pass in a fake verification that points to fraudulent code)

Implement whatever design framework we decide on across pages. It's actually easier if this is done up front so that we can use the right patterns across subsequent pages. Should we pick a site we like and take inspiration from it's UI elements/colors/layout? Any ideas?

Figure out voting rules and UI to add to attestations page.

Before we move to alpha on the Ropsten testnet, we'd like some feedback from the community in terms of what data users can actually provide in an attestation that would be useful. The current schema example is: Attestation Example

It basically includes:

• method description
• method signature
• boolean fields about whether it usesGas, acceptsETH, sendsETH, has known exploits, can update asset ownership, calls external contracts
• overall risk level in using the function
• descriptions of the cases where it throws, calls external contracts, and known exploits.
• Information that lets you verify who provided the attestation.

What fields are missing? What else would you like to see in an attestation. We'll take all feedback and publish an alpha version before going live.

Right now we're calling a 3rd party service to compile the solc contracts for verification. Eric built browser-solc, so we can integrate this to allow TAP to run decentralized.

Right now the homepage lets you create an attestation by pasting the IPFS hash. Instead you should fill out the form fields, which will generate the IPFS file for you. Bonus points if this file is signed by the user's Ethereum private key to prove that they were the author.

If the contract isn't verified yet, then they'll need to verify the contract first by providing it's code, which I'll file in issue #3.

Before attestations for a contract can be provided, a contract must be verified. This requires pasting it's code. And if we follow etherscan's lead, it may require choosing your compiler version so that we can do the proper verification. Perhaps to start we can just support contracts with pragma statements that list the compiler version.

We can create a verify contract page to get contracts into the system so that people can provide attestations, and we can link to it from the create attestation page described in #2

The latest commit that allows you to loop through multiple attestations and display them all doesn't seem to be working locally for me. This is a reminder to fix that bug, but in the meantime you can just fetch attestation(0) instead of looping through them all.