ipfs

Farcaster

Cohost /gmfarcaster livestream Farcaster news and culture show🎙️💬 Founder Tenger Ways, bringing joy into work with DevOps practices 🤗 mom x 3 💗

1) IPFS can be slow and unreliable
2) The network is less self sufficient because casts now depend on IPFS
3) Embeds rot over time if data is not pinned or preserved
4) Clients need to build custom UI for every possible extended cast type
5) Competing standards for different data types may fight each other

Love you horsefacts, but this is one of the most tired arguments against IPFS. If I run an HTTP server on my computer and expose the port to the world, anyone making requests to it would say it's slow and unreliable. That's why people don't do that when they need speed and reliability.

Writer. Building @pinatacloud. Working on simple static site hosting https://orbiter.host \ https://polluterofminds.com

Doesn't IPFS [nodes] (unless pinned) down score/remove files that aren't accessed often? 

If true:
Comparing with HTTP: direct access to the server adds reliability, while IPFS if I ask for a file, the network decides whether I'll get it or not depends if someone has it.

As long as one node that is accessible has the file, it will be served. By using CDNs like the rest of the internet does, even rarely accessed content can be served fast. Pinata has built its whole business around making this true.

By uploading to a provider like Pinata, you get CDN plus access on IPFS by anyone, even those who don't use the CDN-backed Gateway. When uploading to S3, people have only one way of accessing the content. More importantly, though, is that IPFS provides CIDs and immutability.

>CDN

Yea, this part kind of makes the network redundant too. IPFS could be good as a backup in this case but my main go to in this workflow should prioritize uploading to CDN first instead of IPFS -> CDN. I guess people who want 'free' can take advantage of this but they're still relying on centralized infra then.