A rough draft of a BUD-10 for multi-part uploads to blossom servers. not sure if this is a good idea so I'm looking for feedback The biggest issue comes from the fact that blossom relies on the sha256 hash of the whole blob. so there isn't a way to verify that each uploaded chunk is part of a whole until the all the chunks are uploaded. I think this issue can be mitigated slightly if the client includes `x` tags in the auth event for each chunk its uploading. so that the server can verify that each chunk was created by the client. In the case of payments, I think it could be possible for the client to pay for each chunk. although this might require more requests or the server to define an x sats/bytes pricing. Inspiration taken from Thanks to @fiatjaf for making me aware of it

Replies (12)

Yes, I think. Most clients cant keep a long running http requests for uploads, and mobile clients need a way to retry parts when the network fails or times out
Thanks @hzrd149 as always. I’m happy to take a look and give some feedback. You should consider the GET side of this using range requests. This would assist in downloading larger files.
Would it be possible for there to be a client side blob creation first, send/upload that hash ID first, then begin the chunk upload process? (if I understood that that the blob hash is used to check the chunk hash ID)
CanopyKev's avatar
CanopyKev 9 months ago
I have a working demo at just look for the Chunked uploader section. It will chunk to IPLD standard and produce a IPFS compatible CID. It will publish the chunks to a Nostr relay. It also has a visual representation of the chunks and what's already uploaded. So partial chunk resumes/completions already work.
CanopyKev's avatar
CanopyKev 9 months ago
Oh, and the website above is stored in Blossom as a chunked dag-pb set and served up in realtime from the blossom server.
Appreciate the progress in this! Will most likely use this for @DEG Mods when the time comes, as a lot of creators will most likely attempt to upload large files on it (hundreds of MBs to double-digit GBs) Appreciate what @Colby Serpa is doing as well on their end.
Depending on how large some of the mods get it might be worth attempting to use torrents. since they are much better for larger files. IMO the only reason to build on top of blossom instead of torrents is if you know the files are going to be small (cat pictures) and they NEED to work in the web browser. otherwise if you building a desktop app it would probably be much better with torrents
Makes sense. I guess I need to consider that down the line then. I'm basically thinking both now and in the future. And the future being a lot of people having very convenient home servers with Blossom Drive, and start mirror mods and providing their links to it to be discovered, for the mods they like, to support/enhance their availability and censorship resistance. I guess testing these things out and seeing what comes as the best setup solution
É muito bom ver que o #Nostr está em constante movimento 🤠 View quoted note → View quoted note → Será possível cobrar por um conteúdo em específico e até vender usando ZAP e Blossom. E também outras novidades interessantes.
hzrd149's avatar hzrd149
A rough draft of a BUD-10 for multi-part uploads to blossom servers. not sure if this is a good idea so I'm looking for feedback The biggest issue comes from the fact that blossom relies on the sha256 hash of the whole blob. so there isn't a way to verify that each uploaded chunk is part of a whole until the all the chunks are uploaded. I think this issue can be mitigated slightly if the client includes `x` tags in the auth event for each chunk its uploading. so that the server can verify that each chunk was created by the client. In the case of payments, I think it could be possible for the client to pay for each chunk. although this might require more requests or the server to define an x sats/bytes pricing. Inspiration taken from Thanks to @fiatjaf for making me aware of it
View quoted note →