owocki commented 6 years ago

what

An important part of the Ethereum Ecosystem

ETHAvatar - a gravatar-like app, but instead of attaching images to emails, it attaches avatars to ETHereum addresses.

what, technically

create a basic webapp that, when a form is submitted, uploads an image avatar to IPFS.
webapp should then attach your ETHavatar to your web3.eth.coinbase in a smart contract which you build and deploy to rinkeby, and then, once tested, to mainnet
smart contract should store an IPFS hash of a metadata blob with metadata like title, image width, image height, etc...
smart contract should have a 'getter' so the user can get the image IPFS hash and the IPFS metadata hash
if a 2nd image is uploaded, it will overwrite the first image
if the get is called on an image that does not exist, return an IPFS hash which contains an identicon

design

do not worry about the frontend design. once you have built an app that works functionally, we will apply a design to it.

bounty

code this application up, open source the code (both the webapp and the smart contract), and deploy it to heroku (or similar) so it can be tested without having to deploy it.

if you wouldnt mind delivering code samples for posting an ETHavatar and GETing an ethavatar, thatd be great too. wed like to display these on the landing page of the site

mbeylin commented 6 years ago

My advice is to use a 2-tiered IPFS model where you first upload the image to IPFS, and then upload a JSON object which includes the metadata (including the original file hash, it's dimensions, etc). This will significantly cut down on the necessary gas costs of such a tool.

gitcoinbot commented 6 years ago

This issue now has a funding of 0.23 ETH (198.64 USD) attached to it.

If you would like to work on this issue you can claim it here.
If you've completed this issue and want to claim the bounty you can do so here
Questions? Get help on the Gitcoin Slack
$9176.38 more Funded OSS Work Available at: https://gitcoin.co/explorer

owocki commented 6 years ago

from consensys slack: Most popular use-case would probably be adding images to token contracts. Get AirSwap to adopt it :slightly_smiling_face:

tarekskr commented 6 years ago

I love the idea and would love to work on it! What time frame do you guys have for this?

owocki commented 6 years ago

hey @tarekskr -- the bounty is set to expire in about a month.. would that timeframe work for you/

gitcoinbot commented 6 years ago

Work has been started on the 0.23 ETH (97.14 USD @ $422.33/ETH) funding by:

@tarekskr

Please work together and coordinate delivery of the issue scope. Gitcoin doesn't know enough about everyones skillsets / free time to say who should work on what, but we trust that the community is smart and well-intentioned enough to work together. As a general rule; if you start work first, youll be at the top of the above list ^^, and should have 'dibs' as long as you follow through.

On the above list? Please leave a comment to let the funder (@owocki) and the other parties involved what you're working, with respect to this issue and your plans to resolve it. If you don't leave a comment, the funder may expire your submission at their discretion.
- Learn more on the gitcoin issue page
- Questions? Get help on the Gitcoin Slack
- $3787.64 more Funded OSS Work Available at: https://gitcoin.co/explorer

tarekskr commented 6 years ago

@owocki yes a month seems reasonable. I'll start this Fri and will keep you guys updated.

cleanunicorn commented 6 years ago

You would also need a mechanism to prove that you own the address.

tarekskr commented 6 years ago

@cleanunicorn you prove you're the owner by calling the smart contract from the desired address, no?

tarekskr commented 6 years ago

Guys: I need your opinion on how to proceed with storing the IPFS hashes in the smart contract. We basically have two options:

Store it as bytes32. This has some pitfalls that I'll explain below.
Store it as string. This roughly costs users an additional 65% more gas than bytes32.

When using bytes32, the contract caller must convert the IPFS hash into 32 bytes, while the original IPFS hash is 46 bytes as it is. However, since IPFS uses Base58 to encode its addresses to start with, the hash can be converted back into 34 bytes by using bs58.decode(). Furthermore, we can trim the first two bytes since they're always constant, allowing us to finally reach 32 bytes. The whole process is described in a lot more detail here.

My problem with the above scenario is that it's not future proof at all, and will completely break in case IPFS decides to change the format of its hashes. What do you guys think? Do you have any ideas where we could use bytes32 and still future proof this?

owocki commented 6 years ago

what magnitude of gas are we talking about? 65% difference means much more in the case of 21000 vs 210000

tarekskr commented 6 years ago

About 85,736 gas for string (~ $0.22 @3 Gwei) vs 28,624 for bytes32 (~ $0.07 @3 Gwei).

tarekskr commented 6 years ago

FYI: I just posted on reddit asking the IPFS team for their input. https://www.reddit.com/r/ipfs/comments/8221ru/future_changes_to_the_ipfs_hash_format/

owocki commented 6 years ago

@tarekskr first off; thanks for doing such extensive research on this. its great to see how thoughtful youre being :)

