Do a Nostr client that saves each event as an individual file. Notifications is just a folder, sort by date and get your feed. Each feed is a folder. File thumbnail renders and previews the event. If the posts has images/media, cache those images inside the .media of each folder. Symbolic links everywhere. Then each event kind could open in a different preview client.
It's Nostr's own "file" explorer.
Login to reply
Replies (16)
I think there's some very potent brainstorming ahead. @Silberengel would be very interested, as she's written a nostr directory system spec
== Directory System Specification
[[NKBIP-04]], a NEP based upon [[NKBIP-01]]
This NIP defines the basic structure for building a directory system out of Nostr events, so that events can be organized as _files_ and _folders_. The basic structure consists of a drive event `kind:30042`, where the top-level directory shall be mounted, and any directory `kind:30045` events (similar to the index `kind:30040`, but with a different purpose) contained therein, that are the root folder-events in the drive. This creates a forward-tracing directory structure, which is the minimal implementation.
Kind 30041 is the default file kind and is defined in NKBIP-01, but any kind can be contained in a directory. Directories MAY be nested. All of these events are addressable and replaceable, and MUST contain an `d` tag.
A backward-tracing structure, with full directory functionality and optimal performance, can be created by adding:
* tracebacks: `kind:30043` event, which is related to a `kind:30045`, and contains the parent-directory link
* symlinks: `kind:30044` event, which is a symbolic link to a particular file or directory. Hard symbolic links are to `e` tagged events, and soft symbolic links are to `a` tagged events. The difference being that addressable events (those with `d` tags and 3xxxxx kind numbers) can be replaced, without breaking the link.
image::https://i.nostr.build/cJLZaqtqKiUlRcs4.png[diagram of Nostr filestystem events]
*Event Structure*
Drive event:
* The `a` tags MUST be an ordered list of root `30045` index events.
* The `content` field MUST be empty.
[source, json]
----
{
"kind": 30042,
"pubkey": "<drive-owner-pubkey>",
"tags": [
["d", "<drive-identifier>"],
["description", "<human readable description of the content of the drive>"],
["a", "<30045:pubkey:dtag>", "<relay hint>"],
["a", "<30045:pubkey:dtag>", "<relay hint>"],
["a", "<30045:pubkey:dtag>", "<relay hint>"],
["a", "<30045:pubkey:dtag>", "<relay hint>"],
],
"content": ""
}
----
Directory event:
* Contains `a` and/or `e` tags of the files and subdirectories contained therein
* The `content` field MUST be empty.
* The order is the default for the initial display, but MUST NOT be essential to any functionality, so that sorting the directory content doesn't break any use case.
[source, json]
----
{
"id": "<event_id>",
"pubkey": "<event_originator_pubkey>",
"created_at": 1725087283,
"kind": 30045,
"tags": [
["d", "<directory-identifier>"],
["a", "<kind:pubkey:dtag>", "<relay hint>", "<event id>"],
["a", "<kind:pubkey:dtag>", "<relay hint>", "<event id>"],
["e", "<original_event_id>", "<relay_url>", "<pubkey>"],
["a", "<30045:pubkey:dtag>", "<relay hint>", "<event id>"],
],
"sig": "<event_signature>"
}
----
Traceback event:
* The `a` tag MUST be a `30045` index event, to which the traceback is linked.
* The `A` tag MUST be a `30045` index event, which is the parent event of the linked index.
* The `content` field MUST be empty.
[source, json]
----
{
"kind": 30043,
"pubkey": "<drive-owner-pubkey>",
"tags": [
["d", "<traceback-identifier>"],
["a", "<30045:pubkey:dtag>", "<relay hint>", "link"],
["A", "<30045:pubkey:dtag>", "<relay hint>", "parent"],
],
"content": ""
}
----
Symlink event:
* The first `a` or `e` tag MUST be the event, that is the target of the symlink.
* The `A` tag MUST be the 30045, that contains the event context, and MAY be the same event as the first.
* The second `A` tag MUST be the `30042` drive event, that the symlink should begin at.
* The `content` field MUST be empty.
[source, json]
----
{
"kind": 30044,
"pubkey": "<drive-owner-pubkey>",
"tags": [
["d", "<symlink-identifier>"],
["a", "<30041:pubkey:dtag>", "<relay hint>", "target"],
["A", "<30045:pubkey:dtag>", "<relay hint>", "context"],
["A", "<30042:pubkey:dtag>", "<relay hint>", "drive"],
],
"content": ""
}
----
View quoted note →
This is different. There are no need for specs. All I want to see is the performance/ easy of use of a client that stores everything separately in disk, in the same way we do for images. And then users can see everything they want to keep or delete from a regular explorer.
Fair but my main point is Silberengel would likely be a good anchoring point for these ideas, spec or not.
What would I get if I told #shakespeare to actually create this?
No idea
Didn't @fiatjaf do that on nak? The filesystem relay thing.
Use copyparty as the explorer.
Try it π€·ββοΈ
Nobody uses it except @Constant
Who do you think came up with it in the first place
You can mount Nostr as a FUSE filesystem in NAK.
How would you work around platform limitations on number of file descriptors that can be open at once? Or the incredible amount of overhead that would require? Or the fact that symbolic links are not a thing on Windows?
IMO, a filesystem is not the right tool for the job, a database is.
An OS directory system is just a collection of hierarchical lists containing references to storage space.
What is the benefit of using the native one, rather than using one on a local relay, and the references pointing to events in the database? Performance?
Also, wouldn't that be a step backward? I thought OS are moving away from files and toward events...
@Vitor Pamplona como funciona o sistema de datas e horΓ‘rios nos posts do Nostr?
Eu sei que os usuΓ‘rios assinam as postagens pela chave privada e isso nΓ£o pode ser adulterado, mas e sobre a data e o horΓ‘rio?
Faz parte do mesmo, portanto nΓ£o pode ser alterado tbm