Tony D’Addeo
@deodad
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
2 replies
3 recasts
30 reactions
W1NTΞR
@w1nt3r
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.
2 replies
0 recast
1 reaction
W1NTΞR
@w1nt3r
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.
1 reply
0 recast
0 reaction
Tony D’Addeo
@deodad
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?
0 reply
0 recast
0 reaction
