Here it is.
https://wikistr.com/nkbip-04*dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319
Discussion
Here is the njump version, if your wiki doesn't do Asciidoc.
Very odd I was just thinking something similar
Yes, @Beave is on us to go ahead and expand it with public and private/encrypted options, but I want to check the basic scaffolding, first.
It's an interesting concept because you can, of course, share these virtual drives with other npubs, copy or fork drives, etc. And because you can replace everything in the scaffold, you can move events around, add-or-remove events, etc.
Should be nostr:npub1q6ya7kz84rfnw6yjmg5kyttuplwpauv43a9ug3cajztx4g0v48eqhtt3sh , sorry. Typo.
Notes starting off as a flat hierarchy, where they can be organized by tags and unique ids, and then imposing a tree hierarchy for specific contexts,
AND then you can distribute the files/text across relays and servers. One can always worry about larger files, but if you're just working with text (as many file are- code, notes, collaborative docs) you really can go far. Anything requiring larger files just points to a server location.
nostr:nprofile1qqsza748zkamgmw4he4hm2xhwqpxd5gkwju38wqh3twmtshx8kv8xvgpramhxw309u6rxdpsd4skjm3wv36kx6mydeejummjvuargwp58qhsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hsv0qvag what do you think? I know you are working on distributed file storage.
Hard to talk about specifics from this context, but I would say insure that the file storage expectations are set up to work well with content-addressable data.
We've only been thinking of git blobs and blossom objects, so far.. Did you have something else in mind?
I guess what I had in mind was "arbitrary data" lol. Like if it's content addressable and the remote source is still alive, whatever may be at that hash is what the data for that "file" is.
I would think this would allow for being backend-agnostic. As long as there are bytes to be received from that address, bytes ye will get.
But I am pretty green on your whole system here so there might be plenty of reasons that wouldn't work? (MIME types come to mind immediately)
Yeah, that's what we were also thinking. Anything addressable could be included, really.
30040/41 contain a MIME-Type tag, but we just use that to guide rendering.
Grateful, for any constructive feedback, including suggestions on a different method for performing something similar.
Then maybe you need to see if the versions match so you need to write the version somewhere
Versions have an eventID. We can compare that and fallback on the `a` tag, otherwise, and display an info.
Versioning could be handled by the metadata event nostr:npub1ecdlntvjzexlyfale2egzvvncc8tgqsaxkl5hw7xlgjv2cxs705s9qs735 suggested 🤔
What is being versioned here? The entire tree structure?
Individual events in the tree, I think.
Can't relays choose to version them (or not)? Histories is outside of the scope of this NEP.
Yeah I agree it's outside scope. But if we wanted to add versioning, I think metadata would be the way to do it.
The background story is that I was supposed to write a story for an #Alexandria grid-view of the 30040 indexes and immediately saw a fileserver explorer in my head.
From the article:
"The `a` tags MUST be an unordered list of root 30040 index events."
A couple of notes:
1. The diagram shows a symlink connected to the drive event. How do we make symlinks discoverable for a client trying to browse a drive? It might be better for the drive to reference the symlink, and then the symlink references a "leaf" event in the filetree.
2. This specification says "unordered" list. Does this mean the client can render the child events in any order it desires? That differs from the behavior defined for 30040 events, so we should make sure the expectation is perfectly clear.
3. To use the Drive analogy, a typical drive would only have one root (e.g., `/` on Linux, or `C:\` on Windows). Is the 30043 considered to be the root of the filetree, or is it the flag that identifies the root? If that's the case, the root is the 30040, and each drive should have only one root.
I suppose, for symlinks, a client could discover them by requesting kind 30044 events containing an `a` tag pointing to the drive's root 30043 event.
I wonder if this kind of lookup by tag value is faster, slower, or the same speed as a lookup from a known event to one of its children? The relay devs would likely know.
tag lookups are as fast as all the others in a filter except the search field
good quality key/value stores maintain sort order in the blocks of the data once it has done a compaction pass, so it really is just finding the start point and simple iteration
i haven't thought about the implications of the tree structure of these 30040/1 events though, you should maybe read up a little on filesystem architecture theory to help evaluate what ways you can do things... filesystems are not quite the same as key/value stores, similar, but a filesystem can be highly branched where a key value store is like a (mostly) sorted index
I said it in another comment, but if the filesystem must be unix-like, we could only have one root.
Unrelated to my previous comment; possible suggestions to complete this proposal:
- Permissions must be handled (read, write, not execute since this is mainly for storage)
- information node structures for all the metadata (also related to permissions)
Yes, permissions are missing.
I don't understand the second point.
I think, at least for the first draft, it will be a read-only drive for everyone except the user who creates it. Handling write permissions would require some way of delegating event signing or deferring original events signed by one user to a replacement signed by another user, which means the event is constantly changing ownership/authorship.
What kind of information would it be useful to have on this distributed filesystem concept? It doesn't need to exactly mirror Unix. Should we have a metadata event that contains relay hints, for instance?
Couldn't metadata be in the drive event, analog to 30040s?
Potentially. Just throw a bunch of tags on there.
Though that wouldn't work if we wanted to tie metadata to each level of the file tree.
Well a file has a path which describes the traversal to reach the desired leaf. So it contains a pointer to the root, which could be fetched for metadata. So as long as there is enough information to find the root, then you shouldn't have any trouble fetching metadata from a child node.
It's turning into too many separate events, IMO. Complexity x² with each additional event.
1) If the drive contains a reference to the symlink, rather than the other way around, we should maybe just skip the symlink. Otherwise, there's redundancy and you would have to constantly change the drive, anytime a symlink is changed. The size of the drive is then limited by length of drive event, as well. You would have a max number of syms.
2) There doesn't seem to be a purpose to a predefined order, so I wanted to make that explicit. But maybe we should make it ordered, to match. Devs can always choose to ignore the order. Changed it.
3. 30043 is the drive and the root. I didn't want to overload 30040s with root attributes and functions.
Points 2 and 3 make sense.
Given nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku's comments on search efficiency, I think symlinks as currently defined will work well. Clients will need to discover symlinks by searching for tags, but that's not hard to do.
Can symlinks reference something other than a 30040? The way they are currently defined, we can only create symlinks to directories. What if I want to create a symlink to a particular file? Can I use an `e` tag to point to an arbitrary event?
Okay, update symlinks to add the context-level and allow for targeting non-30040 events.
nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn nostr:npub1636uujeewag8zv8593lcvdrwlymgqre6uax4anuq3y5qehqey05sl8qpl4
One 30041 can then be found in multiple places. I would like a way to share or link to that 30041 event with its context, like it’s nearest 30040, since pointing to the event itself won’t give enough info, but sharing the 30040 isn’t precise enough in this case.
Yeah, the possibility of filepaths.
Like Drive/30040/30040/30041 ?
Filepaths would get very long if we used the hex IDs or bech32 encodings. Since these are all parameterized replaceable events, we could use d tags for each step in the path.
If the end event isn't a 30041, we'd have to use a hex ID or URL or something like that.
I don't get it, too much talk about 30042 and 30041 events and "a" tags without any explanation of what it actually does or how its actually used...
I tried reading NKBIP-01 but I still don't understand how its supposed to be used
nostr:naddr1qvzqqqrcvgpzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcqpphxkcnfwqknqvg9xm7pr
👋 requesting a left curve product person translation
Its ultimately about organization of the events.
You can listen to albums in their linear order, or you can create playlists that explore multiple artists and albums. You can customize how you want the information to be organized.
Example: Suppose you want to replace a transmission for your car, but its hard to navigate and understand the several manuals that discuss replacing the transmission. With the event kinds we have, you would be able to navigate the manuals more easily to find the specific pages that discuss transmissions and find the one that you understand the best.
If you look at the feed on next-alexandria.gitcitadel.edu , you'll find everything organized like regular books and articles - closed, linear and isolated. Great for reading as we normally do.
When you click on the 'visualize' tab, you'll see something similar to an Obsidian knowledge graph, where ideas are scattered around.
In later versions, the individual events will have their own networks.
So again, these event kinds are helpful for data organization, and for future customization to create knowledge graphs and find ideas, books, aricles, etc, that are related to one another.
Kind 30041 is basically a bunch of scattered events that you can search through beyond a single book. Like regular text search of kind 1.
On the other hand, kind 30040 creates the structure of a book for regular reading.
The address is https://next-alexandria.gitcitadel.eu .
Just go there, click on the publications, read the publications, look at the events on njump. That's how you understand it. The spec is just for people who want to implement the same thing.