The other analogy that comes to mind is a DB index. Nostr events are like noSQL DB entries (sure, they can be stored in a structured DB, but that's an implementation detail). The kind 30045 directory is an index for other Nostr events.
A DB implementation could take advantage of such events to optimize retrieval of any event kind that is part of a structure.
nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj are you picking up what I'm putting down?
oooooooh.... right....
30040s are publication indexes
30045s are general event indexes
indexes are faster to sift through, than sifting through a loose pile of events.
And symlinks, right?
Symlinks tell you where in the pile to start looking.
symlinks are a bit complicated, there is hard and soft ones. they basically work like directories that point to a file. the "hard" part is really a logical hard in the sense that if you copy a hard link you don't copy it, just make a new pointer to it, and if you copy a soft link, you only copy the pointer... the main difference between them has to do with cd/pwd stuff. to be honest i don't even remember exactly, except that links to directories are always soft, and files can be soft or hard. maybe you can remind me the exact distinction.
symlinks/softlinks are redirects to another path
hardlinks reference the underlying inode and act like 2 separate files but with the same content always
a hardlink would be 2 directories pointing to the same file event
a softlink would contain a path to another file as a βredirectβ
hard links point to content and soft links (symlinks) point to filenames. So, theoretically, you could switch out the data beneath a filename, and the symlink would still be valid, but the hard link wouldn't.
But events have unique "filenames" (event ID), so the file being pointed to can't change and the softlink is always being pointed to the same data.
I think. Sorry, sort of complicated.
Okay, whatever Semi said is probably right-erer.
yeah, sounds right. so a soft link would need to be an `a` tag, with kind, pubkey and file identifier.
links to any other type of event would be like hard links, not symlinks.
Ah, right. I guess I'm just calling everything a symlink, but that distinction sounds right-erer.
I'm going to add that to the NKBIP-04.
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.
yeah, a tags, and d tags they refer to are a kind of virtual reference like a symlink. the rest of the namespace is just a flat one because there's a squillion possible "filenames" thanks to the sha256 hash.
"replaceable events" use the kind as a filename
"parameterized replaceable events" are actually the combination of a kind, pubkey and arbitrary unique identifier. this identifier can be re-pointed at anything
really symlink isn't the technical right word because event IDs are like ... the actual file, the data blob. replaceable events give you 10k "names" you can point at new things, and the 30k namespace gives you 10k namespaces you can put infinity names into.
I decided to stick with symlink, cuz it sounds cool, but I differentiated harder and softer ones.
symlink means soft link
hard links are actually not a real concept in the FS
it is basically 2 different file entries pointing to the same data, say the same file event
it's a kinda artificial distinction but the filesystem behaves differently in that it treats soft links like some kind of file in itself, where the hard links ARE the file itself, but deleting it doesn't affect the other reference, writing it does.
if an event has a d tag on it, and you make two events that point at it with an a tag, then that's really just like a hard link... IF the "file" is a replaceable event, so the reference to it is not to the event ID but to the kind/pubkey/identifier
the analogy breaks down at this point
Yeah, it means symbolic link, but it always refers to soft links. But I lumped the hard link into the same event, as we have the ability to list either e (hard) or a (soft) tags.
Maybe I need a different name, but symlink sounds cool, and this whole topic is incredibly dull and nerdy, and I want to be cool.
yeah, the distinction is that events are immutable, that's the hardest part of it. d tags give you a handle to point a tags at so then you have a kind of mutability. the relay is supposed to recognise this and return the newest (or even delete old versions) when it gets an event with a d tag on it.
with symlinks you can swap the directory/file at the same path with another and itβd work
not with hardlinks, it would point to the old data if you rename/swapped
That is exactly what I meant when I said Iβm going to put a stack machine in your relay.
Not exactly, but what you can do is ask the relay βHey, get this event, then find this entry, then retrieve that and so onβ and it can do that and provide you the entire chain as proof.
NFDB will also support 4 retrieval modes:
- Metadata only (kind/created_at/pubkey/id)
- Metadata + content
- Metadata + tags
- Full event
The 1st one is extremely fast and does not incur any IA reads. The 3rd one could be made to not need IA
