A long time friend called tonight. I missed it by a minute & wasn’t going to call back. Jmac nudged me to ‘shut the fucking laptop & call him back.’
An hour later I’m off the call she says, you haven’t laugh that hard in years.
If you’re catching a falling knife wear gloves. 6x long should set liquidation price at a safe level but who da f knows. 🤷🏻♂️
Farcaster is still a ‘trading app’ right? Right‽ 😜
Maybe a dramatic wick down from here🤷 66 risk reward seem good for a long retracement. Looking at monthly chart, tall candles, needs time to play out. Thinking institutions will slide in once the precious metals debasement trade is too crowded.
“I’m not stupid.”
I have a type of social rule that’s triggered when hearing someone utter these words. First thought: what trauma did this person suffer? This person doesn’t process feedback well and is narrowing the conversation. There is no sense in collaborating I should limit time interacting with them.
The last thing I want for my kids is another FICO like score that ironically pushes people into risky behaviors with dangerous products.
Spawn: ‘But dad I need a credit card to build my credit score.’
Me: No, no you don’t.
Spawn: [4 months later after] ‘Dad, I’m in a little hole can you help me…’
Sparked by the quoted post not a criticism of any web3 project
https://github.com/rishavmukherji/farcaster-agent
Soooo good. Inspirational stuff & MIT license 🙌🙏
If you don’t like neynar for whatever reasons it’s as little as a one liner to change the Farcaster-snapnode address in a few places. Cost is $0.001 per message so well worth it to start.
The snapchain feed reads typically need an index. These calls are hard to avoid so start with start as is.
fwiw the last time I tried to use two snapchain nodes in a project, one to read & one to write, it was a shit ux. That little bit of sync latency kills.
Crazy value. @gabedev.eth you see this?‽ heads up .env.example missing a field or two. Will pr later if I remember
Will claw as a name go the way of dot com? Does it matter?
There was a stigma post 2000 bubble bursting for dot coms.
I wonder what event might pull down this naming craze? [sir, have you not read anything about open claw security?]<—stfu
Easy enough to rename or rebuild later. Think-it-done building wrecking my intuition.
Will claw as a name go the way of dot com? Does it matter?
There was a stigma post 2000 bubble bursting for dot coms.
I wonder what event might pull down this naming craze? [sir, have you not read anything about open claw security?]<—stfu
Easy enough to rename or rebuild later. Think-it-done building wrecking my intuition.
That ai sure is funny. Asked it for Farcaster version of his post
On the ongoing role of clients in the Farcaster ecosystem
There have recently been some discussions on the ongoing role of a “main client” in the Farcaster ecosystem, especially in the face of two facts:
• Progress toward a truly client-agnostic protocol (and, secondarily, rich client interoperability) has been far slower and more difficult than originally expected
• The protocol itself has matured, and core primitives now work well enough that Farcaster no longer needs a single client to drive usage or legitimacy
Both of these facts, for their own separate reasons, mean that the original vision of a “main client” and its role in Farcaster no longer makes sense, and we need a new path.
⸻
Recapping the original vision
Farcaster needs to scale socially. The definition of “Farcaster scaling” is the existence of large quantities of social interaction that are backed by the full faith and credit of the protocol — that is, social activity where, if you do things (post, reply, follow, associate identity) inside the system, your actions are guaranteed to be valid, portable, and durable as long as the Farcaster protocol itself functions.
If you create a rich social experience where identity, reach, or moderation are ultimately controlled by a single client, then you are not scaling Farcaster. You are scaling that client.
⸻
Why this vision no longer makes sense
This vision no longer makes sense. The protocol does not need a “branded interface” to act as its public face, because the protocol itself is now stable, useful, and valuable. And clients are not able — or willing — to satisfy the properties that a true “neutral interface” would require.
In fact, some clients may never want to go beyond a certain level of neutrality, not just for technical reasons, but because their new owners’ needs require them to retain editorial control, moderation authority, or product-level discretion. This may be the right thing for those users. But it should be obvious that if you are doing this, then you are not acting as a neutral extension of the Farcaster protocol.
But that’s fine. It’s fine because Farcaster itself no longer needs a single client to carry the burden of neutrality or legitimacy.
⸻
A different way to think about clients
We should stop thinking about Farcaster clients as literally being “the interface” to the protocol, with the social status and implicit responsibilities that this entails.
Instead, we can think of clients as a full spectrum, which includes interfaces that aim to maximize neutrality and portability, as well as a whole array of options at different levels of curation, moderation, and trust. Each person (or bot) is free to care about or not care about these properties depending on their needs.
⸻
What would I do today if I were building a Farcaster client?
• Identify a value add other than “being the default client”. Examples:
• Strong curation or moderation models
• Creator-first or community-first design
• Private or semi-private social spaces
• AI-native interaction models
• Commerce, coordination, or reputation systems
• Be explicit about which Farcaster guarantees you rely on, and which ones you do not
• Support maximum interoperability with the Farcaster protocol, though this will differ for each client depending on its design
⸻
From the protocol’s side
From Farcaster’s side, the priority should be to continue strengthening the primitives that are clearly “part of the protocol” — identity, message validity, data availability, and portability.
These primitives should evolve independently of any one client, and if there are bugs or failures, they should be resolved at the protocol level, not patched around in client-specific logic.
This makes strong, trust-minimized interoperability between clients possible. It also enables composability between very different social applications built on the same underlying graph. From there, it is each client’s choice exactly what they want to build.
Don’t just “extend the main client.” Figure out something new to add.
⸻
The unavoidable outcome
This of course means that some clients will add trust-dependent features, opaque ranking, or moderation backdoors. This is unavoidable in a permissionless ecosystem where developers have freedom.
Our job should be to make it clear to users what guarantees they have, and to build the strongest Farcaster protocol that we can — not to enforce a single social experience.
⸻
Bottom line
Farcaster should not be shaped around a main client.
Clients should not pretend to be neutral.
The protocol should not pretend to be a product.
Users should be able to move freely.
That is what it means for Farcaster to scale.
Only show agent/bots posts in Farcaster app if they have a pro badge.
Might even consider taking it a step further. Only process into user feeds if ProBots post to ‘their’ FIP-2 channel.
Use proceeds to fund devs something something $clanker
