Nostr Web Client

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.

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.

You know, so we can mount files onto drives, instead of onto npubs. This is the thing.

Everything in Nostr is a primordial soup of event IDs, with only npubs being anchors people can latch onto in the Nostrverse. But, now, npubs can generate new anchors and toss them out, and anyone can hang onto them, without having to hang on to the npub, directly.

So, that makes two different anchors, that things can latch onto:

npubs and drives.

MichaelJ 6mo ago 💬 2

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 2

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.

semisol 6mo ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 2

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.

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 1

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.

semisol 6mo ago 💬 2

symlink means soft link

semisol 6mo ago 💬 1

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

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

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.

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

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.

semisol 6mo ago

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

semisol 6mo ago 💬 2

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

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.

MichaelJ 6mo ago

I'll be curious to see the API and how much it extends the core Nostr API.

Niel Liesmons 6mo ago 💬 1

To be clear on my actual needs (which might be simpler than what you describe, I don't know).

- Write Stuff

- Label Stuff

- Index Stuff together in a publication that I can share / publish

- Target Stuff to Communities (which are pubkeys and which can be private)

- Collab on Stuff

I personally don't need the in between "folder" thing.

Either I need Labels (categorization) or I need an Index (ordered, coherent whole).

This gives you an index to put lots of different stuff in, while you work on it, and then you can select items from the index to put them together into a publication. And the index can be flat and monolithic, like "My Notes" and you just throw everything into one big index/folder/directory, or they can be organized into multiple indexes on one level, or they can be nested, so that you can group similar things together.

Or, you can put them straight into a publication, but that already exists. And then it shows up in every curated publication feed, as if it were a coherent, curated document with a predetermined order.

I have hashtags and kind 1985 labels implemented. Other labeling could be added.

The drives have the visibility "public" (published to all relays you have access to) or "protected" (published to one relay and containing a "-" tag. A "private" visibility could be added, later, with encryption, but that makes collaboration more difficult and for now I'm just leaving events unsigned and saved to the local db (so that you can continue to edit them), and you have to sign-and-publish, to make them visible to someone not using your machine. So, there's a deliberate "send it out" step, that is separate from the "write it down" step. The way Obsidian Nostr plugins work, basically, but Nostr-native.

No multisig on the events, but you can add any event to any index, even if it isn't your event, and people can clone/fork your index and then edit that and submit a change back to you, to update yours.

It's more, than you asked for, but I was going to build it, anyway, so here it is.

You can also define multiple drives, and have one "public" and one "protected", and choose which one you share with whom.

I allow for categorization, grouping, a hierarchy, and differentiating visibility, but displaying this in a file explorer. Feels much more intuitive.

And I have a search, filters, and sorting, for all levels or for the entire explorer.

One event could be in multiple folders on different drives, so you could see where all you put one event.

And an event can literally be anything. This isn't only kind 30041. You could have a folder of your favorite emojis, or cool kind 20 images, or citation events to scientific journals or web pages, or something. That's why I went ahead and added the citations. Scientists and engineers like to keep track of things they've seen, elsewhere, or good AI prompts they've used, so that they can use those as references, later.

ben 6mo ago 💬 1

doesn’t nip94 already specify an event for files?

semisol 6mo ago 💬 1

yes it does