enjoyed this piece from @w1nt3r 

one fun angle to explore for the new frames direction we are exploring: how could we make building dapps easier? some ideas:

- no need for a domain name if primary discover / access mechanism is via Farcaster
- IPFS is suitable for hosting if Farcaster clients are will to pull from IPFS and serve to users from their CDNs
- dapps could assume an Ethereum JSON-RPC Provider will be available if Farcaster clients provide this to frame apps

not a panacea but might be some interesting opportunities to make a difference

enjoyed this piece from @w1nt3r 

one fun angle to explore for the new frames direction we are exploring: how could we make building dapps easier? some ideas:

- no need for a domain name if primary discover / access mechanism is via Farcaster
- IPFS is suitable for hosting if Farcaster clients are will to pull from IPFS and serve to users from their CDNs
- dapps could assume an Ethereum JSON-RPC Provider will be available if Farcaster clients provide this to frame apps

not a panacea but might be some interesting opportunities to make a difference 

https://w1nt3r.mirror.xyz/csZhMabCHXYiUhnQHrje_6da1n0XZGQ7y2QoETkDyPE

Building @warpcast and @farcaster, new dad, like making food

IPFS is not very suitable for quick iteration, every time you change something or fix a bug, you get a new "URL". Would be fun to use ENS for this (fse.farcasterapp.eth's record points to latest IPFS hash), but seems clunky and one extra tech to worry about.

RPC node is also tricky, every provider has subtle differences on how they handle methods. E.g. can't get logs to work for @base's public RPC for long ranges, different QPS limits, etc.

Overall though I like the idea — I'd expect many farcaster apps don't need an out-of-farcaster UX anyways