Changes between Version 4 and Version 9 of Ticket #869


Ignore:
Timestamp:
2014-03-03T01:11:08Z (10 years ago)
Author:
daira
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #869

    • Property Keywords forward-compatibility backward-compatibility anti-censorship added

  • Ticket #869 – Description

    v4 v9  
    11source:docs/architecture.txt describes Tahoe as comprising three layers: '''key-value store''', '''filesystem''', and '''application'''.
    22
    3 Most of what makes Tahoe different from other systems is in the filesystem layer -- the layer that implements a cryptographic capability filesystem. The key-value store layer implements (a little bit more than) a Distributed Hash Table, which is a fairly well-understood primitive with many implementations. The Tahoe filesystem and applications could in principle run on a different DHT, and it would still behave like Tahoe -- with different (perhaps better, depending on the DHT) scalability, performance, and availability properties, but with confidentiality and integrity ensured by Tahoe without relying on the DHT severs.
     3Most of what makes Tahoe different from other systems is in the filesystem layer -- the layer that implements a cryptographic capability filesystem. The key-value store layer implements (a little bit more than) a Distributed Hash Table, which is a fairly well-understood primitive with many implementations. The Tahoe filesystem and applications could in principle run on a different DHT, and it would still behave like Tahoe -- with different (perhaps better, depending on the DHT) scalability, performance, and availability properties, but with confidentiality and integrity ensured by Tahoe without relying on the DHT servers.
    44
    55However, there are some obstacles to running the Tahoe filesystem layer on another DHT:
    6  * the code isn't strictly factored into layers (even though most code files belong mainly to one layer), so there isn't a narrow API between the key-value store and filesystem-related abstractions.
    7  * the communication with servers currently needs to be encrypted (independently of the share encryption), and other DHTs probably wouldn't support that.
    8  * because the filesystem has only been used with one key-value store layer up to now, it may make assumptions about that layer that haven't been clearly documented.
     6 * The code isn't strictly factored into layers (even though most code files belong mainly to one layer), so there isn't a narrow API between the key-value store and filesystem-related abstractions.
     7 * The communication with servers currently needs to be encrypted (independently of the share encryption), and other DHTs probably wouldn't support that.
     8 * Because the filesystem has only been used with one key-value store layer up to now, it may make assumptions about that layer that haven't been clearly documented.
    99
    1010Note that even if the Tahoe code was strictly layered, we should still expect there to be some significant effort to port Tahoe to a particular DHT. The DHT servers would probably have to run some Tahoe code in order to verify shares, for example.