second; what is your take of the responses on the reddit thread? i have some thoughts about maybe saving gas in the meantime but building the contract to be future-proof also... but would love to hear your thoughts before i go too deep into that.

cc @mbeylin

mbeylin commented 6 years ago

Based on the comments of the IPFS team, it seems like they want us to future-proof it, which would mean adding those 2 extra uint8s to the storage. Because of how weird solidity works, it's actually cheaper for us to just use 2 uint256's instead of uint8s. I haven't checked the gas costs of this method vs the string array but something tells me the savings will be much smaller than we had originally expected.

tarekskr commented 6 years ago

@owocki it's really my pleasure :)

I was actually just going to suggest that we stick with string. It's clear from the IPFS subreddit discussions that any hack to fit the hash into 32 bytes isn't future proof at all. Furthermore, all the suggestions involving storing the size & type in additional uint8s or even having two bytes32s to provide some redundancy, all these bring us really close to the cost of the string we're trying to avoid.

To reduce gas costs to the absolute minimum, I am planning to have the smart contract only store the hashes without any other metadata. Everything else including the name, size, etc. will be stored in IPFS (similar to what @mbeylin has kindly suggested earlier). This should also help keep our smart contract super simple and a lot easier to inspect and debug.

owocki commented 6 years ago

I was actually just going to suggest that we stick with string

+1

To reduce gas costs to the absolute minimum, I am planning to have the smart contract only store the hashes without any other metadata.

+1

tarekskr commented 6 years ago

Regarding the image: I propose we enforce a 1:1 aspect ratio, just like Gravatar does. This will make it much easier for 3rd party websites to integrate EthAvatar into their content.

owocki commented 6 years ago

Strong ➕

tarekskr commented 6 years ago

Great, working on that.

Btw I was thinking that one of the really great uses of this project is account verification. If I am sending ETH to an exchange for instance, I'd love to see the exchange's logo as soon as I paste the address in my wallet, this way I know I've got the correct address. People are always paranoid about missing a letter and losing all their money, and this is an excellent way to verify they got the correct address.

Super excited about this!

owocki commented 6 years ago

Btw I was thinking that one of the really great uses of this project is account verification. If I am sending ETH to an exchange for instance, I'd love to see the exchange's logo as soon as I paste the address in my wallet, this way I know I've got the correct address. People are always paranoid about missing a letter and losing all their money, and this is an excellent way to verify they got the correct address.

this.. 💯 times this!

tarekskr commented 6 years ago

Smart contract now deployed to rinkeby and dapp to Heroku: https://eth-avatar.herokuapp.com/

To use, please make sure the 'rinkeby' network is selected in MetaMask or your favorite Ethereum browser. Please excuse the really primitive UI :)

Your feedback is highly appreciated!

Source: https://github.com/tarekskr/eth-avatar

vs77bb commented 6 years ago

@tarekskr Just dropping in 👀, dApp seemed to have trouble loading - just FYI.

You're doing fantastic work on this so far. ➕ to exchanges and individuals both using this - will be an immediate UX boost. I almost want to loop in Dan Finlay on this @owocki, but I'll let you guys keep going a bit further down the road for now 🙂 Glad you checked out Gitcoin and good luck as you continue!

tarekskr commented 6 years ago

@vs77bb thank you so much! :)

Are you getting any errors on the page or the console? I am assuming you're on 'rinkeby', correct?

EDIT: One other thing that could be happening: the Heroku dyno could be still waking up since we're on the free plan and dynos shut down after a certain period of inactivity.

owocki commented 6 years ago

awesome! this is fast progress.

qa notes:

this is what i get when metamask is locked: http://bits.owocki.com/2e311F3c3n3j/Screen%20Recording%202018-03-07%20at%2010.13%20PM.gif
avatar upload is pretty slow.. not sure if theres an easy way to make this better
mind submitting a WIP PR against this repo? https://github.com/gitcoinco/ethavatar
success! it works... awesome!

alejandro-isaza commented 6 years ago

May I suggest using Jdenticon instead of blockies? Is what we are going for in Trust wallet. They look a lot better.

tarekskr commented 6 years ago

@owocki

Thanks for reporting, will fix.
Time is mostly waiting for the Ethereum transaction to process. Will probably be even slower on main net. This is basically an Ethereum limitation, will get faster as the network throughput scales.
Will do as soon as I fix (1.)
Awesome, love your avatar! :)

owocki commented 6 years ago

i do agree they look better but id be curious to hear from @tarekskr whether its too complex to change course now

owocki commented 6 years ago

