<div dir="ltr">One little typo and there goes anything resembling a reasonably professional layout :) Please ignore my last message, it was sent by accident when I slipped and hit the wrong combo of keys.<div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div><span style="line-height:1.5;font-size:13.1999998092651px">-------------------------------------------------------</span><br></div><div><br></div><div></div><div dir="ltr"><div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif">I just recently discovered Tahoe-LAFS and find it not only incredibly fascinating but also a refreshingly novel approach to distributed data stores.</div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif">One part of Tahoe-LAFS' design that I'm particularly curious about is why each file is encrypted in its entirety prior to "chunking" (my term). Wouldn't it make more sense to fragment/chunk the file <i>then</i> encrypt each fragment/chunk/segment? <span style="font-size:13.1999998092651px;line-height:17.9999980926514px">I can see a few possible benefits to this order of operation:</span></div></div></div><div dir="ltr"><div><div class="gmail_default"><ol style="font-size:13.1999998092651px;line-height:19.7999992370605px"><li><font face="arial, helvetica, sans-serif"><span style="font-size:13.1999998092651px;line-height:17.9999980926514px">In the case of file which is inherently linear (e.g. a large media file), the segments could be requested in order allowing the file to be accessed as it is retrieved. This would make it possible to, say, begin watching a large video file prior to the entire file being retrieved. It might also be possible to seek to a point in the file in question prior to the intervening segments being received. Such features would be useful in a VOD (Video On Demand) scenario.</span></font></li></ol></div></div></div><div dir="ltr"><div><div class="gmail_default"><ol style="font-size:13.1999998092651px;line-height:19.7999992370605px"><li>Another possibility that such a scheme would potentially allow for is each segment to be encrypted using a different key. Such feature may present issues with the "key-in-URL" nature of Tahoe-LAFS but I don't imagine such a detail is insurmountable.</li></ol><div><span style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif">I really appreciate everyone's time. I'm not exactly an expert when it comes to cutting edge cryptographically secure decentralized peer-to-peer distributed data stores that scale, though, it would appear that there are at least a few people working on this project who are.</span></div></div></div></div><div dir="ltr"><div><div class="gmail_default"><div><font face="arial, helvetica, sans-serif"><span style="font-size:13.1999998092651px;line-height:17.9999980926514px"><br></span></font></div><div><font face="arial, helvetica, sans-serif"><span style="font-size:13.1999998092651px;line-height:17.9999980926514px">Adam Hunt</span></font></div></div></div></div></div>