Once we've launched, let's discuss contributor rewards as @eknobl mentioned here: https://discord.com/channels/883478451850473483/884980325653049367/944617218090606653

Would be great to maintain a codebase written on TypeScript and leverage on Hardhat's Typechain where it auto-generates TypeScript typings for the smart contracts that gets compiled and deployed locally. Also TypeScript would be awesome too when we're creating those tests in Chai.

If you guys would approve then I'll take a look and find a way to migrate everything into TypeScript.

Right now it's relying on the latest deployment getting the domain https://pixel-avatars-api-rasmus-developdao.vercel.app

This also means that if production was deployed last, the staging website displays inventory from live genesis contract.

It's only a problem on staging, as production is always tagged with --prod during deploy

It would be helpful for users to know that this is an open source project that they can also contribute to.

Here's my thoughts on how to deploy smart contract for the pixel avatars. Basically we want to create a way for existing DevDao token holders to claim a token on pixel avatar contract. All the image metadata can be added at mint time or after mint.
A good discussion about this topic can be found here:
Openzepplin discussion forum

Stack exchange

Let's look at other projects that have implement this kind of requirement. Which is If msg.sender is a token holder in original contract , let them mint a token form the new contract.

Gan Apes is a project that is mintable by Bloot token holders( bloot is similar to loot and launched by making small changes to the Loot contract, similar to Developer dao project. )

Opensea for Gan Apes: https://opensea.io/collection/gan-apes-nft
Etherscan for Gan Apes: https://etherscan.io/address/0xbae6f981dc151cfc633212f06a9c5b4e37920454#code

Gan Ape images are stored in IPFS and this metadata location can be queried by reading the contract's tokenURI method

This is the metadata for token 1003 when I view the IPFS string returned from the step avobe
https://bafybeicnsgu6unnctx4hczjv7jgo6cohqckh33kcy4l5bnsxtyzak6btoy.ipfs.dweb.link/1003

{
    "name": "GAPE #1003",
    "image": "ipfs://QmcLrdSvoiTtFhABitH59NoSBRsFAUbibVLjCydspcZj8T/1003.jpg"
}

This metadata has a image location on ipfs and when I navigate to that image uri ( via a browser like Brave which supports ipfs) I get the image. That image is used by Opensea and other NFT platforms.

So testing plan for our project can be something like:

1. find the testnet version of developer dao contract.

   • https://rinkeby.etherscan.io/address/0x25ed58c027921e14d86380ea2646e3a1b5c55a8b#code

2. Create a Dummy metadata file for a few tokens based on this tutorial. Basically we can create a metadata server by a file hosted on github repo:

• https://forum.openzeppelin.com/t/how-to-provide-metadata-for-erc721/4057

3. Deploy another contract based on the GAN Ape contract above and allow list the DevDao Rinkeby contract so only Dev Dao token holders on Riknkeby can mint pixel tokens. Set the tokenURI to the uri we create in step 2.

Thoughts?

