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
IngwiePhoenix / Ingwie Phoenix
npub1tc…hjmky
2023-10-16 13:43:29
in reply to nevent1q…tjur
Author Public Key
npub1tcekjparmkju6k83r5tzmzjvjwy0nnajlrwyk35us9g7x7wx80ys9hjmkyPublished at
2023-10-16 13:43:29Event JSON
{
"id": "dc1fb032e9dc87ca59a7c55de248fc548764491a766459862c847f2cd434a8f9",
"pubkey": "5e336907a3dda5cd58f11d162d8a4c9388f9cfb2f8dc4b469c8151e379c63bc9",
"created_at": 1697463809,
"kind": 1,
"tags": [
[
"e",
"679e060ec8f02abc7ea3c6f97c3b804b189a07a385436044762019c4dbaaef4a",
"",
"root"
],
[
"e",
"90cede71705d19fb0a446aafe026ea3d111c754ddbd482b09adc2a12a98f1de5",
"wss://nos.lol/",
"reply"
],
[
"p",
"0b963191ab21680a63307aedb50fd7b01392c9c6bef79cd0ceb6748afc5e7ffd"
]
],
"content": "So, here is the short-notes I made. Usually, I go from short notes -\u003e concept document -\u003e PoC code -\u003e mini documentation -\u003e implementation -\u003e documentation completion.\n\n- dropstr is a read-only relay.\n- 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)\n- 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\".\n- 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.\n- 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.\n- 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.\n- Users may query relays or dropstr instances directly for files with standard relay queries.\n\nWhat I haven't figured out:\n- Chunking (related to the idea above)\n- Privacy\n- Which kinds can be re-used, which ones can not",
"sig": "6a7254efa0bd1f2b53f6912d9f1472e87b550fb25bc6817976d54a0d0fb1f2e3f22165a42d52fb3c27eb596e741fd047ae0fe7b825a7599b187f5cbb39c72db4"
}