Time is mostly waiting for the Ethereum transaction to process. Will probably be even slower on main net. This is basically an Ethereum limitation, will get faster as the network throughput scales.

i dont think it is.. theres about a 25 second wait to even confirm the tx in metamask... maybe this is IPFS upload?

owocki commented 6 years ago

@tarekskr @mbeylin @aleph7 here is a design bounty for this project https://github.com/gitcoinco/skunkworks/issues/63

tarekskr commented 6 years ago

i dont think it is.. theres about a 25 second wait to even confirm the tx in metamask... maybe this is IPFS upload?

IPFS upload happens before MetaMask shows up, and doesn't take more than a couple of seconds max. I'll retest this and see what's going on.

tarekskr commented 6 years ago

@aleph7 I used blockies since it's already being used by Mist, Augur, and several others I believe. I personally liked Jdenticon more, but couldn't find a React component for it.

owocki commented 6 years ago

hey @tarekskr i've registered ethavatar.com and i have a server to run it on (instead of heroku).. can you send me your ssh public key pls?

also, is ubuntu 16.04 okay for the server?

tarekskr commented 6 years ago

i've registered ethavatar.com and i have a server to run it on

Awesome! Please find my SSH public key here: https://pastebin.com/EUkwNSRB

Ubuntu should be perfect 👍

owocki commented 6 years ago

@tarekskr can you send me an email so that i can send you the ssh login information in a place thats not public? kevin@gitcoin.co

i am also on the gitcoin.co/slack slack if thats a better place

tarekskr commented 6 years ago

can you send me an email

@owocki sent.

I've also fixed the locked MetaMask issue you were having earlier. Will create a PR shortly.

owocki commented 6 years ago

just sent you the ssh info for the server (which ethavatar.com points to).. do you think you could deploy the app to that server?

mbeacom commented 6 years ago

Following this discussion regarding deployment strategy - Could be a good one to deploy containerized to start, even if the containers are just running on the instance?

tarekskr commented 6 years ago

dapp now deployed and live on http://ethavatar.com

mbeacom commented 6 years ago

😂

owocki commented 6 years ago

@tarekskr mind writing a quick readme and putting it up on https://github.com/gitcoinco/ethavatar ?

things id like to see

deployed contract addresses w. links to etherscan
web build / deploy instructions
smart contract build / deploy instructions
code examples: how can one who wants to leverage ethavatar POST or GET an avatar image by passing in a eth address?

tarekskr commented 6 years ago

mind writing a quick readme

Sure!

how can one who wants to leverage ethavatar POST or GET an avatar image by passing in a eth address?

There is currently no POST/GET API implemented. My main reasoning is that I don't wan't people to depend on a centralized server (in this case http://ethavatar.com) to fetch the avatar, but rather use the smart contract & IPFS directly. One cool thing we could do however is publish the eth-avatar-image to npm as an independent react component that people could plug into their React apps.

owocki commented 6 years ago

There is currently no POST/GET API implemented.

Sorry.. I was using POST/GET as shorthand for the creation of a new avatar, and the 'get' of the avatar image for an existing avatar respectively.. not suggesting that the literal HTTP verbs be implemented.

I was looking for javascript code samples of how one would get the avatar urls back, because those will go on the landing page for this application (in addition to the README.md). I will likely follow on with web3py examples from there.

and deploy to rinkeby, and then, once tested, to mainnet

on, and one more thing .. mind deploying to mainnet?

tarekskr commented 6 years ago

Just deployed to mainnet! 🎉 https://etherscan.io/address/0x4FbF2f1613Cc86314b22AE10Ae95D19cF2990824

Will get to README.md later today.

owocki commented 6 years ago

thx :)

tarekskr commented 6 years ago

Just commited README.md. Wording probably needs some refinement as I blabbered a lot about Eth Avatar's use cases :)

owocki commented 6 years ago

looks great!

owocki commented 6 years ago

@tarekskr want to submit work at https://gitcoin.co/funding/details?url=https://github.com/gitcoinco/skunkworks/issues/58 so we can pay you out?

tarekskr commented 6 years ago

@owocki will do, thank you so much!

It was a real pleasure working on Eth Avatar, really can't wait to see it adopted! :)

gitcoinbot commented 6 years ago

The funding of 0.23 ETH (159.99 USD @ $695.6/ETH) attached to this issue has been approved & issued to @tarekskr.

Learn more at on the gitcoin issue page
Questions? Get help on the Gitcoin Slack
$5363.46 more Funded OSS Work Available at: https://gitcoin.co/explorer

gitcoinco / skunkworks

Eth avatar - gravatar for ethereum addresses #58

what

An important part of the Ethereum Ecosystem

what, technically

design

bounty