Why?

By: Deca

Date: 9th September 2025

The past two weekends I built two Base Mini Apps at the Aleph Hack (Aug 29-31, 2025) and ETHWarsaw (Sep 5-7, 2025) respectively.

Upon Evan and Clemens’ request, I made this mini report, which distills the actual developer experience into a clear setup flow with caveats, tips, and dev tools.

Shoutout to 🍋Limone , Caso and Bianc8 who gave me advice along the way.

Follow these three steps in order to build and test your Mini App effectively.

📚 Step 1: Choose your SDKs wisely

You’ll only need two libraries:

• One for Mini App logic

• One for wallet connection
  

Use one of these combos:

1. farcaster/miniapp-sdk + coinbase/wallet-sdk ← works best right now

2. coinbase/onchainkit + coinbase/wallet-sdk

🚫 Avoid farcaster/frame-sdk - it’s deprecated and will cause issues.

🚫Don’t use BOTH farcaster/miniapp-sdk AND coinbase/onchainkit - pick one of the two.

Once you've picked, move on to Step 2: manifest setup.

Docs:

• https://miniapps.farcaster.xyz/docs/getting-started OR https://docs.base.org/onchainkit/getting-started

• https://docs.cdp.coinbase.com/coinbase-wallet/coinbase-wallet-sdk/install

🧾 Step 2: Fill out the Farcaster Manifest

Use the official manifest builder:
https://farcaster.xyz/~/developers/mini-apps/manifest?domain=yourdomain.com

Hint 1: You’ll need to generate and include five images at exact dimensions:

• icon.png: 512×512 px

• splash.png: 400×400 px

• hero.png: 1200×630 px

• screenshot1.png: 1200×800 px

• screenshot2.png: 1200×800 px

If using Next.js, place them in your /public folder.

You can use Canva to easily create documents of the correct size.

Hint 2: To generate your manifest, do not do it via the CLI!

npx create-onchain --manifest

Instead, to get your farcaster header, payload and signature, do it directly from the Farcaster app on your phone:

1. Open settings

2. Open advanced tab > enable developer mode

3. On developer tools > domains, enter your domain and generate manifest

4. Copy and paste the values of header, payload, and signature you have in the clipboard in the related env variables

✅ Once all fields are green in the manifest tool, you're ready to build out your Mini App’s functionality.

🧪 Step 3: Testing and Debugging - What Works and What Doesn’t

By default, simply opening your app at localhost:3000 and using browser devtools is not sufficient to test Farcaster-specific behavior.

Here’s why:

• The SDK provides a context object (sdk.context) populated only when the Mini App is rendered within a Farcaster client - like Base App, Farcaster App, or the Farcaster manifest preview tool.

• You can test your own user context this way (e.g. sdk.context.user) via the preview site.

• But if your logic depends on other context, like the author of the cast (sdk.context.location.cast.author), the preview tool won’t work - it doesn’t simulate the full cast environment.
  

This means that to test all context fields fully, you must push your app to production, post a cast linking to it, and open it from Base App.

But:

• Pushing to prod takes time - typically 1-5 minutes per change (depends on host like Vercel, your git branches setup, whether you test the build locally, etc.)

• You can’t access browser logs from Base App - debugging becomes hard.

🧰 Two Workable Debugging Solutions

Option 1: Use a tunneling service (e.g. ngrok)

• Lets you test locally using a public URL

• Works with the Farcaster manifest preview site

