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.

I've been wondering about this—is there no obvious dapp aligned solution to hosting dynamic content at a static URL?

I'm not deeply familiar with ENS resolvers, the basic mechanism makes sense but I don't have a feel for the details and how hard would it be in practice. For instance, are there equivalents to public DNS servers being hosted that cache + resolve? What would it take to have a drop-in for fetch that works with ENS URLs?