Intro

"Not your keys, not your coins." The phrase cuts through crypto like a knife. Simple. True. Final. Whether you're new to crypto or a veteran, understanding how we got here matters.

Picture this: someone hands you a series of random letters and numbers. These characters control everything you own on the blockchain. Lose it, all is gone. Share it, all is stolen. This was true in 2009. It's still true today. The core challenge remains: how do we put cryptographic keys in everyone's hands?

The math behind blockchains is elegant. Public-private key pairs. Digital signatures. Hash functions. Merkle trees. Each piece clicks. Easy-peasy, right? But most people first touch this technology through something with a familiar name: a wallet.

We borrowed the word "wallet" from the physical world. It worked because everyone knows what a wallet does. It holds your cash. Your cards. Your license. The photo of someone you love. The receipt from that special night. But as our lives move to the blockchain, maybe we need a better analogy.

Let's trace how we got here. Two things matter: keys and coins. One controls, one holds value. Together, they tell the story of how crypto tried to make cryptography work for everyone.

The math was solid. The cryptography worked. But people needed ways to use their keys. Evolution came in waves. Each wave brought new tools. Each tool made keys easier to use. The audience grew larger. What started with cryptographers spread to developers, then to tech-savvy users. Although mass adoption remains a distant shore.

Bitcoin Core (originally called Bitcoin-Qt) was released in 2009. At first, we had a piece of software which ran in the terminal. CLI – command-line interface – meant typing text commands to interact with your computer. No buttons to tap/click on. No URLs to access. No visual interfaces. The barrier to entry was a bit higher than using cURL. It functioned as both a non-custodial cryptocurrency wallet and a kind of validator.

A typical interaction looked like this:

$> bitcoin-cli sendtoaddress "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" 0.1

This command would send 0.1 BTC to a wallet address - assuming you typed the 34-character string perfectly. One mistyped character and your funds are forever gone.

There was no encryption until version 0.4, so before this, keys were stored in plain text, on the local hard drive. Users faced a brutal choice: risk losing their funds through technical mistakes, or risk theft through inadequate security.

Developers built tools for developers.

Security paranoia bred creativity. Some printed or engraved their private keys on physical objects: paper, metal, wood, you name it. Casascius coins were cool for a while. Still are IMHO. Blame holograms.

User Experience (UX) rating: ★☆☆☆☆

- Required technical expertise

- High risk of user error

- No safety mechanisms

- Direct blockchain interaction

Command lines scared people away. The industry saw an opening. "Give us your keys," they said. "We'll keep them safe."

Mt. Gox led the way in 2010. Started as a trading card exchange, it became crypto's first major exchange. By 2014, it handled 70% of all Bitcoin transactions. Then it fell. Hard. Hundreds of thousands of Bitcoin vanished. Millions in value, gone. A decade later, users finally got some coins back - about $8 billion worth. An expensive lesson in "not your keys, not your coins."

Between 2010 and 2013, other services followed: MyBitcoin, Instawallet, Bitcoinica, BitFloor, Cryptoxchange and more. Some were actually exchanges besides simple services to store keys. People mixed up the two concepts and most of these services didn't end up well. Hacks, scams and general loss of funds were too easy.

At least they lowered the barrier to:

1. obtain Bitcoin

2. store Bitcoin

The user experience was simple and akin to managing a bank account. One step forward from the terminal.

The risk of giving away free reign over your keys was too high. At that point, you might as well email them your credit card PIN.

Blockchain.info (established 2011, eventually .com) started as a blockchain explorer and, like most business who want to take advantage of the attention and recurrent traffic, they added a wallet service.

UX rating: ★★☆☆☆

- Simple

- A bit more secure than the terminal

- Not much more than a bank account

- Sometimes open-source

Bitcoin is only one token. Somewhere between this phase and the next, the number of alternative tokens exploded. For brevity, I won't mention too many of them.

Web browsers became the new frontier.

MetaMask changed everything in 2016 during the DevCon 2 conference. Suddenly, crypto lived where people lived - in their browsers. It did mean people had to download and install one additional piece of software. Some were reluctant because browser extensions can be a breach of privacy, but convenience won over.

MetaMask brought gifts. Self-custody without command lines. Key management without complexity. A wallet that felt like an app. It opened doors to Web3. To NFTs. To DeFi. Millions of users followed.

Store the seed phrase in a fire-proof safe at your grandma's house and your exposure to most of the attacks was greately reduced. A win is a win.

dApps were born. They are like websites or apps, but run (aka. persist data) on various blockchains and this earns them the "d" prefix from decentralized.

UX rating: ★★★☆☆

- Simplified transaction flow

- Requires an additional plugin

- Always-available access

While browser plugins revolutionized access, they were a single point of failure. What if more people should have complete control over their funds? Split the risk. Enter the era of multi-signature wallets.

What if you can't trust yourself with your own keys? A "Bitcoin Improvement Propolsal" (BIP) introduced the concept of multi-sig in 2011 through BIP11. The idea evolved a bit since then.

