Conversation

Notices

1. Embed this notice
   Mark T. Tomczak (mark@mastodon.fixermark.com)'s status on Tuesday, 17-Jun-2025 04:33:15 JST Mark T. Tomczak

   General Fediverse question.

   Sooner or later, the Fediverse will hit the point where somebody's individual node in their closet is the primary posting source for incredibly popular high bandwidth content, like a primary source news clip. As currently architected, the system will hug that data to death when individuals who do not have accounts on an equivalent fediverse server go requesting that content (and possibly also when 100 nodes of the given service go requesting the content).

   Are there any projects to do content distribution networks or other multiplexed and more local caching for fediverse content? What would that even look like?

   #fediverse

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 17-Jun-2025 04:33:13 JST silverpill

     in reply to

     • Adam Nelson

     @adam @mark I think IPFS is not necessary, as we already have a storage network with 30000 nodes, right here. The problem can be solved with signatures and digests alone.

     In FEP-ef61, both objects and media are portable and can be served by multiple servers (but the proposed media portability solution is not proven yet):

     https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md

   • Embed this notice
     Adam Nelson (adam@toot.nels.onl)'s status on Tuesday, 17-Jun-2025 04:33:14 JST Adam Nelson

     in reply to

     @mark I've been thinking about this a lot while designing Fediverse projects. One idea I had a while ago, while writing FEP-fffd[1], was to upload each public post to IPFS and then add a content-addressed IPFS link as a FEP-fffd proxy of the post. Then followers who receive these posts could mirror the IPFS version of the post, making it highly available.

     But it still has a few problems (besides the fact that I never implemented it):

     1. Does anyone still use IPFS outside of crypto? Projects that used it years ago, like Dhall[2], abandoned it because it was too unreliable. Is there a modern alternative?

     2. Other instances would still have to fetch the full Activity to see the IPFS proxy URL. Fixing this would require special behavior from compatible ActivityPub servers, like including proxy URLs in Announces, reply lists, etc.

     3. Content-addressing doesn't play well with edits (this is why Nostr still doesn't support editing) and there's no guarantee that all nodes mirroring the IPFS data will respect Deletes.

     [1] https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md
     [2] https://dhall-lang.org/

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 18-Jun-2025 03:31:25 JST silverpill

     in reply to

     • bumblefudge
     • Adam Nelson

     @by_caballero @adam @mark I like hashlinks. FEP-ef61 currently recommends them for media:

     https://codeberg.org/fediverse/fep/src/commit/2a0dac7212096ef4cce739969e4e30cef47e2337/fep/ef61/fep-ef61.md#media

     Unfortunately the RFC looks abandoned. Do you know anything about that?

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Wednesday, 18-Jun-2025 03:31:26 JST bumblefudge

     in reply to

     • silverpill
     • Adam Nelson

     Well, it depends what you mean by IPFS! IPFS is already a hashlink system (and URL scheme, and registered protocol), and is referenced as an interchangeable/cross-interoperable hashlink scheme in the hashlink spec:
     https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-07#appendix-B.2

     I think what you mean by "IPFS" is the IPFS DHT (with all its censorship-resistance properties and discoverability/networking pain points), which is not actually a mandatory way of dereferencing ipfs:// URLs anymore!
     @silverpill @adam @mark

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Wednesday, 18-Jun-2025 04:16:09 JST bumblefudge

     in reply to

     @silverpill @adam @mark
     If you're recommending them in the FEP you can always link to the abandoned internet-draft as a reference, but I don't entirely understand what "apgateways" and hashlinks give you that IPFS gateways don't also provide out of the box, since there are already an ipfs:// scheme (badly specified as it may be) and GET endpoints already built into implementations in multiple languages? you can configure an IPFS node to pin all its own CIDs indefinitely and set TTL for others.

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Wednesday, 18-Jun-2025 04:16:10 JST bumblefudge

     in reply to

     • silverpill
     • Adam Nelson

     @silverpill @adam @mark manu was proposing that so that Adobe could use hashlinks in C2PA, but I'm guessing no WG accepted it as work item, and/or adobe lost interest. I don't know if Manu/DB uses hashlinks in prod for their own clients?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 18-Jun-2025 04:27:27 JST silverpill

     in reply to

     • bumblefudge
     • Adam Nelson

     @by_caballero @adam @mark

     >but I don't entirely understand what "apgateways" and hashlinks give you that IPFS gateways don't also provide out of the box

     IPFS node is just not necessary, because ActivityPub servers can store media themselves. Hashlinks are preferable because they are simpler than ipfs URIs.