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

Eliminate the fileserver #2

Open
countvajhula opened this issue Jul 4, 2023 · 0 comments
Open

Eliminate the fileserver #2

countvajhula opened this issue Jul 4, 2023 · 0 comments

Comments

@countvajhula
Copy link
Collaborator

countvajhula commented Jul 4, 2023

Currently there are peers and there is a fileserver. The fileserver represents a single point of failure for the P2P filesystem and should be eliminated.

Options

  • When peers store files, they, as clients of the filesystem, could retain all the relevant metadata themselves
  • alternatively, clients could advertise the metadata for storage in a distributed data structure maintained across all peers using some agreement protocol (to be defined).
  • a third option, suggested in Zebra Striped Network File System, is to save the metadata as a file that is itself stored in the filesystem using some (highly-redundant) storage scheme, just like any other file stored in the filesystem

In the first option, the storage scheme on the client would be responsible for knowing which blocks are relevant and where they are stored, that is, something like the blocktree and the block book would be retained on each client, containing information about the specific files stored by them. This option is certainly the simpler of the two.

In the second option, any peer would be able to download any file (preserving the current behavior). It would also be more robust since the metadata being stored on a single client once again represents a single point of failure, albeit one that is in some respects a desirable thing. That is, naively, a client may prefer not to advertise where their personal information is stored and be the sole keepers of that information. Yet, the best of both worlds seems to be to preserve the robustness of this option while achieving privacy by a separate protocol such as encryption (#6 ).

The third option is very interesting and seems like a great way to achieve the goals of the second option 🤦

Let's do some variant of the third option, since it would support the user downloading their file from anywhere as long as they have the right credentials -- a more realistic usage scenario.

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

No branches or pull requests

1 participant