IngwiePhoenix on Nostr: So, here is the short-notes I made. Usually, I go from short notes -> concept ...

So, here is the short-notes I made. Usually, I go from short notes -> concept document -> PoC code -> mini documentation -> implementation -> documentation completion.

- dropstr is a read-only relay.
- Each event that dropstr presents is a file that it actually knows that it has - and can serve through a public HTTP interface (think ipfs gateway)
- Files are added through a separate API with very basic endpoints: add, del, ls. In the future I would like to use lists to have "folders".
- dropstr will write it's file events as well as it's reachable addresses (tor, i2p) to other relays as a way to offer them for others to download. Think DHT-lite.
- Idea: Each "file" is a list of chunks akin to multiple binary posts in usenet, allowing a client to pull from several servers simultaneously and also making step-by-step verification easier.
- A user may chose to manually import a file from other sources - but they may also opt to follow another dropstr instance (after all, its just npubs publishing things) with a certain strategy to optimize space OR redundancy: "big-to-small" would sort another instance's files by biggest to smallest and download them untill a budget is hit; "small-to-big" is the same but in reverse - whilst "count" is just the number of recently published files that this instance will and should also offer.
- Users may query relays or dropstr instances directly for files with standard relay queries.

What I haven't figured out:
- Chunking (related to the idea above)
- Privacy
- Which kinds can be re-used, which ones can not