Brainstorming on Fediverse media storage improvements

ActivityPub
1

Howdy,

I’ve recently posted a rant adjacent blog at Call to Action: Fediverse Media Server – Shlee regarding my current problems with the fediverse/mastodon media storage and caching design.

I am keen to know if there is any prior art to pull from regarding any plans to enhance the AP ecosystem in regards to media storage… and hopefully start a discussion to pool our views/insights which might help towards building a standardised solution.

Formalising the Jortage modal with an official reference deployment that people can easily deploy and/or enhance would be a good start, but I’ve also brainstormed more complex solutions which has led me here.

My need for a solution is immediately driven because I want to host multiple fediverse instances while limiting my bandwidth requirements (with some basic de-duplication logic) but I’d imagine that a solution that works for me, would also work for everybody.

Considering the building blocks we have to play with… VMs for compute/transcoding. Disks for Local hot storage. S3 for warm storage. CDNs for regional replication and maybe even some AP for S2S communication between instances/fileservers and fileserver/fileserver for some enhancements. We should hopefully be able to make a common shared fileserver modal (lots of people ask thinking IPFS style solutions but I don’t have any opinion on that over something more stable and safe).

4 Likes
2

IPFS is stable, but slow and inefficient. But we can borrow some ideas from it. For example:

{
      "type": "Image",
      "href": "https://social.example/media/image.png",
      "mediaType": "image/png",
      "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
    }

digestMultibase property is currently being standardized at W3C. This is essentially a hash, and you can avoid HTTP request if you already have a file with the same hash in your media storage.

3

AHEM, speaking on behalf of the IPFS Foundation, I can say that using kubo locally and fetching CIDs from a public gateway from the public DHT is slow and inefficient. This is usually what people mean when they refer to “using IPFS,” but there are many ways to recombine and configure the IPFS stack. At its lowest level, IPFS is a particular way of calculating content-identifiers (and a specific CID syntax)-- all the details about how that creates a key/value store, and a “distributed file system”, how CIDs are advertised and searches and fetched and cached and persisted, all of that is actually pretty flexible and configurable… if you have the time to invest. Which I would imagine most people don’t who already have 10 other cans of worms open working on a Fediverse server!

So, long story short, if you want to standardize on media storage… you might do well to start from content addressing and assess IPFS as one popular CID standard among others, bracketing off all the other stuff, because if IPFS-style CIDs are what you want, there are many options beyond the classic kubo/public-DHT configuration! including alternate encoding clients, k/v databases, etc.

–

Separately, speaking only for myself, I would also recommend @shlee take a look at another SocialHub thread I just posted along related lines:

1 Like
4

digestMultibase looks perfect as a “known hash” point of reference.

The way I see it, this problem is solved in two parts. The API between the instance and the media server (standardised) and the the media server itself (free form).

Having a standard reference modal using something closer to Jortage would be great, and then a more node based P2P modal could be adopted. The IPFS style of people just adding extra nodes and having the system handle the anycast routing dynamically would be fun but it’s obviously not required. This sounds like a project for somebody with the right experience tho. :smiley:

2 Likes
5

For pooling resources, Jortage/Rivet seems to be a good solution. Do you think it is not enough?

6

I’m more than happy to just give the Jortage dev cash to build something but I’m also just an admin guy… I don’t understand AP enough to talk protocol or programming enough to actually build it…

So in theory, yes? how do we formalise Jortage/Rivet into the upstream code. I’m not the one to push this because I am dumb. :slight_smile:

7

As I see it, the way media is stored is an implementation detail and it doesn’t need to be standardized. Anyone can build a media pool and publish API docs. Then ActivityPub server developers may integrate that into their software if there’s enough demand from instance operators.

For the server-to-server protocol, I can only think of the digestMultibase (or a similar property), which should enable some optimizations.

1 Like
8

I too would love IPFS to become widespread. For those with less time they could even use an IPFS service such as Filebase https://filebase.com/

1 Like
9

Yeah. Not standardised in the W2C way… ok… I’m going to step off and start talking to devs but the way I see it… this can be done in stages.

Stage 1: S3 compatible service with file de-duplication.
Stage 2: Rivet style API
Stage 3: P2P/AP smarts

3 Likes