Ethereum introduced smart contracts, and because the blockchain is a public ledger, developers connected the dots. Numbers and flags indicating how many N ___insert_arbitrary_unit_of_measure___ correspond to each wallet could be stored on blockchains through smart contracts. Multi-sig wallets were born.

Gnosis Safe lead the way. Built for anyone who couldn't trust a single key. Two signatures out of three. Three out of five. Five out of seven. Choose your security level. Choose your trusted circle.

The corporate world took notice. DAOs embraced it. Teams adopted it. Multi-sig became the standard for serious money. But complexity crept in. More keys meant more coordination. More signatures meant more delays. Security and speed fought their eternal battle.

The UX was akin to an upside-down pyramid. N wallets need to sign so 1 multi-sig can act upon the blockchain.

UX rating: ★★★☆☆ (not better, not worse)

- more secure than a single-sig wallet

- more complicated to use; perfectly ok for some use cases

Mobile apps dominated consumer tech. They could do anything. Including hold keys. But holding keys wasn't enough - what's the point of holding keys if you can't use them?

Browser plugins proved something important: non-technical users wanted wallets ready at a click. But mobile browsers struggled with plugins. The solution? Turn wallets into browsers. Now every dApp journey started through a wallet's lens.

This tech later circled back to desktops. Brave (launched Jan 2016) and Opera (launched 2018) tried to replicate the mobile browser experience of having wallets built-in. They came late to the party. The mix of "wallets" and "browsers" felt forced. "Wallets" means money, currency, serious stuff. The stuff you can eventually exchange for a Lambo. Browsers are for casual surfing, no?

UX rating: ★★★☆☆

- one-single app for all your web3

- not open-source

- avenue to become a lot more noisy, opinionated and pushy than a regular browser

Smart wallets brought new promises. Account abstraction (AA). Programmable accounts. Gas abstraction. Words that meant little to users but changed a lot about how wallets worked.

Take Safe (formerly Gnosis Safe) or Argent. They let you recover accounts through guardians - trusted friends or devices. No more lost seed phrases. Privy is building quite a bit in this space.

Crypto folks started talking about different types of wallets: externally owned accounts (EOAs) (the "vanilla" ones we had from day 1) and smart wallets (smart contracts which can act on behalf of users).

This shift brought familiar authentication patterns - like email-based recovery and multi-factor authentication - to blockchain interactions.

These smart wallets have a few other notable features, but their main claim to UX-fame is that they work just like your e-mail. Most people use Gmail, MS Outlook, Yahoo, [insert centralised email provider here]. That's flawless, right? Convenience wins again.

UX rating: ★★★★☆

- smoother UX than a regular wallet

- back to email and co.

With this evolution of wallet tech, the concept of ownership has become increasingly nuanced. You might think you own the currency in your wallet - it's there, nobody can take it from you (barring security breaches). You are your own bank and investment manager. Wall St bros envy you. But what does ownership really mean?

Today's crypto wallets are command centers - managing identifiers (not identities), authorizing transactions, and connecting to various services.

True ownership died somewhere between subscription services and terms of agreement. You might not even own the seat warmers in your car. What's the point of owning, if there's a paywall to unlock meaningful access to a feature?

Perhaps it's time to move beyond the wallet metaphor entirely. We don't say "digital cameras" or "horseless carriages" but simply "cameras" and "cars". They're tools for proving who you are and what you can do on networks that matter.

Should I explain why you don't really own the Oura ring on your finger? Or how surveillance has a real price tag?

If there's no ownership, what's the value? The value is in access, history, context. In the digital footprints you leave and the reputation you build.

Your tokens are not currency. They are proof. Proof that you were there. Proof that you participated. Proof that you believed.

Take CryptoPunks. People say they're worth millions. But that's not why they matter. They matter because they mark a moment. Summer 2017. The birth of something new. You don't own an asset; you own a verifiable relationship with a moment in time.

These aren't baseball cards. They're not stocks. They're not even digital art, not really. They are timestamps. Proof that you were there when it happened. When it changed. When it mattered.

The coins in your wallet tell your story. Where you've been. What you believed in. What you built. The networks you joined. The risks you took.

That's what sits in your wallet. Not money. Stories.

As we've seen through this journey of wallet evolution, the tools we use to interact with blockchain networks have come a long way. Yet, human-friendly solutions remain elusive.

History has many versions of information systems: books, wallets, computers, libraries, banks, browsers, spreadsheets, and all the nuances in between. Each solved specific problems of their era.

Now we face a new world. Everything connects to everything. Hyper-connected. Old tools don't fit anymore. A wallet can't hold the internet. A browser can't secure your future.

No wallet deserves five stars. Not yet. Not when billions need to use it. Not when it holds their future.

We need something new. Something that fits this connected world. Something as simple as email, as secure as a vault, as personal as a signature.

The old metaphors are dying. Let them die.

We tried to make cryptography simple. Still trying.

Command lines scared people away. Custodial services got hacked. Browser plugins helped but created new problems. Multi-sig added security and complexity. Mobile wallets promised convenience but brought confusion. Smart wallets look familiar but hide their risks.

Two steps forward, one step back. [1]

