Nostr Web Client

Replying to

Silberengel

Here it is.

https://wikistr.com/nkbip-04*dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319

MichaelJ 10mo ago

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.

Reply to this note

Please Login to reply.

Discussion

MichaelJ 10mo ago

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.

Silberengel 10mo ago

nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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

Finrod Felagund 10mo ago

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)

Silberengel 10mo ago

Yes, permissions are missing.

I don't understand the second point.

MichaelJ 10mo ago

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.

MichaelJ 10mo ago

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?

Silberengel 10mo ago

Couldn't metadata be in the drive event, analog to 30040s?

MichaelJ 10mo ago

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.

Silberengel 10mo ago

In addition to the traceback, or instead of it and including the traceback as metadata?

MichaelJ 10mo ago

In addition to traceback.

Silberengel 10mo ago

I'm not going to tie two different events to a third event. Event spaghetti.

ChipTuner 10mo ago

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.

Silberengel 10mo ago

It's turning into too many separate events, IMO. Complexity x² with each additional event.

Silberengel 10mo ago

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.

MichaelJ 10mo ago

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.