Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unique identifiers for files and directories #482

Closed
4 tasks
Tracked by #501
icidasset opened this issue Feb 2, 2023 · 4 comments
Closed
4 tasks
Tracked by #501

Unique identifiers for files and directories #482

icidasset opened this issue Feb 2, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@icidasset
Copy link
Contributor

icidasset commented Feb 2, 2023

We have CIDs and other unique identifiers in WNFS that point to the following things:

  • Public content
  • Public file header (wrapper around content + metadata)
  • Private encrypted content
  • Private encrypted file header (wrapper around content + metadata)

It should be made clear to users that de-duplication is achieved automatically with WNFS when using the public file system. The private file system does not have that because each file is encrypted with a different key. https://talk.fission.codes/t/does-wnfs-deduplicate-content/4067

Questions to answer and problems to solve:

  • How do I get a unique name for my file or directory? Should fs.write() by default not overwrite a file?
  • How do I point to an exact version of a file or directory? How does this differ between the public and private side?
  • How do I make private content public and vice versa? What happens with the unique identifiers?
  • What does Webnative recommend to identify/link a file from another file? Example, a picture associated with a blog post.

The internal data structures should not be exposed. Instead, the interface should be easy to learn and be as helpful as possible to help people build various kinds of apps.

@icidasset icidasset added the enhancement New feature or request label Feb 2, 2023
@expede
Copy link
Member

expede commented Feb 2, 2023

These are good questions! Some quick thoughts below (with my usual disclaimer that I'm just exploring ideas here, not imposing what should happen with my CTO powers 😛)

Should fs.write() by default not overwrite a file?

Bash overwrites by default. The macOS Finder prompt the user if they want to overwrite or use a unique name.

To make this even harder to chose between: because WNFS is concurrent, you also have the option of making it a concurrent/conflicting write.

What happens with the unique identifiers?

If I'm understanding correctly, the unique content ID is intentionally lost when moving to the encrypted side. If it's later moved back to public, then it would have the same CID again.

What does Webnative recommend to identify/link a file from another file? Example, a picture associated with a blog post.

I had assumed that this would live in the metadata header, but would love to know if others have thoughts!

@icidasset
Copy link
Contributor Author

because WNFS is concurrent, you also have the option of making it a concurrent/conflicting write.

Good point. I'm starting to think we should not overwrite by default and be explicit, as we're leaning towards explicitness a bit more now in other areas of Webnative.

I had assumed that this would live in the metadata header

With the new rs-wnfs file system I think that's the way to go yeah. That said, couldn't hurt to think about some other patterns, as I'm sure there will be quite a few apps that have their own format (maybe they don't want to conform to one system, legacy reasons, etc)

@bgins
Copy link
Member

bgins commented Mar 8, 2023

I'm starting to think we should not overwrite by default and be explicit, as we're leaning towards explicitness a bit more now in other areas of Webnative.

To make this explicit, we would add an option to fs.write?

What happens when an overwrite is attempted but not permitted? Webnative throws an exception?

Bash overwrites by default. The macOS Finder prompt the user if they want to overwrite or use a unique name.

It might be useful to consider interactive vs non-interactive interfaces. The macOS Finder prompt has a user present to determine what to do. Bash might not.

Webnative is non-interactive. Are there other purely non-interactive systems that we could look at to see how they handle this?


Another consideration is whether overwrites are destructive or not. In our current implementation, we have the file.history API, which means overwrites aren't destructive. More of an append.

As a wild idea/alternative to making overwrites explicit, how about if fs.write returned an identifier for the previous version of the file? Or the file.history.list function for the file. It would keep the syntax of fs.write simpler and make it more convenient to reach back for previous versions of the file.

@icidasset
Copy link
Contributor Author

Addressed in #500 (see PR description)
Part of #501

How do I get a unique name for my file or directory? Should fs.write() by default not overwrite a file?

Mutations return a CID that can be used for a unique name or just use a UUID.
We've added fs.create() that adds suffix to the name if the file or directory already exists.

How do I point to an exact version of a file or directory? How does this differ between the public and private side?

A capsuleCID and contentCID are returned from a public mutation, which can be used with the read method. For the private side you get capsuleRef, which can also be used with read. You can also get these unique identifiers with their respective methods on the file system (ie. contentCID, etc).

How do I make private content public and vice versa? What happens with the unique identifiers?

You can now use the move method to move a file or directory from public to private and vice versa. Unique identifiers depend on the destination partition.

What does Webnative recommend to identify/link a file from another file? Example, a picture associated with a blog post.

Use paths or the unique identifiers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants