Catching up on answers: > How hard is it to allow the user to specify which fields he wants in the response? Pretty easy, but like all things we prioritize fe

Catching up on answers: > How hard is it to allow the user to specify which fields he wants in the response? Pretty easy, but like all things we prioritize features based on customer requests. Seriously, you could probably game it by creating 20 different gmail addresses and emailing us once every three days from a new email address requesting the same feature. :-) If we hear from something like 20 different customers the same request we prioritize it higher and get it done. The OTHER way is if a "potentially large" customer approaches us and says they require some feature or they cannot integrate or won't use B2. I won't name the customer for privacy reasons, but we added the ability to put the SHA1 at the END of the upload instead of at the start in the HTTP headers because one "important" customer required it. It also makes sense, the headers come FIRST and some streaming applications don't have the SHA1 until all the data streams through them, thus at the end of the stream. > redundant data in the response can cost YOU a lot Much to my surprise (totally being honest), bandwidth only costs Backblaze about 2% or 3% of our total operating budget (including salaries and datacenter). Modern bandwidth is CHEAP! But even more interesting is that most of our Online Backup customers and B2 customers pretty much only UPLOAD data, but we are forced to purchase symmetric bandwidth (same upload as download). So hilariously enough, outbound bandwidth is utterly free to us until it comes up to match the inbound bandwidth. Free. I've even tried to come up with a scheme where we make it free to our customers up until the moment we actually have to increase our capacity to support outbound, but I can't figure out a scheme to make that happen. So we are pricing it for the situation when we exceed the "shadow", even though it is nowhere near (and probably never will) exceed the shadow. > please answer my other question about the authorize() token headache I looked back and found one question you asked about 24 hours vs weeks vs forever. If that is the question, the 24 hours is a "guideline" because so many customers kept asking what to expect so we made up a number. In reality, you have to follow the protocol which is: if a call is ever rejected for whatever reason with a "expired_auth_token" or "bad_auth_token" then your code should re-authorize. It's source code that you have to write and it doesn't matter how often it is triggered, after you write it (correctly) then it will always occur when it needs to occur, and never occur when it doesn't need to occur. To give you an insight as to why, if we happen to reboot a particular server (or it crashes, or the power supply dies), then all the auth codes will be incorrect and all currently connected customers that used that authentication server need to re-authorize which will come from one of the OTHER authentication servers. We do weekly code updates on Thursdays at 2pm-ish so if you get an authentication token on Friday it will probably work for 6 days, but if you get one Thursday morning it might fail once in the middle of the day. This is all about cost reduction for Backblaze - we simply don't purchase ANY high end load balancers, it is all cheap computers that are expected to fail and break, but because there are hundreds (or thousands of them), even if half of them have lost power or died there are still plenty up and running (now we have some in a different datacenter!) to respond to your software's requests. We don't own a single load balancer (like F5), and we pass the savings on to you. Unfortunately we also pass along a small amount of additional complexity. So it is really straight-forward code and you write it once and it just executes every time it needs to and never executes when it doesn't need to. Your code should not have ANY assumptions of time in it. Unfortunately it isn't something where you can write really bad software and just ignore it, you MUST handle the return value EVERY time it is returned, whenever one of our authentication servers has a hardware failure (which is at unknown times) or whenever we restart Apache Tomcat on the authentication servers (Thursdays at 2:15pm-ish-kinda).