vrypan |--o--| pfp

vrypan |--o--|

@vrypan.eth

1100 Following
30960 Followers
vrypan |--o--| pfp
lemon3 update. # Uploading - You can upload files (any file, but try it with audio/video) or any size. - The files, together with the metadata you provide are uploaded on IPFS. - Then a special link is shared on farcaster, together with a miniapp that renders the content. # Downloading: The miniapp is just a user-friendly renderer. If you want to download the files locally, you can use the "download" command. # Feeds The original promise of lemon3 was "something like RSS with enclosures, but decentralized". Now, you can use the "downloadfeed <fname>" command, which: - Will check fname's casts - Identify the ones that contain lemon3 embeds - Download the embedded files. # Limitations You need access to a Snapchain node and an IPFS node. For snapchain, the simples solution is a free Neynar dev account. For IPFS you can download the IPFS desktop app. Of course, you can use your own Snapchain hub and the command-line version of the ipfs client. Check out the repo for source/pre-build binaries, instructions. Check out @fc1's feed to see how the uploaded files look in practice. https://github.com/vrypan/lemon3
1 reply
0 recast
7 reactions
vrypan |--o--| pfp
1 reply
0 recast
15 reactions
vrypan |--o--| pfp
0 reply
0 recast
1 reaction
vrypan |--o--| pfp
7 replies
0 recast
15 reactions
vrypan |--o--| pfp
0 reply
0 recast
4 reactions
vrypan |--o--| pfp
3 replies
0 recast
7 reactions
vrypan |--o--| pfp
1 reply
0 recast
1 reaction
vrypan |--o--| pfp
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
0 reply
0 recast
10 reactions
vrypan |--o--| pfp
2 replies
0 recast
18 reactions
vrypan |--o--| pfp
1 reply
1 recast
6 reactions
vrypan |--o--| pfp
0 reply
0 recast
1 reaction
vrypan |--o--| pfp
2 replies
2 recasts
27 reactions
vrypan |--o--| pfp
2 replies
2 recasts
11 reactions
vrypan |--o--| pfp
(Moving this to a separate thread because it's not documentation-related and the original thread was about docs.) The lack of public nodes is a great example of what I described in my previous post about priorities and how they affect devs. So, Farcaster does not offer public API endpoints at the moment. It has practically outsourced this to Neynar. Which is great (we don't want a single entity to do everything, do we?). But Neynar had to obviously set some limits, so they have introduced some minor changes in the requests (an extra header with an api key, and limit to response size), and the infra (the node sits behind a proxy of some sort that checks the api key. The side-effect is your standard code, implemented according to the docs, that used to work with hubs does not work with Neynar's hubs, not without modifications. Had the core FC team had to deal with the same problem, they would have probably ended up with the same solution Neynar did. But the solution would have been part of the API spec. And the code I wrote (take fcp for example) and tested with my local hub would work with Neynar out of the box. Now, a) I've spent hours trying to understand how to implement and debug the Neynar changes. b) I can't tell a user, here is a program to back up your casts, get a free key from Neynar to use/test it. c) Why even mention fcp, if I have to respond to most of the requests, "well, no you can't use it, unless you set up your hub, dedicate 2TB of disk space and wait for a couple of days to sync".
2 replies
1 recast
5 reactions
vrypan |--o--| pfp
0 reply
0 recast
1 reaction
vrypan |--o--| pfp
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.
9 replies
8 recasts
55 reactions
vrypan |--o--| pfp
4 replies
0 recast
5 reactions
vrypan |--o--| pfp
4 replies
2 recasts
10 reactions
vrypan |--o--| pfp
1 reply
0 recast
15 reactions

Mini Apps

farma - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.

blog.vrypan.net - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.

l--o--l - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.

pingem - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.

Pingem Analytics - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.

Example Frame - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.

lemon3 viewer - Farcaster Mini Apps

A Farcaster Mini App by vrypan.eth

A mini app by vrypan.eth.