The challenge isn't technical. We solved the math. We wrote the code. The challenge is human. How do we make the complex feel simple? How do we keep security without sacrificing speed? This article isn't just about history - it's about understanding where we are and where we need to go for crypto to reach its potential.

As we move toward mass adoption, the technology needs to become invisible, working silently in the background while users focus on what matters: using their assets, not managing them.

Where will we be 5 years from now? The journey continues. The challenge remains.

Thanks to Philip (@sheldrake) for catching inconsistencies and pushing for clarity. To @afrochicks for suggesting structural changes that made me question my choices. To @beecurious for bringing the beginner's mind - fresh eyes see what experts miss. To @ccarella.eth for encouraging personality over dry facts. And to @tako-unik for asking the hard questions about audience and purpose.

[1] A more accurate visualization stuck in my head is pixel-by-pixel animation like in the old Snake game. For the snake to move forward, the rightmost pixel must turn black, while the last pixel must turn white. Done fast enough, it creates the illusion of movement. Same snake, same number of pixels in length. The only moment the snake grows is when it eats.

This article is meant to expand on this open visual map I assembled over the last few months.

Are you excited about AI? Ready to build something amazing? A product or a business? You're not alone!

The world of AI is exploding with possibilities. There are tools, platforms, frameworks, and resources everywhere you look - maybe even too many to sort through on your own. That's where this guide comes in.

We'll walk through each step of the ML development cycle together. You'll discover what matters, when it matters, and why. Some steps blur into each other, and certain platforms serve multiple purposes. That's okay. Skim through what interests you most, and dive deeper when something catches your eye.

Speedrunning? Focus on getting from raw idea to happy customer. Everything in between is just details we can optimize along the way.

Starting out? You might fixate on models and deployment. That's natural. But there's more to the story.

This article has been published on HackerNews too. Any votes/comments are welcome.

As you move beyond those first prototypes, you'll discover that building AI products involves a deeper journey. Let me show you why each step matters:

- Data Quality Issues: Poor data in means poor results out. When your initial data curation falls short, you'll face endless cycles of expensive re-training and cleanup.

- Technical Debt: Rush to deploy now, pay the price later. Without proper infrastructure and monitoring, you're building on quicksand. Each shortcut becomes a future roadblock.

- Resource Waste: Teams without a plan burn through resources like wildfire. They train models they don't need. They over-provision infrastructure they barely use. Money vanishes into the digital void.

- Maintenance Nightmares: Documentation matters. Monitoring matters. Skip these fundamentals, and you'll find yourself unable to maintain or improve your models. Your future self will not thank you.

- Scalability Barriers: Ad-hoc solutions create bottlenecks. These barriers become walls. Walls that prevent your AI solutions from growing with your success.

Following a structured development cycle changes everything. It helps teams see around corners. It keeps resources flowing to the right places. Most importantly, it builds AI solutions that last - solutions that deliver real business value, day after day.

Let's walk through each step of this lifecycle together. In a systematic manner.

It all starts with data. Raw. Messy. Full of potential.

Your data might come from anywhere. Public datasets wait on Kaggle. Governments share treasure troves of information. Research institutions open their archives. Or maybe it's your own data, living in warehouses, CRMs, and countless spreadsheets. Need something specific? Third-party providers stitch together custom solutions - for a price.

But raw data isn't enough. It needs care. Attention. Purpose.

You'll clean it first - removing duplicates, handling missing values, smoothing out the rough edges. Then comes curation. Adding context. Labels. Metadata. It's complex work, but specialized tools make it manageable.

Let's look at an example. Here's raw data, exported from a legacy system:

Now see it transformed - structured, labeled, ready for action:

Privacy matters here. Compliance isn't optional. GDPR, CCPA, HIPAA - they're not just acronyms. They're promises to protect. If your data warehouse handles these well, you're ahead of the game.

Let's assume you're familiar with what an AI/ML model is. Your first big decision? The classic "buy vs. build" question.

Think about this. Some models are trained on 25,000 GPUs. They learn from billions of data points. They cost millions to create. You could use one of those. Or you could build your own from scratch. Each path leads somewhere different.

Let's make it crystal clear:

- Buying means using someone else's model

- Building means training your own

Concrete example. Say you're working with human language. You need to understand words, sentences, grammar. The smart move? Grab an open-source model like Llama 3 or Mistral. They've done the heavy lifting.

But maybe your company is different. Maybe you've got unique data about Earth's climate that no one else has. Petabytes of satellite imagery. Years of temperature readings. That's when you might want to train your own model, just like IBM and NASA did.

Consider the climate impact. The equivalent of five cars' lifetime emissions is no small footprint.

Here's a framework to help you weigh these trade-offs:

The buy vs. build decision isn't final.

Your choice can evolve. Many start with pre-trained models, then build in-house capabilities as they grow. It's a journey, not a destination. Hybrid approaches are common.

Let's see this framework in action with a few examples:

1. Customer Service Automation

- Buy: OpenAI's API handles queries. Your prompts shape the voice

- Build: Your data trains your model. Your rules. Your way

