Farcaster Was "Dead," So I Started Building
Two months ago, Farcaster was acquired and subsequently declared dead. Crypto Twitter shillfluencers incorrectly announced that the protocol would be shutting down (to be fair, it may not have been their fault that they were so misinformed). Since then, Coinbase’s Base App has ripped the Farcaster graph out of their system to focus on trading, sports betting, or something… not on decentralized social.
From the inside, many of us felt the shift. The timeline has been quieter, and the Dune Dashboards have been declining, quantifying the protocol’s death in real time.
So, naturally, as I watched my favorite social platform dwindle and everyone declare it was over, I did what any rational person would do.
I started building a new app on it.
There’s something interesting about watching a protocol reorganize. In a former life, I worked on a protocol that was once very popular but has since dwindled into irrelevance. But that protocol still exists. There are still people running nodes. I even check into the Discord from time to time, and people are still working; hoping for its eventual resurgence.
Decentralized protocols don’t die because the hype fizzles. The infrastructure lives on as long as there are nodes pinging.
Farcaster’s social graph is still open. The identity layer still works. The composability is still there, perhaps more than ever (more on that later).
Attention wanes. Architecture remains.
With Base App’s departure, there is now a vacuum. Client diversity took a major hit. There was a time when TBA signers were generating more content than any other client, including the Farcaster monolith. That said, most of this “content” was blue square slop, bot traffic, spam, or desperate airdrop farming. Uno is the last remaining high-quality alt-client.
Now that we’re two months on, the hot takes have evaporated, and the meta-conversation on the protocol’s future is getting stale. Even Rish is tired of it.
We don’t need more hot takes. If we want Farcaster to live, it needs to feel alive. Vibrant. Full of builders who give people a reason to come, join, and open the apps.
The missing primitive
Farcaster supports text, images, video, miniapps, and cross-chain actions. But there’s still something it doesn’t support natively.
Voice.
There are no native audio spaces anywhere in the Farcaster ecosystem. If you want to have a live conversation, you have to essentially leave Farcaster. You can open the FarHouse miniapp, sure. But the experience suffers from some architectural issues that are outside their control. You can hop on X Spaces or use Telegram or Discord VC, all of which defeat the purpose of using Farcaster in the first place.
That’s why, three days ago, I casted that live audio should be treated as a first-class citizen.
That night, I built Juke. Much like a real juke joint, I imagine it as the place where Farcasters gather to listen to music, chat, and vibe. A few days later, it was live on TestFlight, and you can join, create spaces, and listen now.
Why native matters
Web apps and, in turn, mini apps, are not suitable for live audio spaces. Specifically, background audio persistence (like when you lock your phone or navigate to another app), requires a native mobile app.
The reason apps like FarHouse don’t really work inside the mini-app context is because platforms like iOS kill WebRTC connections in the background within seconds.
You need AVAudioSession configured for .playAndRecord mode. You need UIBackgroundModes: audio in your Info.plist. You need a native Swift module handling audio interruptions like phone calls, accidental Siri triggers, Bluetooth routing, etc.
If the audio dies when you lock your phone, nothing else matters.
This single constraint shaped every technical decision that followed. A PWA wouldn’t work. Web client as an MVP was a waste of time. But I also needed to be able to support Android users. React Native with Expo’s bare workflow was the only day one decision that made sense if I wanted to roll this in a single evening.
The spec is everything
Or more specifically, the SPEC.md.
The most important aspect in developing something AI-assisted is the spec. I will die on this hill. That’s why I spent an hour writing an 800-line technical specification.
I’ve been developing on Farcaster for two years now, so I already had pretty deep prerequisite knowledge of the graph, Neynar APIs, etc. Combined with 10+ years of software development experience, I was able to shape the entire app’s specification with excruciating detail.
Every API endpoint, request shape, response schema, error cases, side effects. Every database table. The exact PostgreSQL schema. Every Redis key pattern. Exact data shapes and TTLs. The full Neynar auth flow (with code examples). LiveKit server SDK integration. All of the necessary Swift native modules. Component breakdown. A permission model that mirrors X Spaces for hosting, co-hosting, listening, etc. with server-side enforcement.
You have to go beyond documentation. What’s written must be an executable artifact.
With that in-hand, I instantiated 10 coding agents in parallel, each with a dedicated section of the codebase. They had access to the Neynar and Expo MCP servers, the latest documentation, smart package installation, screenshot capability so they could end-to-end test and interact with the iOS simulator to verify their work.
I watched Sinners while they worked. Roughly two hours later, I had a working MVP. Everything from Sign In With Neynar, a following feed, reactions, casting… everything. Because the SPEC.md included exact SDK usage patterns pulled from Neynar’s own documentation, the agents had zero ambiguity. There was nothing to hallucinate. Nothing lost in latent space.
This outcome is a testament to Neynar’s developer experience. It’s so clean that a well-written spec can one-shot the entire integration layer.
I would venture to say the Farcaster stack is one of the best in the decentralized computing universe. Few crypto projects (if any) are at this level of polish when it comes to DevEx or AIEx.
This fact presents a unique opportunity for Farcaster (and Neynar) to establish a refreshed presence among builders, especially as the AI vibe-coding boom is just beginning.
The FIP-2 Trick
After the initial scaffold was stood up, I did start to jump into the codebase to refine things and add features. One feature emerged during the build that was outside the scope of the intial spec, and it is probably the most architecturally interesting thing about Juke.
Live chat in audio spaces powered entirely by Farcaster’s native reply system.
When a host creates a space, they have the option to cast an announcement to Farcaster. That cast becomes the root of a reply tree. The replies are the chat. An ephemeral Neynar webhook spins up the second the space goes live and new replies stream into the Space’s UI in real time. When the space ends, the webhook is torn down.
This probably sounds pretty standard but think about it more deeply.
Zero chat infrastructure. No message database. No chat backend or WebSocket server for text. Farcaster becomes the chat layer, natively.
The result is cross-client visibility. Someone on Farcaster App or Uno sees the announcement cast. They can reply and participate in the live discussion even if they don’t have Juke installed.
When the space ends, the graph is left with a persistent artifact. The thread lives on forever. Even without recorded audio, the discussion is permanently captured on the graph.
This persistence also means the conversation retains native composability. The chat messages are simply casts. Indexable, searchable, and referenceable on the protocol permanently.
No polling, persistent connections, or stale state.
This is only possible on an open protocol. You cannot do this on X, Discord, Telegram, or any other platform.
Three days to air
Day 1: Architectural mapping. Technology selection. Cost modeling. Figuring out that LiveKit (open-source WebRTC SFU) was the right audio transport layer, and that its open-source model meant no vendor lock-in when costs scale. Wrote the spec. All 800 lines. Every endpoint, every schema, every native module, every screen. Agent swarm execution. Ten agents running in parallel. MVP functional by end of the night.
Day 2: Bug fixes, UI cleanup, concurrency testing. The FIP-2 chat feature emerged and got built.
Day 3: Landing page at juke.audio. TestFlight submission. Beta prep.
Today: Announce the beta, hope shit doesn’t break. Fix it if it does.
One developer. One spec. A swarm of AI agents. A protocol with infrastructure that's better than its reputation.
What’s next
Let me be clear: I’m not planning a token for this project.
Now that the TestFlight is live, the priority is getting real people to try the audio spaces. I deliberately made the auth flow narrow. If you don’t already have a Farcaster account, this beta is not for you. A Farcaster-native beta cohort is an obvious choice, since anyone still casting is likely invested in the protocol and understands early-stage software.
Monetization is something I’ve considered pretty deeply already. I think it makes more sense to lean on hosts for premium features. Scheduled spaces, custom links, analytics, recordings/replays, clipping. Things that turn an ephemeral space into a content asset.
The core experience (hosting, live chat, listening, the client itself) will remain free for as long as I can maintain the costs.
But let me get some users before we start thinking about all that stuff too seriously.
Thinking more broadly, the Juke codebase (and perhaps more importantly, the SPEC.md that generated it) could become a resource for the ecosystem. If desired, I could open source this working reference implementation for other devs to leverage as a jumping off point. Let me know if that’s of interest to you. I’ll need to do some cleanup in the codebase no doubt, but I’m happy to explore it if there’s demand.
Perhaps Farcaster isn’t dead. Maybe it’s just quiet in wait of a new place to gather. And in a world increasingly dominated by AI slop content, true connection feels more important than ever.
Juke is available on TestFlight as an open beta now.