• Preserves full access to browser logs (e.g. console.log)

  Setup:

  • Terminal 1: npm run dev

  • Terminal 2: npm run ngrok (set up a script for this in your package.json file)

  • Paste the generated URL (e.g. random-id.ngrok.io) into the manifest preview tool (without https://)
    

Pros:

• Fast feedback loop

• Easy access to logs

Cons:

• Can't access full cast context (e.g. sdk.context.location.cast.author)

• You might run into extra issues if your app’s logic changes based on domain (e.g. different auth providers per subdomain)

• Tunnels may need to be reset often...

  • Clear cookies, browser cache, and app state

  • Restart both servers (npm run dev AND npm run ngrok)
    
    

🔎 This setup is useful when you're building more complex flows.

Option 2: Use an in-app DebugPanel component

This is what I used:

1. Create a component that logs and displays relevant data visually inside the Mini App
   if (debugMode) {
  return <DebugPanel data={sdk.context} logs={clientLogs} />;
}

2. Serve the app at yourdomain.com/?debug=true

3. Post a cast containing this URL

4. Open the cast in Base App → DebugPanel is visible

5. Copy-paste DebugPanel logs from your phone to your laptop (possibly feed them to an LLM)
   

Real example I built with DebugPanel:
🔗 https://base.app/post/0x23f1a925729e1f3a2ae58b2385b8e72764925121

Pros:

• Full access to all real context fields (sdk.context.location.cast.author, etc.)

• No compromise - this is your final deployed Mini App

Cons:

• Slow feedback loop (prod push every change)

• You must manually transfer logs to your dev machine

If this was useful, please Recast this guide!
✌Deca

I am writing because I think you'd appreciate knowing about the other camp in crypto, the one you do not hear about, the one with vision, values and hope. This second camp is not loud like the traders, it's not shortsighted or superficial.

My thesis is as follows: I’m driven by the belief that blockchain is the one paradigm-shifting technology which, in a world where macro trends flirt with dystopian risk (AI, climate, biotech, geopolitical divide...), can rein in all the rest. Its approach to “proof, not trust” can fundamentally change the game-thoeretic rules of any system through financial incentive alignment.

Let me explain in a way nobody has ever explained it to you. The maths (cryptography) enables a system where:

1. All the rules of the system are written in code - i.e. no single entity has control of the system

2. The system has money embedded in the code - this enables financial incentive alignment - i.e. behaviours that are beneficial for the system are financially rewarded and behaviours that are harmful get penalised

3. The code/rules of the system are visible to everyone, but cannot possibly be changed unless by democratic consent

4. Participants of the system no longer have to trust counterparts, brands or institutions when interacting. All they have to trust is their counterparts' self-interest - if they behave in a nefarious way, the fine is larger than their benefit.

If you are my intended audience, you'll have perceived the increasing global chaos over the past few years and your logical response to the perceived chaos will be to try and leave a net-useful impact. I think a lot of people see a similar picture of the world but that instead leads them to nihilism. Many crypto traders are like this.

Blockchain / crypto / web3 routinely makes headlines when the price is high and goes silent when the price is low. The traders and speculators are the ones luring unsuspecting normies in with promises of instant gains, but really just looking for exit liquidity. Furthermore, being a technology in its infancy that embeds money in code, it's been adopted from the fringes of society.

Hence, news outlets see wild predatory trading behaviour, uncensorable systems, North Korean hacks, dark web payments, and perpetuate the story that this is a dangerous and pointless technology built to defraud people. It is not. This technology is our best shot (as far as I have seen) to restabilise this increasingly unhinged world.

If I have sparked some interest, reach out, comment my post on X.

WAGMI

Deca

Note from Author

I am starting the research phase for this paper today, on December 1st 2024. I am applying for the Ethereum Foundation’s 2025 Software Engineering Internship, with a specific interest in improving Ethereum’s UX. Therefore, writing this paper will be an effective way to get an in-depth understanding of AA. I am already familiar with the concepts of ERC4337, including bundlers and entry-point contracts, paymasters and transaction sponsoring…

I will now go deeper, by reading EIPs 86, 101, 1613, 2771, 2938, 3074, 4337, 7701, 7702, RIP 7560 and other related sources.

“The goal with Account Abstraction has always been to solve the cross-chain UX problem” - Yoav Weiss

Account Abstraction (AA) involves three parts of a transaction flow:

1. Authorization Logic (how the transaction is approved)

2. Execution Logic (what the transaction does)

3. Fee Payment (how the validator is paid)

Following years of exploration with the EIPs described in this paper, EIP-4337 condenses the key goal of Account Abstraction into: allowing users to not have EOAs, and instead “use smart contract wallets containing arbitrary verification logic”. This is a technical, practical, operational view of the goal.

On the other hand, the normative end goal has always been to improve UX. Specifically, the three improvements listed in the Pros and Cons tables in this paper are:

• Signing UX

• Wallet Recovery

• Gas Payments

This can be further abstracted into the real final goals:

• Improving onboarding and usage friction by reducing the number of steps and concepts users need to understand when using dApps.

• Giving users peace of mind regarding fears of having their seed phrase lost or stolen.
  

EIP-4337 presented a clever way to address the UX goals of AA without the coordination effort and additional work required by infrastructure-layer changes. It can be seen as a workaround based on the constraint of avoiding consensus-layer changes.

Following EIP-4337, newer proposals push Native AA to the forefront. Native AA refers to embedding functionality into the infrastructure-layer, as opposed to aiming to address AA. RIP-7560 adopts many of the concepts from ERC-4337, but instead of relying on higher-layer infrastructure, it combines them with concepts from EIP-2938, thereby requiring consensus-layer protocol changes.

While this is the current state of collective brainstorming and development, to fully understand the problem being faced, one must look at the full history of AA, which began in 2015 and has seen many proposals since.

Before delving into the evolution of AA ideas brought forth, we must understand what transactions are and the traditional flow of transactions on Ethereum.

A transaction is a write operation - i.e. an action that alters the onchain state. There are two types of transactions on Ethereum: Ether transfers (from EOA to EOA) or function calls (from EOA to Contract).

The diagram below illustrates the standard transaction flow on Ethereum.

This section presents a comprehensive picture of the evolution of Account Abstraction, describing each relevant improvement proposal in a chronological order.

Each improvement proposal will have a table of pros and cons within a structured set of relevant categories:

• Signing UX

• Wallet recovery

• Gas payments

• Security

• Dev overhead

• Future proofing

• Validator incentives

• Implementation

Furthermore, similar to the transaction flow diagram above, each improvement proposal below will have a similar illustration depicting the difference under each approach. The colours yellow and blue represent proposals requiring, and not requiring, infrastructure-layer changes respectively.

https://eips.ethereum.org/EIPS/eip-101

EIP-101 redefines EOAs to no longer store Ether, i.e. only store code and storage. Transactions are simplified to include only the recipient, gas limit, data, and optional code for contract creation, eliminating fields like msg.value.

Ether is instead managed by a unique premined contract at address 0, which handles transfers and balances for all accounts.

https://eips.ethereum.org/EIPS/eip-86

EIP-86 introduces the idea of abstracting transaction origin (who sent it) and signature validation (how it’s authorized), or in other words, “abstracting account security”

It also introduces the CREATE2 opcode, for deterministic contract creation. Although EIP-86 was never implemented, CREATE2 was later re-proposed and finalized as EIP-1014 and introduced in the Constantinople upgrade (February 2019).

*Ethereum was still running Proof of Work at the time of this proposal, hence the miners

https://eips.ethereum.org/EIPS/eip-1613

EIP-1613 proposes the Gas Stations Network (GSN), a decentralised offchain network of relayers, which enables users to make “collect calls”, i.e. transactions paid for by the recipient.

The relayers pay the gas fee upfront and then get reimbursed by the receiver contract (can’t be an EOA). A singleton contract RelayHub manages relayers, ensuring their authorization and reputation, and handles reimbursements.

https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020

This proposed scheme builds on the concept of account abstraction by introducing a two-step process for transaction validation: lightweight verification and execution. This approach allows for custom account logic while maintaining network efficiency and miner incentives.

It avoids creating a new account type, relying instead on a unique ENTRY_POINT contract to route transactions and manage gas payments. It does not require major protocol changes and focuses on making advanced features accessible without sacrificing backward compatibility.

Gas payment is handled by a ney PAYGAS opcode, which deducts gas fees dynamically during transaction execution, locks payment to miners, and ensures unused gas is refunded.

Several subsequent EIPs draw inspiration from this approach, adopting the concepts of the ENTRY_POINT contract and the PAYGAS opcode.

https://eips.ethereum.org/EIPS/eip-2771

N.B. ERCs are a subset of EIP. More specifically, ERCs are EIPs that define application level standards - in this case, an interface and behaviour for contracts to enable meta-transactions.

ERC-2771 introduces Forwarders as an onchain and offchain entity used to sponsor transactions. Users can send a free offchain meta-transaction to a dApp’s forwarder, which then sends the tx onchain to the recipient, including the sender’s address in the tx data.

This allows users to interact with decentralized applications (dApps) without holding Ether for gas fees. This approach simplifies user interactions and enhances accessibility without requiring changes to the Ethereum protocol.

https://eips.ethereum.org/EIPS/eip-2938

EIP-2938 proposes integrating account abstraction directly into the Ethereum protocol, allowing smart contracts to function as top-level accounts capable of initiating transactions and paying fees. Users can use these smart contracts, known as Smart Contract Wallets, in place of their EOAs.

Gas payments are handled by a new PAYGAS opcode, which deducts gas fees dynamically during transaction execution, locks payment to miners, and ensures unused gas is refunded.

This enables features like multisigs, social recovery, time locks, and quantum-resistant signing schemes, while maintaining miner incentives and network security.

https://eips.ethereum.org/EIPS/eip-3074

EIP-3074 introduces two new EVM opcodes, AUTH and AUTHCALL, enabling externally owned accounts (EOAs) to delegate transaction control to smart contracts called Invokers. This allows EOAs to execute complex operations and batch transactions without deploying individual smart contracts, enhancing functionality and user experience.

Invokers can batch multiple operations into a single transaction, sponsor gas fees, allowing users to interact without holding ETH. This reduces the technical and financial burden on users, as Invokers can handle batch transactions, gas sponsorship, conditional execution, atomic operations, cross-contract interactions…

https://eips.ethereum.org/EIPS/eip-4337

EIP-4337 is one of the strongest approach to date to introduce AA without many of the drawbacks. It does not require consensus-layer changes, instead introducing a higher-layer pseudo-transaction object called a UserOperation, which replaces the traditional transaction format.

Users no longer need an EOA. Instead, they manage a Smart Contract Wallet, through which they submit UserOperations to a separate mempool, distinct from regular Ethereum transactions. Any block builder can take on the role of a Bundler, a specialized aggregator that collects UserOperations and packages them into a single transaction.

The bundled transaction is sent to a singleton EntryPoint contract, which validates UserOperations, executes their logic, and manages gas payments. Gas fees can be sponsored by a Paymaster smart contract or paid directly by the user’s wallet contract, with both reimbursing the Bundler.

To mitigate the risk of malicious Paymasters causing DoS, a reputation system ensures only reliable actors are prioritized. “To prevent attackers from cheaply clogging the mempool, nodes in the P2P network need to check if an operation will pay a fee before they are willing to forward it.”

The official EntryPoint contract for EIP-4337 was deployed on the Ethereum mainnet on March 1, 2023, by a consortium of Ethereum developers and contributors, including members of the Ethereum Foundation and the broader AA community. GitHub repo:

https://github.com/eth-infinitism/account-abstraction

https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md

A Rollup Improvement Proposal (RIP) is a type of proposal that focuses on improving Ethereum’s rollup technologies, addressing changes that may impact both the execution and consensus layers. Unlike EIPs, which encompass a broader range of updates—including networking protocols and application-level standards—RIPs are specifically targeted at standardizing and documenting advancements in Layer 2 scaling solutions like rollups.

RIP-7560 integrates EIP-4337-like functionality into the protocol itself, rather than directly using EIP-4337’s application-layer implementations, which is why it is referred to as Native AA.

RIP-7560 makes several arguments for Native AA over EIP-4337:

• UserOperations require twice the gas overhead as basic transactions (42k vs 21k)

• crLists and other censorship resistance techniques address transactions but not UserOperations

• UserOperations rely on a separate mempool and a subset of block builders. They also rely on non-standard RPC methods like eth_sendRawTransactionConditional. This significantly smaller set of participating nodes and their reliance on different RPC methods decreases reliability.

• Tx.origin is no longer useful, since using it on a bundled transaction would return the meaningless address of the bundler.

Specifically, RIP-7560 proposes similar execution-layer changes as first introduced by EIP-2938, involving splitting the Ethereum transaction scope into multiple steps (validations, execution and post-transaction logic), thereby eliminating the need for EOAs entirely. It does so while attempting to maintain backward-compatibility with the year and a half of ecosystem adoption of EIP-4337 concepts, such as UserOperations, Bundlers and the Entry Point contract.

The new transaction type adopted is that first described by EIP-2718 (not described in this paper), called AA transaction. The transaction receipt object is also changed to accommodate AA concepts such as paymasters and the multiple phases of the transaction.

https://eips.ethereum.org/EIPS/eip-7701

EIP-7701 looks at RIP-7560 and proposes adopting the EVM Object Format (EOF) to distinguish between validation and execution code sections. The EOF, first defined in EIP-3540, is a structured framework for organizing smart contract bytecode, separating code, data, and metadata to improve modularity, validation, and execution efficiency within the EVM.

This approach introduces multiple entry points within smart contracts, each designated for specific roles such as sender validation, paymaster validation, and deployment. By embedding these roles into the contract's structure, EIP-7701 aims to enhance transaction validation efficiency and security, reducing reliance on external encoding schemes and improving compatibility with various account abstraction mechanisms.

https://eips.ethereum.org/EIPS/eip-7702

EIP-7702 gives EOAs some of the AA benefits: EOAs can use paymasters, i.e. pay gas with tokens or get gas sponsorship.

The proposal introduces a new transaction type, which includes temporary one-time code. This is executed with the transaction, giving EOA temporary smart contract functionality, like transaction batching and gas sponsorship.

While EIP-7701 assumes full adoption of smart contract wallets, which can be costly and complex, 

EIP-7702 allows EOAs to temporarily adopt AA features, bridging the gap for users and dApps not yet ready for full smart contract wallet adoption.

The evolution of Account Abstraction (AA) in Ethereum demonstrates an ongoing journey to enhance flexibility, security, and usability in account management. Early proposals like EIP-86 and EIP-2938 sought to integrate AA directly into the protocol by introducing new transaction types and modifying both the execution and consensus layers. While these proposals introduced powerful concepts like deterministic contract creation and native gas sponsorship, they were ultimately shelved due to the complexity and disruption of the required infrastructure-layer changes.

In response to these challenges, EIP-4337 took a different approach, implementing AA at the application layer. By using a higher-layer object, UserOperation, processed via an EntryPoint contract, it enabled features like custom verification logic, multisigs, gasless transactions, and social recovery—all without changing Ethereum’s core infrastructure. This proposal was successfully deployed as a set of smart contracts, marking a practical and incremental step toward realizing account abstraction.

However, the pursuit of deeper integration didn’t stop with EIP-4337. Recent proposals like EIP-7701 and EIP-7702, as well as Native AA (RIP-7560), revisit the idea of making infrastructure-layer changes. These proposals aim to integrate AA into the protocol itself, addressing execution and consensus layers to reduce gas overhead, improve security, and make features like paymasters and multi-phase transactions more efficient. For example, the Pectra upgrade is set to implement EIP-7702, introducing temporary code execution for EOAs to access AA-like features without deploying permanent smart contracts.

This progression highlights Ethereum’s adaptive approach to account abstraction: moving from bold infrastructure-layer proposals to pragmatic application-layer solutions and now back to refining protocol-layer designs. These efforts aim to balance innovation with Ethereum’s stability and scalability goals.

• at ethglobal hackathon i rebuilt a scheduler from the ground-up with 2 frens, with many features, but not fully working

• now i'm gradually adding thos features to qcast by debugging carefully as i go

• i recorded a new video for a new launch

• see update #7 (#8 was buggy, i contacted paragraph to get it back)

_technical_

• last week at ethglobal we built a database with postgresql and prisma for several features. i'm implementing this into qcast, but i want to understand things well as i go along, so i've been studying several concepts (e.g. connection pools, db hosting, cloud providers like supabase and neon).

• here i explain some design choices i was able to make with the knowledge from already having done it last weekend.

_farza notes_

go through itertive loop 10 times, with 10 different cohorts (your ppl who like what you're doing). remember update #7 ? ...create, launch, measure, learn... repeat with new cohorts over time.

to find a cohort, first find a good channel and content type that's right for you rn.

• find your channel: e.g. a specific subreddit, discord groups of cs departments of unis, public square in front of public library at specific time...

• and find your content type: e.g. videos of showing behind the scenes of your software with commentary, learn a song in 30 seconds and perform on the spot, skits about gen z vs boomers, videos of going in pubic and asking ppl for feedback...

it's ok to try several channels and content types at first but find you niche and stick to it. plan it out...

however, focus on developing your product as a main concern - nobody wants a shit sandwich on a silver plate with cherry on top.

• Hacking at ETHGlobal Brussels this weekend: Hoot

• Decided to start over 🤯 qcast with different stack, below notes written during hack, see update #7

• cron-job (or other option), & use filecoin for media storage instead of pinata, & lighthouse to pin to ipfs and a dynamic login & auth to pay for service

___Bounties___

👋 Dynamic Best SocialFi Project ⸺ $2,000

• This prize goes to the project that utilizes Dynamic to create a unique social experience with financial incentives. This could involve users interacting over a game, social network or other areas of consumer crypto.

• Qualification Requirements - The project must be available via a deployment link The project must use Dynamic beyond basic signup/login The project must fall into the SocialFi category

🏆 Filecoin Prize ⸺ $11,000

• 🥇1st place $5,000 🥈 2nd place $3,500 🥉 3rd place $2,500

• Awarded to the top 3 projects overall submitting to any of the Filecoin tracks - Data Apps, AI Tools or Privacy Tools.

• Qualification Requirements - Submit a video demo to showcase and walk through your project. - Open-source your project on Github.

💽 Filecoin Data Apps ⸺ $3,000

• Best project built on Filecoin storage services (e.g. lighthouse or web3.storage) or using FVM (Filecoin Solidity Library) directly to make data management flow smoothly. Examples: industry specific storage apps xxx.storage, perpetual storage, data aggregators, data caching nodes, truestless notaries & retrieval oracles.

• Qualification Requirements - Store & use application data programmably using Filecoin storage services (e.g. lighthouse or web3.storage). - Deploy your project on the Filecoin Calibration testnet, including any associated smart contracts if applicable.

___User Flow___

• user login dynamic.xyz (social or wallet)

• user connect warpcast with neynar (get user.signer_uuid)

• user inputs text

• user uploads image (optional)

• ADDITIONAL FEATURE: user uploads frame url (optional)

• user selects date & time

...client-side sends post request with all this info to server-side endpoint

• cast is added to list of scheduled casts

• user can remove or update the scheduled cast

...when it's time for the cast, it's triggered by cron-job and published

• cast is removed from list of scheduled casts

___Tech Stack___

• nextjs, tailwind css

• dynamic.xyz connect wallet or social login

• dynamic.xyz to connect farcaster account

• lighthouse & filecoin to store images & videos

• authjs to authenticate users

• upstash/qstash or trigger.dev to schedule cron jobs

• neynar to publish casts

___Database (first approach)___

• users, contains:

  • id

  • dynamic_id

• signer_uuids, contains:

  • id

  • user

  • signer_uuid

• casts, contains:

  • cast id

  • cast text

  • ipfs url of image

  • date & time

  • bool published or not

  • ? frame url ?

___Challenges___

• when pinning the image file to ipfs with lighthouse, we were following this section of the docs, but it was intended for pinning from client-side. we were trying to use a buffer without documentation on it. we unblocked the issue once we realised another section of the docs about it.

• the new authjs library, it was challenging to manage the token.

___Analytics___

Retreive casts based on filters (docs):

• likes_count

• recasts_count

• timestamp: "2024-07-13T18:47:04.000Z"

• name (channel)

Analytics will be bar-charts based on castScore = likes_count + (recasts_count * 3)

• Graph 1: x-axis is day of the week, y-axis is avg castScore

• Graph 2: x-axis is 3h time intervals, y-axis is avg castScore

• Graph 3: x-axis is channel, y-axis is avg castScore

to do:

• fid should come from "author": {"fid" ...not "parent_author": {"fid"

• the unique identifier for a cast should be "casts": [{"hash"

• i'm building a scheduler for casts (posts) on farcaster, join the waitlist

• working on allowing users to upload their images (using Pinata & IPFS)

• see update #6

_technical_

• users generally don't have a url of the image they want to post, so i need to offer an easy way for them to upload an image and then have it hosted securely.

• i want to avoid storing the images in my own server, cause if it stops running, all images in users' casts won't be available.

• so i'm building in the ability for a user to upload an image to ipfs through pinata. the flow looks like this: user uploads the image, when user clicks on cast button, client-side sends image file to server-side (if present) with a post request. server side generates pinata jwt key, then pins image to ipfs, gets the url and includes it in the cast intent as an embed.

• ...this approach is expensive, as it would cost $20 p/m above 500 uploads (on top of the $9 p/m of neynar) and also it's tricky to implement. i found another solution (below), but i want to get it done this way first to learn and have working code for this approach.

• the alternative is imagekit, not web3 but has a large free tier and is easier to deal with, even direct from client-side i think.

• in conclusion, this week i want to get the pinata + ipfs approach working. starting next week (i also have ethglobal brussels this weekend) i'll work on the imagekit approach.

_farza notes_

farza says: iterate the build-in-the-open loop:

• ...create, launch, measure, learn...

so i reached out to my 7 early waitlist users with 3 questions:

what not to do when asking for feedback:

• don't defend

• don't make changes based on feedback without understanding why

• don't ask 'would you use this / check it out?'

"thanks for being amongst the first ppl to join the qcast waitlist!

heyoo, i'm @deca12x core member of urbe.build

can i please ❤ get an idea of

• do you always cast from warpcast? (what else?)

• do you use any tools to plan future casts?

• what is your least favourite thing about warpcast?

the best way to support qcast rn is to cast a referral frame 👇 warpcast.com/~/compose?te..."

https://www.beearly.club

Beearly - qcast

Beearly - Launch your waiting list on Farcaster.

• i'm building a scheduler for casts (posts) on farcaster

• users can now upload image

• ppl can now join waitlist

• see update #5 & update #4

_notes_

• been using a great guide by pinata for safe client-side uploads

a few hours later...

• ...ok update, i decided to leave the upload pic part for later, since i'm at ethcc7 in brussels rn and there's a lot going on.

• you can now cast your pic but you have to already have the url - i.e. have it hosted somewhere

Farcaster

deca on Warpcast

looking for a minimal easy way to schedule your casts for later? i'm building qcast, join the waitlist and i'll show you how i'm building it https://beearly.club/w/qcast

Farcaster

deca on Warpcast

urbe houz 🇧🇪 cast from script with pic https://scarlet-reasonable-mule-649.mypinata.cloud/ipfs/QmaZQqf2NULqMZnCrHBqoEoWSi7yrEHHTeH84JZEyKmUmi

• i'm building a scheduler for casts (posts) on farcaster

• to do: launch product with a beearly waitlist + work on cron job

_launch notes_

from week 3 lecture & lab

• first: this is not 'buildspace hw', it's my own thing, so don't mention buildspace, n&w, s5 or farza too much.

• how to know who your ppl are:

  • trust (e.g. follow, newsletter sign-up)

  • usage

  • money

• ...so you need a call to action (cta) so ppl know what to do to show you they care and want to participate in your projects.

• to build in public, you must "launch" your product over and over to get other people to care. if it's a video, ideally 40 seconds. in a launch, you need:

  • hook / heading / one liner explaining what you're working on

  • description... don't show a bunch of features, focus on the thing that makes it cool and why ppl would wanna be part of it.

  • cta... what do you want ppl to do next to show that they care

  what does farza look for:

  • what is it?

  • what’s in it for me?

  • is it legit?

  • how do i get it?

_technical notes_

• use example of gm-bot for cron job

• the example uses node cron

• studied & revised a lot of concepts and tools: neynar, nextjs vs express, fetch api, postman vs swagger.

• building toy version = cast from script, no frontend

• last update

_toy version_

1. project setup
- set up nextjs repo
- structure folders like this https://nextjs.org/docs/getting-started/project-structure

2. write logic to connect signer, neynar api key, neynar client and post cast
- first read docs for posting a cast https://docs.neynar.com/reference/post-cast then write all logic in one file neynar.ts but use these 2 github links as examples:
- main logic will be similar to this (search createcast) https://github.com/builders-garden/pulse-api/blob/main/src/modules/farcaster/farcaster.service.ts
- get neynar client from neynar api key https://github.com/builders-garden/pulse-api/blob/main/src/utils/neynar.ts

3. test the api call with postman
- study this about fetching apis https://developer.mozilla.org/en-us/docs/web/api/fetch_api/using_fetch
- set an endpoint and test with postman or swagger https://nextjs.org/docs/pages/building-your-application/routing/api-routes
localhost3000/api/qcast ... this will call route.ts inside api/qcast

_later_
4. endpoint accept calls only from my frontend
- to protect endpoint: create a x-secret in the .env
- pass to the api - in postman headers (or in frontend headers later) set it to be the same

5. in my frontend, only specific farcaster user can call api
- in page body, use neynar authentication so it gets the signeruuid from the fid
authentication https://docs.neynar.com/docs/how-to-let-users-connect-farcaster-accounts-with-write-access-for-free-using-sign-in-with-neynar-siwn

• i realised that my idea was too ambitious and loosely defined (houses onchain)

• i found a real problem to address for myself: scheduling casts on farcaster

• my new idea is: build a scheduler for casts on farcaster

_idea development_

• i write and schedule several weekly posts for x.com/ethrome and for x.com/urbeeth using buffer.com

• it's not the worst experience in the world, but not the best either, so i thought: can i do this myself with the x api, maybe some library like tweety, cron jobs and a cloud server? (https://vercel.com/templates/python) ...

  
  

• sure, i could, actually not too easy but can be done - apparently the x api is notoriously hard to work with. however... my friend and neighbourhood lemon (co-founder of urbe.eth) suggested, why not do one for farcaster? then we could automate posts on both platforms!

• so off i went figuring out how to do this... the cron jobs and server part remain the same, but the key tool will be the neynar sdk to post directly from a script https://docs.neynar.com/docs/how-to-create-a-farcaster-bot

• a nice to have would be to still connect to the x api, so that when my tweets scheduled on buffer are published, my app sees them and reposts them as a farcaster cast! not sure yet if we'd use this feature.

• my mvp has 3 steps:

  • 1. cast from script using neynar

  • 2. schedule a cast with a cron job

  • 3. host my app on a cloud server so it runs 24/7

• first things first. i am late as i have been finishing off https://beearly.club/ submission for the base onchain summer buildathon

• so now i need to build a toy version this weekend. i need to build step 1 at least, 😋

buildspace has 4 houses like hogwarts: spectreseek, alterok, gaudmire and erevald.

i'm enhancing the ‘houses’ experience!

or see previous update

_plan_

since s5 is 6 weeks long and i'm learning as i go, by the time i finish:

• defining the idea

• building the solidity smart contract

• building the thirdweb ui bit

• building the database

• building the frontend

• linking it all together

• + i'm building in public

...s5 will be over, so:

• 1, i will just build a simple database and super simple frontend and hopefully start getting users

• 2, i will try for a longer-term aim, not just the 6 weeks of s5

_priority_

• spin up a nextjs project with one page and simple user input to sign-up

• and postgres db

(anyone can sing-up - later i can introduce a 'certified' feature that can only be assigned by someone with @buildspace.so email address)

_intro for context_

buildspace’s nights & weekends season 5 has just begun! i will be working on “houses onchain”.

buildspace has 4 houses, a bit like hogwarts in harry potter: spectreseek, alterok, gaudmire and erevald.

They each have their unique traits and vibe:

• spectreseek is for the passionate. the bold. the pioneers

• alterok is for the reflective. the profound. the philosophers

• gaudmire is for the ambitious. the imaginative. the dreamers

• and erevald is for the harmonious. the rooted. the caretakers

my goal for s5 is to enhance the ‘houses’ experience within buildspace!

_idea_

• the basic idea is: students own an nft representing their house.

• specific actions award or remove votes to the overall house score and to the students' individual score.

• the individual points awarded have a weighting based on house size. this mechanism ensures that house sizes don't become unbalanced - i.e. new students are incentivised to pick smaller houses to get more points. unother method to address this would be to have sage act as a sorting hat, but i fear that ship has sailed since people have already been picking their houses.

• at the end of s5 (or of the year) there are prizes (tbd) awarded to the top house (e.g. everything temporarily branded like that house) and to the top students (e.g. cash award? or special buildspace swag)

• students are incentivised to join (i.e. get the nft, which is free) because then all of their hard work will be reflected in the houses and individuals' leaderboards, adding points to their houses

• students don't need to have a web3 wallet to do this, they can just login with google/fb... using web3 social login

_implementation_

user identifier:

• i'd create an erc1155 smart contract that mints 4 nft types (one for each house)

• or could store user wallet addresses or even e.g. emails on a db or onchain (need to weigh pros & cons)

ux:

• to remove friction from the ux, i'd use web3 social login using thirdweb tooling, meaning that users can just login with google / fb / apple... and that spins up a wallet for them. the only caveat is that those wallets won't have funds, so we'd have to send them the nft ourselves, which costs on the order of 10p per user.

• thirdweb offers react components to let users buy crypto (do i want this friction?), or also offers account abstraction functionality to let users mint with my money (hmm, worth it?)

I have to run now. wish me luck