- Key factor: How much proprietary support data do you have?

2. Document Processing

- Buy: Pre-trained OCR and NLP do the heavy lifting

- Build: Custom models speak your document's language. They are fit for your types of documents.

- Key factor: How unique are your documents?

3. Product Recommendations

- Buy: Generic algorithms point the way

- Build: Your user data creates magic. Your models are tailored to your users' preferences.

- Key factor: Is your user behavior data unique enough to matter?

Whether you "buy or build", fine-tuning matters. It refines models to fit your needs as they evolve. This process is efficient, with a smaller dataset. It saves time and resources. But be cautious. Limited data can lead to overfitting - a dead end for models.

Fine-tuning means continuous improvement.

Think of training as teaching a child from birth. It's slow. Demanding. Resource-hungry. The model learns to spot patterns in data, testing its knowledge against validation sets. Fine-tuning? That's more like teaching new tricks to an expert. You're building on existing knowledge. Adapting. Refining.

Watch out. The pitfalls are subtle:

- It's still slow

- It still needs serious compute power

- Too little data? You'll underfit

- Too much focus? You'll overfit

- Balance is everything

There's a hidden danger: catastrophic forgetting. Your model might excel at new tasks but forget its original skills. Symptoms? Loss of performance on tasks the model was initially good at. Like a musician who masters jazz but can no longer play classical.

One more thing: guard against data-leakage. Keep your training and validation sets separate. Clean. Distinct. Your model's future depends on it.

A trained model is simple, really. Just weights and biases. Numbers in a file. That's all.

The format? It varies. You might see .safetensors. Or .bin. Maybe .h5 or .pt. Each serves its purpose.

Working with teams? You'll need somewhere to host these files. Somewhere that handles versions. Hugging Face shines here. Git works too, though it needs some setup. Those large files can be tricky.

Data engineers know this dance. DevOps teams too. Hosting isn't new - we've been doing it for years. But AI brings its own twists:

1. Model serving infrastructure

2. Version control with A/B testing

3. GPUs, GPUs, GPUs

Think security. Think access control. These models can hold secrets - treat them like your company's crown jewels. Like that critical internal database you guard so well.

This step has the smallest footprint. Yet it can feel the most rewarding.

Working on open-source or research models? You'll want to give others a chance to play. Who doesn't like testing a good AI?

Streamlit and Gradio make this simple. They handle the hard parts - all those client-server interactions you'd rather not think about. They're true full-stack solutions. All your UI elements live in a few files. Sometimes just one.

Platforms like Hugging Face shine here. They've sparked a new trend of "AI apps". Host your model on their platform. Build your UI on top. Watch the magic happen.

So your model is ready for prime time. Your users are eager to try it out. Exciting times!

How will it integrate with your product? Through inference endpoints, usually. REST APIs or real-time websockets. They take inputs. Process them. Return results.

For LLMs, it's different. SDKs handle the heavy lifting. They abstract away the complexity. Make it simple.

REST APIs? They're everywhere in AI. Most providers follow similar patterns. Especially for chat interfaces. Makes switching providers easier.

Models need maintenance, like any system. Updates. Retraining. Replacement. That's where MLOps shines. CI/CD pipelines automate the process. Keep deployments consistent. Make updates smooth.

Watch your resources in production. Inference isn't cheap. It's not like simple CRUD operations. Your hardware needs will vary. GPUs are a common requirement. Small models might run on CPUs. Image generation? That needs GPU power. Lots of it.

Once your model is in production, you'll want to keep an eye on it. Like any system, it will have its quirks. Its edge cases. Its moments of brilliance and confusion.

While monitoring might feel familiar to DevOps teams, ML ops brings its own challenges. Its own metrics to watch. Its own patterns to understand.

Here's what you'll need to track:

1. Accuracy - is it still getting things right?

2. Latency - how fast does it respond?

3. Throughput - how many requests can it handle?

4. Cost - are resources being used efficiently?

5. Model drift - is it losing touch with reality?

6. Error rates - where does it stumble?

7. Confidence scores - does it know when it's unsure?

When your model sits in a critical path, monitoring can't wait. Real-time alerts matter. Budgets need watching. Thresholds need setting.

For example: Watch how your model performs on real-world data over time. Set alerts for sudden accuracy drops. Don't ignore those gradual declines. They'll sneak up on you.

Remember, you don't have to tackle everything at once. Each step in the ML lifecycle can be handled by different teams. Different expertise levels. It's modular.

I've started maintaining a curated list of helpful tools and resources. It's open-source. Growing. Living. Feel free to check it out and contribute if you'd like!

Did you find this guide helpful? Share it with others who might benefit. The future of AI and ML is whatever we make of it.

Let's make it amazing.

P.S. Thanks to Breno for reviewing this post and for invaluable feedback.

Fascination with Seeds vs. Fruits

Seeds grow eventually into fruits.

Fruits bear seeds, but could also be enjoyed on their own. Which is the common metaphor. Fruits are results. Seeds need effort, right conditions and, most importantly, time.

What are you focusing your scarce attention on? Fruits or seeds.

