Alright, #nostr / #nostrdev folks, I've got my implementation of multipart NIP-95 files up here:

https://github.com/NfNitLoop/yastr/blob/main/src/server/nip95.rs

(Yes, it's very messy. I just saw all the TODOs which I've already done. 😆)

And I've got a little tool to upload multi-part files here: https://github.com/nfnitloop/nostr-cli/  (The `nt upload` command.)

Since clients might not know how to put together multipart files yet, my relay (wss://www.nfnitloop.com/nostr/) also makes them available via HTTP. For example:

https://www.nfnitloop.com/nostr/files/bee3454df946e79724b0ec972242ba2d2e3a1fc185931a7a45def81a5ffb194c/

There is room for space-saving in the storage implementation. If this takes off I'd want to store the BLOBs in binary instead of Base64. And I'd probably want to dedupe whole files so that we don't end up having to store multiple copies of them if multiple people upload them. BUT, that can come later without changing the public interface.

Before *that*, I want to implement HTTP range requests to show that the blockSize metadata allows a client or server to efficiently fetch bytes from a known offset. That way you could, for example, scrub to a certain position in a video without having to download all the bytes up to that point.