Nostr View

Silberengel @Laeserin - 3mo

undefined
undefined
undefined

semisol @semisol - 3mo

And when built on a proper scalable relay… it’s going to be amazing

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

I guess this doesn't make any sense, unless you realize that UNIX doesn't actually have any folders. It has directory files, which are files that list other files, including other directory files. I just made directory events (kind 30045) and virtual drives, for you to mount directories on (kind 30042). And tracebacks (kind 30043) and symlinks (kind 30044). And you can put any event into those events, and those are then Nostr "files". EVENTS = FILES That's all. It's not very exciting, but it means that you can have a file system on Nostr and I made a file explorer, to view that system. And you can drag notes from one directory to another, or copy them, or import them from a file or from your social feed. And you can export them as .html, .pdf, .md, or .adoc files. And you can open them and edit them, sort, filter, and search the file system, etc. I guess it was way hard to think up, but the shit I build is always way hard to think up and really useful, but about as exciting as watching paint dry because it's like... Stella, that's just another data structure. But I'm a data analyst. All I know are data structures.

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

You can zip and send entire drives, now, as a single file. Just export the drive to json, csv, or .zip. I made a button. And drives create a mount that is separate from your npub, and that anyone can use as a mount, if they can find it on a relay. Only you can alter that mount, but people can clone it. They don't have to clone all the events within it, only the drive event. It's a virtual, virtual drive. Virtual ++.

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

event directory

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

I actually originally put this on #Alexandria, using 30040s as folders, but it seemed sort of redundant with the ToC, and I need folders where the order of the content isn't essential. https://i.nostr.build/s6HGc2SHifGD20Fg.png And then I got to thinking about nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q and his notes, and it was like... where to put the notes, tho? Cuz like, if you hang the 30041s directly on the npub, then it's great because it's "my notes", right? And then you could go look at them from the note viewer. So, I built that. And then nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf was like, but what if he wants to use something other than 30041s to take notes with? And how does he organize the notes? Then we need 30040s, but then his folder of notes ends up on Alexandria, as if it were a publication. But publications are meant to be _curated_ and this is just "my notes", all lumped together in cyberspace. And what if he wants to share a folder with someone else? Then it's really stupid. He should be able to have n number of folders and share them, so the folders should originate from himself; they should be independent things, with only his signature on them. But how do you figure out the top folder? You have to mount the top folder on top of something, but we have no distinct hardware to mount on. So, let's mount on an event. So, that's where I'm at, now.

undefined
undefined
undefined

70122 - 3mo

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?

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

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.

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

And symlinks, right? Symlinks tell you where in the pile to start looking.

undefined
undefined
undefined

semisol @semisol - 3mo

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

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

Ah, I missed that point. I was thinking about how to setup the historization, when you posted it, so that's what my brain jumped to.

undefined
undefined
undefined

semisol @semisol - 3mo

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”

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

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.

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

Okay, whatever Semi said is probably right-erer.

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

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.

undefined
undefined
undefined

semisol @semisol - 3mo

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

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

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.

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

https://alexandria.gitcitadel.eu/publication?d=nkbip-04

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

I decided to stick with symlink, cuz it sounds cool, but I differentiated harder and softer ones.

undefined
undefined
undefined

semisol @semisol - 3mo

symlink means soft link

undefined
undefined
undefined

semisol @semisol - 3mo

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

undefined
undefined
undefined

Silberengel @Laeserin - 3mo

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.

undefined
undefined
undefined
Showing page 1 of 1 pages