Don't judge each day by the harvest you reap, but by the seed you plant.
Robert Louis Stevenson

Garry Tan from YC, as well as others in similar positions, often speaks about picking winners. Winners, and humans in general, are a bit more complex than seeds and fruits, but the metaphor holds true at any stage of growth. All winners have a bag of failures.

As fruits are an end result, winners could hit a dead-end.

Would it not be optimal to find winners just before they hit it big?

Seeds, "future-fruits", are on a growth trajectory.

Future winners, sometimes find themselves on a similar trajectory. A winning trajectory is like a seed's optimal growth conditions:

• Upward progress (like a seedling breaking through soil)

• Accelerating rate of improvement (similar to exponential plant growth phases)

• Accumulating advantages (nutrients in the soil building up)

• Positive feedback loops (stronger roots enabling better nutrient absorption)

• Resilience to setbacks (well-rooted plants surviving storms)

Just as a healthy seedling shows early signs of growth, individuals on winning trajectories showcase:

• Rapid skill acquisition

• Expanding network effects

• Increasing opportunities

• Growing resource access

• Compounding knowledge base

Choosing the right seed could be perceived as gambling. The Gambler's Fallacy is the mistaken belief that if something happens more frequently than normal during a given period, it will happen less frequently in the future to "balance things out" (or vice versa).

In a fair contest where each game is independent, previous wins or losses have no influence on future outcomes.

Even after 100 wins in a row, the probability of the next game remains unchanged (assuming all other factors are constant).

However, the Gambler's Fallacy doesn't apply when lessons from one game roll into the next iteration and even less when trajectories are considered.

Just as some seeds carry better genetics from stronger parent plants, serial entrepreneurs carry forward their accumulated advantages. The "seed" metaphor refers more to potential and trajectory rather than purely to newcomers or first-time ventures.

Planting seeds and expecting future fruits is a complex probability problem. It can be expressed as multinomial distributions due to the many possible outcomes.

We can simplify this by reducing it to a basic binary question: "Will this seed result in a fruit?" This creates a simpler binomial distribution.

However, this simplification has limitations. It falls short when we're expecting rare outcomes or unique fruits - which is often the case in entrepreneurship and innovation.

While individual bets might be risky, markets have historically proven to be effective at pricing risk and predicting fruitful outcomes. This is where prediction markets enter the picture – they harness the collective wisdom of many participants to estimate probabilities of future events.

Should we start prediction markets for seeds?

Should we start prediction markets for picking the next unicorn?

Clever tech has been developed to simplify the process of spinning up this type of markets, yet reaching a critical mass of participants remains difficult. Critical mass is a combo of both number and variety of participants. Without such critical mass, the odds are not representative of said expectations. Some fundamental assumptions around incentive alignments needs to be made. Early traction could replace prediction markets, as a sort of clunky proxy.

If growth is a trajectory, patterns like the Hot Hand Phenomenon are more likely to be amplified. The flip side is that the regression to the mean doesn't hit as hard when on a trajectory.

Future events appear to be subject to randomness. Less so in hindsight.

Unlike pure chance games, entrepreneurs can leverage:

• Accumulated experience and learning from previous ventures

• Established networks (investors, talent, customers)

• Pattern recognition; better ability to identify promising opportunities

• Better risk assessment capabilities

• Access to capital based on track record

• Reputation advantages

These factors compound, increasing the odds of future success.

A (potentially-over)simplified model could look like this:

# python
def success_probability(previous_successes):
    # baseline success rate
    base_rate = 0.01
    # multiplier for each success
    experience_factor = 1.5
    # compound network effect
    network_factor = math.pow(1.2, previous_successes)
    # cap at 90% (relatively arbitrary. What is ever 100%?)
    return min(base_rate * experience_factor * network_factor, 0.9) 

HBS suggests founders who succeeded in a previous venture have a 30% chance of succeeding in their next venture.

Failed founders perform better than first-time entrepreneurs.

Experienced gardeners are better at spotting which seedlings show the most promise.

Network studies show that entrepreneurs' networks grow exponentially with each venture, supporting the network_factor in the probability model.

Growth is a process. Low to high, small to large, slow to fast.

Picking winners is a matter of spotting winning trajectories. Recognize the seedlings that show promise before they bear fruit. This insight applies beyond entrepreneurship to talent development, personal growth, and opportunity evaluation.

Remember:

• Today's fruits were yesterday's seeds

• The best time to plant was yesterday; the second best is today

• Not every seed will sprout, but every success story started as a seed

• Focus on trajectories, not just current results

• Compound growth rewards early believers

Be early. Plant wisely. Nurture growth. Fruits will follow.

What trends today are seeds and what are their fruits?

What are the odds of a seed becoming a fruit?

Who is planting seeds today?

Reach out on Farcaster, LinkedIn or Twitter. Would love to hear your thoughts and challenges!

Wishing a fantastic week to all 10 of you! 🌟

If you're enjoying my writing, please share this post with your second-best friend and join the /tudor channel on Farcaster 🤝

