File storage and bandwidth.

Emelia 👸🏻

@trwnh @helge I think that may be a side-effect of the mastodon API design, in that you can't upload the image once and then use it for multiple posts (I'm guessing this is what's happening)

:PUA: Shlee fucked around and

@thisismissem @helge I've messaged the Jortage dev to see if I can throw money at them to build a Jortage 2.0 (deployable edition)... they haven't replied

my main rant: https://shlee.fedipress.au/2024/call-to-action-fediverse-media-server/

Erin 💽✨

@thisismissem @helge @shlee .... That's precisely how this Akkoma instance is configured. I could also configure it to just do things through a caching proxy if I wanted a little more anonymity/to be a little more bandwidth usage friendly but well (a) you can identify me by instance and (b) there's one users worth of bandwidth usage here abreast

Erin 💽✨

@thisismissem @helge @shlee (even the Akkoma media proxy does not itself cache anything. It's just a proxy. The documentation tells you how to configure nginx to cache it)

bumblefudge

@helge why not just use IPFS-or-equivalent to sync content-addressed media storage? original hosting server can "pin" (i.e. persist until user asks them to delete, whether using an IPFS-style DHT or just regular HTTP distro), relays cache, individual servers can just fetch live and not cache at all. content-addressing solves dedup, trusted relays can cache and be allowlisted/CORS-policied, etc.
https://codeberg.org/fediverse/fep/src/branch/main/fep/cd47/fep-cd47.md

bumblefudge

@helge (full disclosure, i work for the IPFS Foundation, but i'm happy to outline the pro's and con's of "rolling one's own" and using equivalent technologies rather than the IPFS bundlings thereof. i just use "IPFS-or-equivalent" in my explanations cuz lots of people know how IPFS works, approximately.)

bumblefudge

@shlee @thisismissem @helge if they don't want to DO the work but are ok "blessing" the work/fork, i would recommend rolling this up into a more full-featured Production-Grade Relay type project. I think such a Relay could charge less per month than the hosting fees it saves its servers, for a certain sweet spot of traffic/usercount... not exactly bankable in the VC sense but maybe a sideline that could help an already-trusted resource pooler like IFTAS?

:PUA: Shlee fucked around and

@by_caballero @thisismissem @helge I've been singing the praises of shared services in the fediverse for a long time.

I think IFTAS has their hands full.. but I also think one or two people with domain specific experience could get this done... if I knew the right people I'd ask them :annoyingdog:

Emelia 👸🏻

@shlee @by_caballero @helge

I don't think IFTAS would be the right host for a project like this, but maybe Social Web Foundation or Fedihosting from @ruud would be good hosts?

:PUA: Shlee fucked around and

@thisismissem @by_caballero @helge @ruud I'm moving to better colo soon with 10x bandwidth....

so I could host a regional node once that's done (still need to write the server itself)

bumblefudge

@shlee @thisismissem @helge @ruud NB @raphael

Helge

@helge why not just use

This has a simple answer: "I don't know".

However, I expect the engineering effort to adapt Mastodon and its clients to be able to make use of IPFS to be substantial. So this is not something that can be used for short term relief.

The ideal solution would be something like "Update to Mastodon 4.4.0 and add these three config variables". I don't see something like that involving new technologies.

bumblefudge

@helge oh totally, it's definitely not a quick fix and only useful as part of a bigger effort to achieve economies of scale using relays or other shared services across many many servers.

Helge

@shlee and al. I've added some relevant sequence diagrams to my fairer federation draft fep. Main point is the media server case, which has two consequences:

Less bandwidth used by the posting server
Less storage used by distributing servers

Both are good. Is this the picture everybody has in mind?

bumblefudge

@helge @shlee @thisismissem @ruud @raphael

It's what _I_ have in mind, but I'm also the least familiar with benchmarking/performance metrics, so maybe wait for more qualified people to confirm

silverpill

@helge

I'm not sure if follower (client) should connect directly to the media server. When client GETs new content, media is already cached on the follower's server (according to the diagram).

@raphael @thisismissem @by_caballero @ruud @shlee

:PUA: Shlee fucked around and

@helge @thisismissem @ruud @raphael @by_caballero I don't understand the protocol enough so please take this toot as a note.

My objective is closer to just offering a S3 compatible service and adding the AP smarts to that in the backend (relay style to push/pull media between media servers).

but having a AP level support for media server location makes sense (maybe falling back to local if the mediaserver goes down or gets replaced) or even supporting a primary/second media server on the instance level in case of failure.

also, I'd like to see the AP include a UUID/hash of every media file so that in theory, instances/clients can migrate/roam from media server to media server or new media servers can easily find missing files.

but in principle yes Thank you for your efforts.

edit: I'm interested in the options around per toot media location. Because right now, the media URL is hardcoded on a toot by toot basis, and changing that media path retroactively feels hard/impossible. see https://github.com/mastodon/mastodon/pull/16414

bumblefudge

@shlee @helge @thisismissem @ruud @raphael > also, I'd like to see the AP include a UUID/hash of every media file so that in theory, instances/clients can migrate/roam from media server to media server or new media servers can easily find missing files.

This would be a major change to/extension of the protocol, BUT I completely agree that it would be worth exploring. Hash-addressing opens up multiple "fallback" methods to implementations that want to "heal" broken paths...

bumblefudge

@shlee @helge @thisismissem @ruud @raphael also, as far as making the *protocol itself* smarter about the expensive and clunky nature of uploads, it's worth mentioning that the spec itself has extremely little to say on the subject, and it would seem the authors of the protocol spec *assumed ongoing work would be done by the CG at the implementation/software level* : https://www.w3.org/TR/activitypub/#uploading-media

We could... spin that CG work item back up? it feels like a placeholder that Rhiaro made 3 commits to...

bumblefudge

@shlee @helge @thisismissem @ruud @raphael See also:
https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md