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)

Reply to this note

Please Login to reply.

Discussion

Yes, permissions are missing.

I don't understand the second point.

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.

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?

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

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.

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

In addition to traceback.

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

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.

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