My handwriting is not as legible as I'd like it to be. Some people have suggested I write more, others have suggested to simply slow down. Both are right, so I started a Morning Pages ritual every day. 3 pages, no judgement, just stream of consciousness, no expectations beyond the process itself.

My medium of choice is a lined notebook, because it strikes the right balance of freedom and guidance.

A completely blank page is intimidating. Gathering one's thoughts is difficult enough, so dealing with slanted lines and inconsistent spacing is the last thing the mind needs. Particularly in moments when aesthetics are at a premium.

Although John Tetlow invented the machine to automate drawing lines, generations before him have come up with the idea – the right type of lines on notebook paper.

The early inventors must have experimented with various alternatives to parallel, horizontal lines, before settling on a few conventions.

As with all conventions, we have a few choices and contexts to choose from, as alternatives to horizontal lines. From quadrille ruled paper to music sheets, these guides are an ubiquitous tool, for both students and professionals.

Could we use plain blank paper? Sure, especially if pushing artistic boundaries.

Guidelines and norms are important for our activities, particularly in collaborative environments.

Very recently Farcaster redefined how channels work, essentially drawing new guidelines. Time will tell if these changes are for the better. One certainty is that the existing communities are writing on a new set of lines, metaphorically speaking.

Part of this doc was inspired by the /okbanger episode about control.

Photo by Damon Lam on Unsplash

Most creators track the perfromance of their content. But what if we flipped the script? What if we tracked our own engagement?

It's a simple idea. Maybe even foolish. But it's possible here, where data runs wild and tools like Dune await.

I introduce to you the personal Farcaster healthcheck. Ready to use.

Consistency. Engagement. Quality. These are the pillars.

Be a beacon in your cosy corner of the web. Contribute. Show up.

This dashboard lays bare your Farcaster life. It shows your patterns. Your strengths. Your weaknesses. Use this knowledge. Grow from it.

See your casts, reactions, replies, and recasts. Understand your impact. Forge stronger bonds.

1. Visit the dashboard.

2. Get a Dune account. Free is just fine. If you already have one, you know the drill.

3. Type your username in the user_input_fname box.

4. Hit "Run" in the top right.

5. Read. Learn. Act.

If you find value here and feel the urge to give back, mint this memento.

For those who dig deeper, the source code awaits on GitHub. It's there for posterity. And for you.

Not any auction, because wanted to push some limits and test some theories, but rather an Bidding Fee Auction, a distinct category of All-pay Auctions. To contextualise, we named these "DEGEN Auctions".

They have been around for a while, although less popular than other established siblings, Dutch or English. 

On an axis between English Auction and Raffle, the DEGEN Auctions sit close to the middle:

• like traditional auction, the winner is not random and it requires a drop of skill, mostly around timing and understanding the mechanic

• like a raffle, the winner has a high reward while all others loose money

DEGEN Auctions aim to test player behavior, including their response to competition and value assessment in high-stake, low-win scenarios.

One of the motivations for engaged players to continue is the sunk-cost fallacy.

Some theories to verify were:

1. People like to compete against friends and strangers for a prize ✅

2. Frames are a good, casual playground for such experiments ✅

3. All players are comfortable with Frame Transactions 🚧

4. Players are less apprehensive about playing with memecoins 🚧

5. It's a good alternative to mints or token sales 🚧

The item offered is important. It should have a clear, market-established value that people know and can quickly asses if the risk of losing your entire bid is worth it. Eg. a bid of 10$ for a PS5 worth 500$ is in the realm of buying a lottery ticket.

No opportunity for price discovery here, because it would break the psychology behind the game mechanics.

The vision here isn't along the lines of Sotheby's selling a priceless piece of art with a very high, yet unknown ceiling to some avid collectors or status-seeking-money-bags.

We decided to auction off a fun, nounish, /yellow token with a nod to Farcaster and Base:

Farcaster

Toady Hawk 🟡🎩 ᖽ on Warpcast

Today’s Collective Noun is just… chef’s kiss 🤌 - Farcaster arch head ✅ - @base blue stripes ✅ - Yellow noggles and background ✅ And it popped up on the 1st day post-Farcon to boot! 🤯 Follow along with the auction & bid in-frame👇 https://imagedelivery.net/BXluQx4ige9GuW0Ia56BHw/95f4a9f2-766a-46b7-83ac-d882c9ff9200/original https://frames.paperclip.xyz/nounish-auction/yellow-collective

Before going further, the auction itself:

Farcaster

Tudor 🟣🟡 Engineer to fCTO on Warpcast

I'm auctioning my favourite /yellow (worth 0.5 ETH) in a "Degen Auction" format, starting at 1 DEGEN. Sad to see this little fella go, but I'm sure it will land in good hands. Bid now! https://magicframes.xyz/spell/auction/34

Some players became very competitive.

The auction lasted far longer than we expected, given our relatively small potential outreach and audience, so the excitement from a Friday evening continued well into Saturday.

As a developer I started getting paranoid about various things that could break or get hacked over night, which is why I did my best to reply to everyone. The burden of MVPs!

30 players placed 199 bids over a span of almost 19 hours. The cast got 1.3k of views.

Query source: https://dune.com/queries/3733870/6280362/

For reference, around 400 bids would be needed to reach the market value of the NFT auctioned. Anything beyond is profit for the seller. There's a formula!

We did not break even.

The Hub API has an experience-breaking delay. Reactions take a while to appear in the Frame Message from frames.js so players had to refresh the frame a few times. This might be a data propagation issue, although the FrameActionHubContext is populated through a Neymar hub. There might be a few ways to improve this flow. Still experimenting.

We need to be better at explaining the rules, because this auction format is even less known than I thought. Regardless of existing similar web2 businesses and TV ads. Curse of knowledge. One immediate step was to populate the official docs.

The Frame Transaction experience is great, but not full-proof. One of the first bugs we hit was when people placed bids from wallets that were not verified on Farcaster, thus we couldn't obtain the their username to display who the current bidder is. This exact area broke in multiple ways though.

Still on Frame Transactions, the mobile UX opened the Coinbase Wallet app, but failed to open alternative ones like Rainbow. Must investigate this further.

Other popular auction formats have certain goals:

• get the highest price possible for an item

• raise funds and grow membership of a DAO like /yellow, /purple and Nouns.

• allow customers to decide their buy-in price like hotter wheels

Raffles are great at raising engagement with your audience, although border-line engagement farming and certainly in the grey area for the healthy growth of a social platform.

Where do all-pay auctions fit in?

Our theory? Midway between auctions and raffles again.

Unused stock is a missed chance to engage with a potential audience. A missed 2nd chance. 

Nouns has >500 NFTs sitting in the treasury. What if a small number of them would be auctioned off?

A creator has an NFT which is valuable with a healthy floor price in their wallet. Why not auction it off and allow fans to collect it, a lower price point for the individual, but high enough for the creator?

These auctions are sometimes meant to run across multiple days. Why not keep "Channel Tourists" entertained and allow them to punt a bid?

A few marketplaces and communities have DC'ed us to run auctions, but we're mostly focusing on implementing lessons + feedback from players, as well as fix bugs and clarifying comms.

The Farcaster protocol is moving fast and they recently announced programmatic Direct Casts, which are perfect for keeping players informed about the progress of the auction, as long as the balance between informative and noisy is achieved.

Follow us on /magicframes where we continue to experiment and build tools native to web3 communities. We tip and buy pizza for feedback.

Thanks @breno and @iggy for review and feedback.

To the players, I'm grateful for your participation and support! ❤

WAGMI

How can we best ensure that 3 months from Friday Nouns has at least one amazing Farcaster client?

Delivering a great app is not trivial and complexity creeps up easily from behind punchy feature names, wireframes, sketches and concept art.

I value pragmatism, so allow me to be boring for a moment.

Nouns x Farcaster clients have layers:

• data layer: aggregate, filter and store the Nounish content

• presentation layer: display the data in an engaging and aesthetic manner

• governance layer: decisions on client features, curation, contributing

The data layer is mostly already out there, because /nouns have historically done a cracking job at creating and putting-it-out-there! Algonouns enhances this layer, by collecting and sort it, based on transparent and customisable criteria. It introduces a new primitive fit for the ethos of Nouns. Unlike most social apps, Algonouns optimises for discovery and connection, instead of ads and “fame”.

Presentation matters. "Good UX" is relative and unpacks based on type of content, user habits and accesibility. Illustrations (source), videos, stories and gifs are meant to shine in NounTok. The familiar feed + voting in Nouncaster aims to quickly pop nuggets of news, while nurturing reactions by voting or replying. More Kiwi News, less Facebook. Nounishness is part of the content and adds or subtracts weight to how readers perceive the latest DAO launch (as one example).

Tangent: Kiwi News introduced Feedbot recently, with a similar goal.

Finally, the governance layer should be concise and permissive. A lot of issues are solved by CC0 and open-source, models which in the long run outlive even the coolest BDFLs. You don't have to be Nounish to read the spec and contribute your own curation buy assembling an algo in Algonouns.

References and context

A video deep-dive in Algonouns: https://www.loom.com/share/b14cf7b8792249aeabe91b1489c59c93?sid=fc473216-4101-457a-bc07-61c5ce897dc9

Nouncaster in the prop.house: https://prop.house/0x767a3bdf2aa3b3201b794927a997fcf4e50d4702

Let’s build a Farcaster Frame!

After reading this tutorial, you will be have an understanding of the main components driving a Frame and see them in action.

As content for this tutorial I assembled a little trivia-style game: MVP or Not MVP. The objective is to guess whether a product or service were MVPs when publicly announced. Players select one of two options and at the end receive a score based on the number of correct answers.

Frames are rather simple primitives and after reading the official spec of a Frame, you might get a sense of what they are and why they unlock a new level of interactivity inside social feeds. They extend the OpenGraph protocol by adding dynamic content on top of what was meant to standardise static metadata about web pages.

How do you build one?

Some familiarity with Next.js is encouraged, although you could simply clone the repo, run it and tinker with the code, a lot of less obvious conventions are imposed by the framework.

