Your councept sounds very good to me and gives me food for thought for my own "dropstr" project. I had gone with the idea of HTTP gateways through i2p or tor due to simplicity; construct a giant list of URLs, feed them to aria2c, verify them and concat them into a file. Where the URLs initially came from is up to the resolver (the process that finds the locations of the file pieces) and may contain a list of different servers.
As for discoverability, taking advantage of the gossip model is one big opportunity. Releasing attachment events (nip98, i think? it was 90s, that far im sure!) with hints to file locations and thus media relay information would be my go-to solution, as you can publish whichever address currently works, and even use expires_at as a make-shift TTL. For instance, when you expect to auto-renew your files every N days, you would set that field to this very duration and republish it, allowing relays to clean up old events and to establish that, yes, this piece of data is still here.
I like the chunking approach, and have seen it in usenet. These guys got this figured out how to chunk and reassemble a file and yet still share a starting point to it. It's fascinating to me what they turned binary articles into.
Great proposal, love the idea, looking forward to the future. ^_^
IngwiePhoenix / Ingwie Phoenix
npub1tc…hjmky
2023-10-16 20:41:52
in reply to naddr1qq…40x5
Author Public Key
npub1tcekjparmkju6k83r5tzmzjvjwy0nnajlrwyk35us9g7x7wx80ys9hjmkyPublished at
2023-10-16 20:41:52Event JSON
{
"id": "37b9dc9ff43489017c8b97fda83b7796fcc429a3ebc26af4ff68c83d63dc6d80",
"pubkey": "5e336907a3dda5cd58f11d162d8a4c9388f9cfb2f8dc4b469c8151e379c63bc9",
"created_at": 1697481712,
"kind": 1,
"tags": [
[
"a",
"30023:0b963191ab21680a63307aedb50fd7b01392c9c6bef79cd0ceb6748afc5e7ffd:1696645035485",
"",
"root"
]
],
"content": "Your councept sounds very good to me and gives me food for thought for my own \"dropstr\" project. I had gone with the idea of HTTP gateways through i2p or tor due to simplicity; construct a giant list of URLs, feed them to aria2c, verify them and concat them into a file. Where the URLs initially came from is up to the resolver (the process that finds the locations of the file pieces) and may contain a list of different servers.\n\nAs for discoverability, taking advantage of the gossip model is one big opportunity. Releasing attachment events (nip98, i think? it was 90s, that far im sure!) with hints to file locations and thus media relay information would be my go-to solution, as you can publish whichever address currently works, and even use expires_at as a make-shift TTL. For instance, when you expect to auto-renew your files every N days, you would set that field to this very duration and republish it, allowing relays to clean up old events and to establish that, yes, this piece of data is still here.\n\nI like the chunking approach, and have seen it in usenet. These guys got this figured out how to chunk and reassemble a file and yet still share a starting point to it. It's fascinating to me what they turned binary articles into.\n\nGreat proposal, love the idea, looking forward to the future. ^_^",
"sig": "6d295d5dffa353875da181e09829bc29e852f77b00c44ae1ec7c02234d5b5461cb7a85daf4275686d32c0d99fbe231d60181c850c568b72166bb1b3b508fdaac"
}