You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: