Main

ipfs

IPFS is local first and electable. https://thymer.com/local-first-ejectable

How could the Bybit attack have been prevented? I got the answer, and it's stupid simple

Base

Orbiter

The web is so cool. We just did a no downtime switch of hosting providers. Orbiter's app has been hosted on Orbiter in the staging environment for a while now and we just made the switch for our prod environment. Now, app.orbiter.host is on IPFS just like everything else.

Orbiter is proof that /ipfs is totally sufficient and capable for frontends. Don’t believe me? Our marketing site, web app, and docs are all hosted on Orbiter using IPFS and /base, all loading in < 1s.

You can just use IPFS ¯\_(ツ)_/¯

Orbiter is proof that /ipfs is totally sufficient and capable for frontends. Don’t believe me? Our marketing site, web app, and docs are all hosted on Orbiter using IPFS and /base, all loading in < 1s.

You can just use IPFS ¯\_(ツ)_/¯ 

https://orbiter.host

A few weeks ago when the Safe frontend was compromised, there were a lot of conversations about how IPFS could have solved the issue, but also some potential failure points. One of those was IPFS Gateways. These are hosted IPFS nodes that retrieve content and return it to the person using the gateway, and a weakness is the possibility of someone compromising the gateway and returning ContentXYZ instead of the requested ContentABC. This made me wonder: what if we could prove the CID? 

I'm still in the early exploration phases of this project, but the idea is to run a ZK proof of the CID with the content that is retrieved from IPFS to generate a proof that can be verified by the client. Currently using SP1 by Succinct and it seems to be working 👀 Would love any comments or ideas on this! Repo linked below: 

https://github.com/stevedylandev/cid_proof

pinata

🤫 

May or may not be giving you a sneak peek at our V2 SDK which was just released 👀

Public and Private IPFS are now supported in the same SDK!!

Private IPFS and Public IPFS all from a single API and SDK.

fc-updates

We would gain very little that benefits users, in exchange for slowing everything down, increasing costs and adding complexity.

Imagine a world where there was an integrations section to Warpcast and people could opt-in to connecting their Pinata account if they want to have their Warpcast media stored and distributed through IPFS. No cost to Warpcast, user opt-in. Seems to solve both sides.

TCP/IP would be Big Brother - constantly checking if everyone's still there and managing all the drama between devices.

HTTP would be The Bachelor - always making requests and waiting for responses, sometimes getting rejected with a 404.

IPFS would be Survivor - content surviving in a distributed world, forming alliances to stay alive.

Experimenting with ipcm.dev is one of my favorite past times. 

Today it's setting an @ensdomains text record with the Chain ID and contract address for my website's IPCM contract address. It's already populating the contentHash with the /orbiter ENS Resolver, but if you wanted to verify the CID onchain yourself you could! I'm a firm believer these are the first steps to having a more secure end to end flow for crypto enabled websites. 

The official @ipfs blog recently posted about how IPFS could have helped prevent the Safe hack but also goes over the limitations and what needs to be done. Definitely would recommend giving it a read!

https://blog.ipfs.tech/2025-could-ipfs-prevent-bybit-hack/

Your web3 username | Join the chat in /ens

Learn more: ens.domains | Register: app.ens.domains

IPFS is an open system to manage data without a central server

It creates a standard for builders that they are already familiar with.

The p2p stuff doesn't matter. It's about coordinating around CIDs.

Right now, content is broken across clients because people roll their own solution.

For instance, Supercast's content doesn't show up in Warpcast appropriately.

And then Warpcast wastes resources caching content that is already cached through Pinata.

IPFS solves this by allowing clients/builders to coordinate around CIDs and then process/cache the content how they see fit from there.

This is how NFT marketplaces work. OpenSea ingests content through CIDs and then process it and cache it to ensure the quality they want on their front end.

As for bandwidth, the client/builder serving the content pays for the bandwidth.

So, Warpcast pays for content that it serves but can easily ingest content from Supercast and vice versa. Supercast can grab content from Warpcast but it is on the hook for serving that content.

A PR to @ipfs-utils that converts it to ESM making it importable through CDNs, and removes 17 dependencies in the process

https://github.com/ipfs/js-ipfs-utils/pull/265

I don’t know who needs to hear this, but IPFS is local-first software.

IPFS is the only web3 protocol that uses protocol in the true sense of the word protocol. Meaning, it doesn’t require an incentivization layer

One of the main reasons I made IPCM was collected frustrations around IPNS: the native method of handling dynamic IPFS content. In this post I go into a more detailed comparison between the two, and why I think IPCM is superior. 

https://bit.ly/4gqwA8q