Nostr View

Silberengel @Silberengel - 4d

A Nostr fileserver structure modeled on UNIX. nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcqyz2rgdh8898mcqxnktg9d3fmnswsjf7rpfzq8p79rkk2k8a8elx9gfhfjxn

1
0
3

Silberengel @Silberengel - 4d

Yes, this is a crazy, wild, out-there idea, that might not even work.

0
0
3

Silberengel @Silberengel - 4d

No, we want to add blossom objects to the folders.

0
0
3

Silberengel @Silberengel - 4d

Nope.

0
0
3

Silberengel @Silberengel - 3d

Do we need to mount a virtual drive? Would the mount be a relay?

0
0
3

Silberengel @Silberengel - 3d

A, I get what you mean, as UNIX only has one directory tree and this has one for each drive, like on Windows. Except that it doesn't, since the tree is independent of the drive and you could have n number of drives with the same tree. The drive can tell you what the first dir in it's tree is, but the dir can't tell you what it's drive is.

1
0
3

Silberengel @Silberengel - 3d

I think we're actually "mounting" a "drive" onto a "kind 0".

1
0
3

Silberengel @Silberengel - 3d

The starting point is the npub and they create drives and then say what is the first 30040 in that drive's tree.

1
0
3

mleku @mleku - 3d

it's a soft link, in any case, if that tree exists elsewhere on the tree hard links are when it's the same file appearing in multiple trees, so that's only relevant for the files - 30041 right? 30040 is equivalent to a directory

1
0
3

Silberengel @Silberengel - 3d

Nostr directories can actually appear on multiple trees because they can be cloned.

1
0
3

mleku @mleku - 3d

yes but a copy can have a fork in its change history also and there really isn't such a thing as a hard link in a system like this, everything is a reference, or a map, and maps can point to maps to restructure the lower (upper?) parts of the tree oh yeah, and yes you can do this with soft links too, there can be loops in the graph, so any walker algorithms you make need to be able to resolve and break out of them

3
0
3

mleku @mleku - 3d

but yes, if another directory points to another directory it copies the state of its descendants to change the directory you need to step up the tree to change the reference to the directory i'm not really bothered to formulate a theory about all this but i bet you will, godspeed!

1
1
3

Silberengel @Silberengel - 3d

Yeah, doomloops will be an issue.

1
0
3

Silberengel @Silberengel - 3d

When we have more concrete stories, we'll be doing internal review (with you). This is just the spec to ensure interop, but doesn't contain implementation details.

0
0
3

mleku @mleku - 3d

there is loop resolution methods... but they are always problematic when you allow symbolic links, and they are necessary for any kind of graph structured data i'm not by any means an expert on tree and graph algorithms but this expertise is going to be required and the specifications should at least minimally point at a reference implementation of a walker that knows how to avoid it nostr:nprofile1qyt8wumn8ghj7mtvv44h2tnjv4skc7fwd3hkctcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0v96hg6pwdehhxarjxyhxxmmd9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uq3xamnwvaz7tmrds6zuarwd9uzuer9wchsqg8ks058qd0h4485fc9e3naaj5m7zez44ykd8r80cn9nrkm42l677gtmgnh8 recently has been doing a lot of work with social graphs and the same problems exist, and part of the solution he applies is random walks, but specifically locating circles is a step further, the random walk is just one way to avoid them, and there is also the easy one step loops those can easily be avoided

0
0
3

mleku @mleku - 3d

yeah, the great thing about this is it has built in deduplication thanks to using a hash reference scheme you may possibly want to include a scheme for creating edit histories though, since they are replaceable, each event should have its own ID plus a second id to refer to the edit tree it is part of

1
1
3

mleku @mleku - 3d

hm well, yeah, see, the thing is that 30041s you may not want to actually be replaceable they should have history, the 30040 definitely better to have them replaceable since they are like the scaffold

1
1
3

mleku @mleku - 3d

i think i am making a mistake of domain overlaps i'm gonna suggest that client side there should be an edit history kept in a git or similar structure but the actual content on the relay should be just the tips

1
1
3

Silberengel @Silberengel - 3d

Is that the versioning metadata they were talking about?

1
0
3

mleku @mleku - 3d

oh, yeah, now that's a separate thing... and it would require a separate kind, also would need to use those d tags and such and a tags to find them the thing is that this obviates the replaceable thing this is partly why i defined in the #realy protocol that instead of making kinds bound to replaceabliity, that this operation was part of the publish API, - either it's new (and can't replace), or it replaces - with the id specified, or it should not be stored - ephemeral, is all a separate version of the client-side EVENT envelope in nostr you may run into trouble because you locked these events into the most permissive form of replaceable... i know that the spec has additional metadata , but actual replacement needs to be an intentional action anyway lol i'm still stuck on this damn unbounded http upload problem, i just learned about a method on http.Request i didn't see anywhere in my searches that relates to faking the "close" of the stream

1
1
3

mleku @mleku - 3d

yeah, thinking about this, the top level of the hierarchy should be done with replaceables possibly the branches can stay as replaceable but the leaves should not be replaceable

0
1
3
Showing page 1 of 1 pages