[tahoe-dev] AES-256 is looking worse

[Zooko Wilcox-O'Hearn]

On Friday,2009-07-31, at 11:20 , Brian Warner wrote:

> It would probably come in the form of a new filecap format  
> ("URI:CHK2"?) which is defined to either contain an algorithm field  
> (URI:CHK2:AES256: or URI:CHK2:XSALSA20:), or which just always uses  
> the new algorithm. New uploads would use the new format, but  
> existing files in both formats would continue to be readable. Maybe  
> we'd provide a switch to let you intentionally upload files in the  
> old format (if you want your files to be readable by older  
> clients), but more likely not.

Ah, actually I had the opposite plan -- make it as easy as possible  
to deploy the new Tahoe-LAFS version while interoperating with users  
of older versions, which means make it very easy (probably even the  
default) to produce the old-style caps.

I think by the time the new caps are ready (six months from now ?),  
Tahoe-LAFS will have substantial user bases with substantial amount  
of stored files, etc., and it will be very useful to be able to tell  
people "Upgrade to Tahoe-LAFS v2.0, and everything will continue to  
work, with no configuration or change in behavior on your part, and  
even though the other people on your grid are still using Tahoe-LAFS  
v1.6.".

I've been planning to write up a document about our compatibility  
plan for such upgrades.

Regardless of the details though, everyone reading this can not-worry  
about compatibility.  The current format is secure, functional,  
performs well and will be carefully supported for the forseeable  
future.  When we introduce new data formats or other changes, we will  
be sure that it is easy to upgrade without requiring a lot of effort  
on your part and without requiring everyone that you work with to  
upgrade on the same day.  We've already done this a few times with  
Tahoe-LAFS, and you haven't noticed.  ;-)

Regards,

Zooko