Hey devs, released my first gen art project Social Graphs. A mint in a frame that uses the minter’s Farcaster social activity to generate a piece based on their casts, engagement, and followers. A lot of work went into this, so I wanted to share how I approached it from a technical PoV

Hey devs, released my first gen art project Social Graphs. A mint in a frame that uses the minter’s Farcaster social activity to generate a piece based on their casts, engagement, and followers. A lot of work went into this, so I wanted to share how I approached it from a technical PoV https://socialgraphs.vercel.app

The frame is built in frames.js which I love as someone who struggles with frontend stuff. On the first button press, I start to fetch the user’s social activity using @neynar APIs. Because this may take longer than the 5 second timeout, I return an in progress view immediately.

best farcaster developers build on neynar.com | /neynar

Smart contract dev & security eng @ rtfkt.com

Creations at /maxi - @punkbot, @farfinder, Social Graphs, Capture the Hat, Reply Guy, Bag Bias, Fact Checker, ++

The user can check if the fetch is done periodically by clicking on a button to get an update. A lambda function is running to fetch the stats, store them in DynamoDB, and also update a separate table to serve as a cache. The cache lets me know what was already fetched to ensure duplicate requests aren’t done.

Once complete, the user can proceed to generate their art piece. This calls a separate Vercel serverless function running p5js on a node server to headlessly generate the art piece. This takes the user’s stats to generate a piece specific to their identity. Once done, it’s uploaded to S3 and returned to the frame.

The user can view the piece, and then choose to reroll. The reroll button essentially redoes the last step except for fetching the cached stats. Once the user selects the piece they want, they can choose to mint. Using their verified addresses and Farcaster wallet, I ask them which wallet they wish to use.

Once selected, another lambda function is called which mints the piece for the user. There’s queues & retries built in due to the serverless nature meaning nonce reuse becomes an issue. This was a tradeoff I was okay with as I wanted everything to be serverless and auto-scalable in case of high volume for a free mint

The tokenId is the FID which is a nice built-in way to ensure someone can’t mint twice instead of having to store that separately. You may wonder why I’m paying the gas instead of mint with warps. Minting by tokenId isn’t a common pattern, which I needed for this mint, and Reservoir can’t detect this mint yet

Minting by tokenId was required in order to have the context on which fid minted which token to set metadata correctly. But that’s basically it, it was a lot of fun to build and a lot more work than I initially anticipated when putting the idea together. Hope this behind the scenes was helpful!