Hope no one minds but I went ahead and set up the repo and open a PR ( #1 ) with a basic hardhat project.

Like me, I think there are quite a few people new to Solidity so thought it would be good to collaborate on how the to get a good dev / test environment set up from scratch in here so it's documented and an opportunity for everyone to learn.

My understanding is the next steps for are to get a good localnetwork and testnet configured but have seen a few different configurations (and think we might need an account at infura) so before pushing ahead wanted to get others input and feedback on how we should set this up.

Should follow the system preferences.

Before adding the dark mode itself it would make sense to first upgrade to Tailwind 3

We can update various metadata directly in OpenSea for https://opensea.io/collection/pixel-devs

• Logo image - This image will also be used for navigation. 350 x 350 recommended.
• Featured image - This image will be used for featuring your collection on the homepage, category pages, or other promotional areas of OpenSea. 600 x 400 recommended.
• Banner image - This image will appear at the top of your collection page. Avoid including too much text in this banner image, as the dimensions change on different devices. 1400 x 400 recommended.
• Description Markdown syntax is supported. 10 of 1000 characters used.
• Category - Adding a category will help make your item discoverable on OpenSea.

Speaking of wearables, makes me think that we'll need a site to house a person's PixelDev collection with all their outfits.

The Developer DAO Dream House ❤️

IPFS

• For prod metadata "description" ("Pixel Avatars are a collection..."), change to "Pixel Devs is a collection..."

Contract

• Update token name in contract to be "Pixel Devs" (@briangershon) Not able to change unless we choose to redeploy production.
• Fix "Pixel Avatars" directly in OpenSea metadata (@briangershon)

OpenSEA

• See #98

cc: @rasmuscnielsen @etherinsight @goldzulu

Someone in the Discord server reported that when they try to save their pixel avatar, they are not being able to save the entire avatar. Instead, they are being able to save only one part of the avatar at once. (eg. pants) Link to the message: https://discord.com/channels/883478451850473483/883482557809852416/899139138396258374

This has probably got to do with the fact that we are just placing PNGs for different parts of the avatar on top of each other. But we should definitely add a download functionality.

to be consistently using ethers.js for front end since already using it on the hardhat side

Do we need to put on Google analytics before launch?

I shared the link to Pixel Avatars in Discord and it resulted in just a boring old link! If we add meta tags we can attach an image and a description to make it more likely others will check out the project! We implemented them for developerdao.com and you can see the difference here:

https://metatags.io/ makes this really easy!

On the subject of preparing for future games etc. I have been pondering if we could do anything to future-proof our smart contract further.
While it can be difficult to foresee every possible future idea I have thought of an example use-case of offering special mints where people choose their own traits (outside of the 8000 reserved combinations) - potentially branding it as another kind of token that doesn't hold the D_D necklace but some other visual identifier.

Basically I think it would offer a lot of flexibility if we could adjust these parameters:

Authorization / eligibility
Different mints requires different pre-requisites. This is already achieved today by server signature as we can change the server code as we please.

Mint price
Different kinds of mints / variations could trigger different prices. This would be easily achievable by tweaking the current contract/server integration. Basically I propose we continue to enforce a minimum mint-price in the contract which should be the cost of minting the current DAO member NFT's.
However additionally we could allow the server to also enforce a "tipping fee" or similar which would be useful in case we wanted to offer other variations that incurs extra fees.

Trait combinations
It would be very powerful if we could also add more variations / meta data beyond the existing traits and their 8000 existing combinations.
I believe this should already be possible after launching the contract but honestly I'm still not completely familiar with the full palette of the ERC 721 contract such as meta data and uploading assets to IPFS.
If we were ever to allow people to make their own combinations I suppose it would have to be the server that generated & uploaded the image to IPFS + issues that token with proper meta data to the contract. I'm not sure whether this is a bad idea or even possible, but thought I'd share it and get a conversation going. As long as the current contract would allow such an extension we don't have to work on this right now.

The alternative to all of the above of course is to just create new contracts every time we hit a roadblock with the current one. While that's possible too it might make it more cumbersome to create an ecosystem of games etc. around the avatars if they are all spread across different contracts.

With the flexibility the server gives us I thought it might give us an advantage in terms of adding new functionality, and perhaps allow us to have everything hosted on the same contract by using the server to incorporate business logic for the minting part.

Interested to hear your thoughts!

@eknobl Great work on the assets!

Just noticed the US flag is currently being used for Jackson, Omaha & Gold Coast.

Maybe we could let the Aussies have the Gold Coast one and make it an Australian flag? 🌞 🇦🇺

https://en.wikipedia.org/wiki/Gold_Coast,_Queensland

Suggestion

After user connects with wallet, most users will probably only have 1 or 2 tokens.

I'd suggest a small change: Let's auto-select the first token.

This will

• take out one manual step of having to find/select your token you want to claim - makes that a bit easier and more obvious
• will automatically show the preview of the user's token (instead of the default 1).
• Claim Avatar button will also be visible and be ready to click on

So the new version would show the token pre-selected like this:

Without the default token selected, the current "token picking process" seems slightly hidden:

Related

• This relates to #66 too and what we should display if token is already minted.

• A nice to have could be to show tokens in more of a preview format -- list of boxes (maybe even a preview of the token if already minted) versus a drop-down, but that's a bigger project.

@goldzulu was mentioning we need a derivatives project website

• with links to mint page
• a roadmap

like any other nft projects

and as part polygon sponsorship page

@goldzulu has been working on a bunch of animation -- hype videos for twitter and also a tutorial for how to mint for new users!

Since we are planning to hardcode the treasury address for UkraineDAO on the smart contract, then this could be tricky to test. But a solution to that is to use mocking then we can test things out and make the assertions we desire.

• Test prod contract ownership transfer
• Transfer contract ownership to DAO Multisig
• Ask Erik to test withdraw

Ie by adding "Already minted - {TOKEN ID}" to the dropdown of personal tokens.

devastated that Ruby isn't in the language list!

Is there anything I can do to help make that happen?

An Automated Vercel deployment would be great.

Probably need to chat with the website team and/or have our own pixel avatar Vercel account

Bug

If user saves link to their NFT preview and then revisits that URL at a later time, users will see the wrong NFT.

The link contains the ?developerId query param but site doesn't show that NFT when visiting link directly.

Repro

To reproduce, click on any example link below. They all show same NFT (default Developer ID 1).

https://pixel-avatars.developerdao.com/?developerId=123
https://pixel-avatars.developerdao.com/?developerId=456
https://pixel-avatars.developerdao.com/?developerId=999

I had discovered this by adding a link to my own NFT and when I later visited that link, realized the image didn't match the data in https://raw.githubusercontent.com/Developer-DAO/pixel-avatars/main/web-previewer/data/developers.js.

Workaround

User can see their NFT if they manually select it in the UI.

We should use this bot to better keep track of contributors: https://allcontributors.org/

We are already using this bot in our website repo & it has worked well for us.

Feature requests

• Support query params. Eg. www.pixel-avatars.developerdao.com/?id=5350 should directly display the avatar for the token with ID=5350. The DAO's main website serves as the perfect example - https://www.developerdao.com/?id=5350.
• Sync ID input with the URL in the addressbar. Eg. if you type in a token ID at www.developerdao.com, you will notice that the URL in the addressbar syncs with your input. This lets people easily share a link to their avatars.

As we're getting more people involved it'd be great to have some ESlint / TSlint / Prettier setup.

Bonus if run automatically with Github Actions on PR commits 🚀

Hey @rasmuscnielsen I wonder if "FAQ" link is too subtle in the bottom corner? What do you think about a notice toward the top of the page? Since the minting UI always fills the full window as window size changes, I didn't notice there's a FAQ below the fold.

Some ideas:

• if at the top it could be titled something like "Learn more about this project"
• or "Click here for FAQs about this project"?

A successful mint is cause for celebration - perhaps some champagne popping and confetti 🎉 🎉 🎉

Perhaps related, perhaps not.. But when a NFT is successfully claimed and you're authenticated as the owner, we should have some download + share buttons that easily lets you share on ie twitter

Convert included contracts into import dependencies.
as per kevincharm (discord)

• install dependencies (openzeppelin etc) with npm and import them.
  -> benefits - it will be more easily readable, and hardhat can output 1 file for etherscan verification.

Currently all environment variables on Vercel can be inspected by anyone with access to our Vercel account. This is not ideal, as the server private key should be kept rather secret.

An alternative is to setup a Github Action that deploys a cloud function using the Vercel CLI or REST API.

• Private key is generated once and kept as Github Action secret SERVER_PRIVATE_KEY
• On push to main it deploys a fresh serverless function to Vercel and links it to the correct domain

To do for @carlomigueldy (me)

Details are also on todo for this ticket

We had brainstormed on our meeting last week that we wanted to have an option for public without dao tokens to mint Pixel Avatars. We will charge a small fee ( to be decided ) for the public mint and allow a certain amount(TBD) of public mints.

Pixel Avatars will be generated form metadata of Developer Dao token. For public mints, we can randomize the metadata and create a headless avatar that doesn't depend on the Dao token.

To decide:

• How many public mints to allow?
• Should we limit public mints per address? For example only let one address publicly mint one avatar. This will stop someone buying all public mints since we plan to keep the cost low.
• What price to charge for public mint
• How to market the public mint option

Todo:

• test out the contract to ensure the collected funds can only be withdraw by the allow listed wallet or the contract deployer address. We will use the dao address to deploy contract.

#23 added the foundation for the smart contract's source code. Would be a good idea to have some tests in place since we probably will iterate on the contract.

• Verify contract

For DAO members to mint their token, then need MATIC! And there are many steps involved and added expense.

We need to write an article that provides the best/cheapest/least-friction way to obtain Polygon MATIC.

One idea is using https://www.kraken.com/en-us/

Why?

Lots of publicity from @goldzulu's twitter post (and amplified with Nader's repost) show a need for a FAQ page.

What?

Idea is to add a static FAQ page to Pixel Devs, with an obvious link at the top of the home page.

Which FAQs?

Marc just added probably the most important one:

"Heads up that we may need to get more explicit with “pixel devs != genesis nft/membership”. Not sure exactly where and how to say it, but looks like we should address that. The timing of this launch coincides with our messaging about the dao opening back up unfortunately" Thread: https://discord.com/channels/883478451850473483/884980325653049367/945140811408998410

You can view replies from Twitter thread with questions being asked: https://twitter.com/developer_dao/status/1495547491881820162

Also notes from @goldzulu:

I think we can do anything quick would be good. then we think of long term "website"
with roadmaps etc
i think simple
mint price
url
questions
and what are these
what is Dev4Rev

Is

I bookmarked some pages from Developer DAO and noticed, that the favicon don't match:

Should

In my opinion, solving this issue would benefit a continuous DAO branding. The favicon should be round as our base logo.