Along the way, I will explain some fundamentals and lessons learned.

Architecture

This demo has the following components:

1. The Frame front-end - to render URLs with Frame meta tags

2. The Frame Server - to handle taps on buttons and advance the game

3. Persistent Storage for the game state - to store the game across sessions

4. A Farcaster Hub - to validate FIDs and message data

When Farcaster clients try to embed the content of an URL, they look at all the <meta> tags in the <head> . If clients find a set of tags that correctly define a Frame, they render it, otherwise they fall back to the OG protocol.

The first rendered frame is cached, so the best practice is to not have dynamic data on it.

When users tap any of the Frame buttons, Farcaster makes a request to the Frame Server to perform some logic and return the content of another Frame.

The URL of the Frame Server is defined by the <meta property="fc:frame:post_url" content="..." /> tag.

Step 1 - Create a first static Frame

This is almost trivial given the generateMetadata functionality in Next.js 14, because inside this function we only need to return an object with the right keys.

Here’s my example:

Source from /app/page.tsx

fc:frame:post_url and fc:frame:image point to the Frame Server, which for this Next.js app is hosted on the same machine as the front-end.

This Frame contains a single button, with default actions. Tapping it makes a POST request to /api/start with info about the user who tapped and index of the button.

Step 2 - Responding to the button

This logic sits server-side on the Frame Server, so it has access the persistent storage service to initiate the game.

Source at /app/api/start/route.ts

The Request object is key here, because it contains a payload sent by Farcaster with an encoded version of the message, the FID of the user who triggered the action and the URL of the frame. These can be validated by a Farcaster HUB. I use Neynar in this demo. The validation logic itself is fairly straight-forward and lifted from the official Frames demo. See it inside app/frames.ts.

To separate display from business logic, the endpoint completes with a 302 redirect to the page which renders a new Frame and new buttons.

The first screen had a single button, so there’s no need to check its index, because it can only have one function: start the game.

After the redirect to /start a frame renderes with the first level:

So far we covered 3 paths:

• / (root path)

• /api/start

• /start

These 3 paths cover the core loop of any Frame:

1. Render

2. Interact

3. Call Frame Server

4. Repeat

To chain multiple levels together, I split the game in 3 stages:

1. /start - the first screen which starts the game

2. /next - levels 1 through 5

3. /over - the final screen

Each stage is comprised of an API endpoint plus a corresponding Next.js page.

Diving into /next as an example, this is the API endpoint:

Source from /app/api/next/route.ts

Assuming the game did not end, the code to render the next level Frame looks like this:

Source from /app/next/page.tsx

The API endpoint passes query params to the Next.js page it redirects to. Here, the game id is sent so the page knows which image to display.

Next.js runs the above code client-side, so we won’t have access to server-side functionality like Storage.

Step 3 - Rendering Images

So far the app takes advantage of mostly Next.js boilerplate code, while following the Frame specs. The final challenge is rendering images for the frames. Fortunately, there are quite a few options available:

• Satori for generating SVGs from HTML

• Sharp for rasterizing SVGs to PNGs

Here's a glance over the code:

Source app/api/images/level/route.tsx

Step 4 - Recap

The cycle is complete once the image for a new frame is rendered. Forks in the logic path can be added and the flow expanded path this point. We can now build navigation for a tiny, focused app.

That was it! This minimal game emphasizes the best parts of building Farcaster Frames.

Constraints are great for innovation as they provide focus, encourage creativity, foster resourcefulness, create urgency, x promote efficiency. These limitations encourage innovators to concentrate on specific problems, think creatively, utilize resources effectively, act swiftly, and seek efficient solutions. The key lies in approaching them with a positive and creative mindset, turning challenges into opportunities for breakthroughs.

In times when the UI stack for building web apps is getting more and more complex, Frames feel like a fresh take, back to first principles of interaction, natively supported on most platforms.

If Next.js is too much and because most of the content is rendered on the server, you can choose almost any other framework, regardless of language. I was tempted to replicate this demo in Flask, FastAPI or Hono.

Play!

Play "MVP or Not MVP" here: https://warpcast.com/tudorizer/0xd122d681

Checkout the repo: https://github.com/tudormunteanu/frames-demo-1/

FAQ

See also

The state of the Open Graph protocol doesn't seem to be great. Twitter has cards, while Google went with another standard from schema.org.

While the core value prop is simple: "encourage websites to include metadata which tells other platforms what they should look at", the value prop of similar standards might soon be challenged by AI, given the relatively narrow and content driven scope of the intention.

I'm hopeful this enhancement of the standard will live on at Farcaster and improvements like Frame Transactions take it to new heights. Building it in public, sufficiently-decentralised and outside the tutelage of one entity might lead to a different fate.

If you have further questions or need additional clarification on any of the content discussed in this tutorial, don't hesitate to reach out on Warpcast, Twitter, LinkedIn or GitHub. I'm always open for conversations and eager to assist!

Remember, learning is a journey, not a destination. Let's keep exploring together.

Thanks to everyone who reviewed this article, gave feedback and tips. Particularly Tommy and Mark.