Content
@
0 reply
20 recasts
20 reactions
nyc-crypto-cabal-kid
@zinger
Hard truth: most of the replies to this complaining about how channels aren’t in the protocol are just cope Channels not in the protocol? Build your own channels. Direct casts not in the protocol? Build your own direct casts. That’s what Warpcast did. What you’ll come to realize (after a bunch of wasted time and effort) is that channels are a product problem, not an engineering one Apps that only focus on one or a few channels don’t make sense, not enough of a wedge or retention mechanism, partially due to how early we still are but also people don’t want to download a separate app for each of their interests Apps that focus on all channels and encourage you to check them individually are too much work for the user (see Discord, Telegram, etc) so you end up back with an algo feed to surface the most interesting content in one place Building a social app is a retention (and GTM) problem for the most part, not a technical one — and it’s hard as fuck https://warpcast.com/zinger/0xa6906bb7
7 replies
0 recast
115 reactions
Matthew Fox 🌐
@matthewfox
All facts
0 reply
0 recast
2 reactions
Michael Pfister
@pfista
This feels directionally correct for channels but having a harder time seeing why it is the case for direct casts, especially wrt b2b farcaster apps. To narrow the problem through Buoy's lens– our customers are teams on Warpcast and they have to manage customer issues via DC. Building our own DC system wouldn't solve this, because end users don't use buoy. End users DC founders who then have a hard time managing it all between their team, and that's what our product aims to solve.
0 reply
0 recast
1 reaction
Dan Romero
@dwr.eth
Good take.
0 reply
0 recast
1 reaction
tomu
@tomu
personally i don't understand the value prop of a channel-client. what's the retention rate for nouns x farcaster clients? exactly, it's hard as fuck you also kinda want distribution, /itookaphoto without the main feed doesn't make a lot of sense. what's the end value? to be descentralized and add monetization? hypersub and moxie are already experimenting with that, let's see how that scales first
1 reply
0 recast
3 reactions
ns
@nickysap
"Apps that focus on all channels and encourage you to check them individually are too much work for the user (see Discord, Telegram, etc)" Respectfully, I'm not sure I understand your analogy here. Those apps have hundreds of millions of users, billions combined. Most of their growth was driven by referrals from other social apps. Focused channels have proven to be insanely popular on other networks, even ones that encourage discoverability via algorithmic feed (Reddit). What about more esoteric networks like 4chan, which are even more "challenging" for the user? Still 20MM+ users. Just because something is hard doesn't mean it's not worth doing, especially when the model has proven successful in many cases.
1 reply
0 recast
4 reactions
Ivy
@ivy
‘Just build your own ______’ is a protocol problem, ppl expect some bare minimum standard of primitives and the lack of them is often cited by ppl for not building or extending products here I really think the buoy from frames has contributed to some arrogance
0 reply
0 recast
0 reaction
Apurv
@apurvkaushal
this can apply outside of social apps as well - in general for content apps as well. when you have a lot of features & content you would like your users to try. now building a separate URL for each is suboptimal, a separate app is worse off. Nav bar is current solution for us but doesn't work the best when within a widget as well you have refreshing content every day.
0 reply
0 recast
0 reaction
