vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
The Farcaster ecosystem largely revolves around two main providers: Merkle Manufactory (MM) and Neynar. Both offer services that span the full stack, from low-level infrastructure (like Snapchain nodes) to end-user clients and miniapp tooling. I consider node improvements, specs, and documentation part of their offering in this context. This creates a resource allocation dilemma. As a startup with limited time and engineers, you naturally focus where ROI is highest. Right now, that seems to be at the top of the stack: ROI = end user growth. But this focus narrows innovation. While low-level infra allows many creative paths, the higher up you go, the fewer options you have. MM and Neynar appear to prioritize miniapps, wallets, and small UX features (like profile banners or max number of cast embeds). This is also reflected in the uneven documentation quality (ex., there is a dedicated website for miniapp development, 99% of the documentation is about using js/ts, the migration from hubble to snapchain is hardly reflected in the docs, and so on). The result: it’s increasingly difficult to build anything truly new. If you’ve tried using the low-level stack, you’ve likely hit countless friction points: a small detail here, a small detail there, a change that has not reached the docs yet, FIPs that would have made your life much easier but are of low priority, design decisions optimized for quick user growth and not DX. I know the answer: demand is king. I generally agree. But, maybe user growth is in places not on the path already laid out. And my concern is that diverging from this path, is getting harder and harder.
10 replies
6 recasts
50 reactions

Harris pfp
Harris
@harris-
recently I was looking to take inspiration in a lot of the sentiment that has been echoed by some people re: farcaster the protocol has a lot more than warpcast / social media the product, but the more I tried to think of a way to build upon that the more I kept finding things preventing it through these lower level primitives. Experiment: imagine how you might create a new client that treats casts as blog posts with .md or something. I kept ending up with the only solution being to disregard text and use links like you have with lemon3, but then you have timestamps that may or may not be related to publishing, no edits, you can only link 2 things through a cast one of which would probably have to be where the actual content is hosted etc, on top of a lot of wasted data types like mentions and reactions(maybe), anything custom on top needing global protocol discussions and improvements or be rejected from the network.. 🤷‍♂️ maybe I'll play around again at a later date to see what can be done :)
1 reply
0 recast
2 reactions

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
I'm actually thinking of building something like this on top of lemon3. Adding markdown mime/type support is trivial (I'll do it in the next days) and then all you need to do is render a person's timeline. It's on the todo list. (Bonus: get rid of the blog post title, which has dominated what blog posts are. See this for inspiration https://blog.vrypan.net/2016/09/23/blog-posts-without-titles/ )
0 reply
0 recast
1 reaction