@User can you elaborate why it would be a problem?

I guess it depends on how you store things. But if you could have two S3 representations which only have one possible R2 representation, how are you going to pick which S3 version to choose?

It's wrong to think about it in terms of S3 representations or R2 representations. There's only R2. The S3 XML API is just one particularly wire protocol format used to communicate to R2. Internally, by default all operations would (likely NFC) normalize the keys before using them (unless you ask that we skip normalization). But note that every time you provide the key you'd have to be consistent because if you tell us to skip normalization & upload it in a different form than what we use for normalization, then it's going to be invisible unless other operations are told to skip unicode equivalence as well. Otherwise we're internally looking for a different key than what you told us to store. It's a footgun but one you have to opt into explicitly vs getting it for free (albeit in a slightly different way) in the existing object stores. The list operation would always see all objects regardless of encoding. For it unicode equivalence would only apply to the prefix.

In case the middle part is unclear, what I'm saying is if the developer does PutObject while explicitly opting into skipping unicode equivalence and uploads an object with key Ç. Then they do a GetObject for Ç, forgetting to opt out of unicode equivalence, the object won't be found. If they then do another PutObject for Ç or Ç (again forgetting to opt out of unicode equivalence) then GetObject will always work but you'll get different objects depending on whether you ask to skip unicode equivalence or not (and in the former it'll depend on the unicode encoding of the key you supply). Before the second put, list will return Ç, but after the second one list would return Ç and Ç (the result from list is always preserving of the encoding you asked us to store). I hope the above shows why it's silly to define the keys as unicode strings but then ignore the unicode equivalence issue. I'm also not saying we would implement the opt out. Just that doing unicode normalization by default doesn't preclude it.

For anyone playing along

Ç => 67, 204, 167
Ç => 195, 135

You can also observe the behavior when text editing. Because the former is a combining character, backspace will typically convert it back to C whereas the latter is the precomposed form and backspace treats it as one character. I'll also note. This doesn't solve ALL unicode issues application developers may have. For example, homographic attacks may still be relevant to your problem domain (e.g. https://en.wikipedia.org/wiki/IDN_homograph_attack which describes how browsers and registries tackle it for domain names).

I'm curious, if we are currently using S3, will it be easy to migrate from one service to another?

Oh yeah, take a look at the blog article: https://blog.cloudflare.com/introducing-r2-object-storage/

Built-in migration, among other features.

Basically it connects to your S3 bucket, then whenever you access files it lazily pulls them and migrates them to R2.

So then you only incur egress costs once.

Wow that's awesome!

Will there be something like a short-lived permission possibility? For example my server wants to give a user direct access to a directory or file for let's say 15min?

I'm not aware of any plans like that. You should be able to build something like that yourself via Workers though.

Not yet in the R2 beta, but curious if it is known whether or not I would be able to persist a durable object to R2 as part of the API of a durable object.

No. You can write a durable object though that just uses the R2 API instead of the DO storage API. That wouldn't really be that different I think.

Hi. I am using Workers to proxy S3 (Wasabi), will moving to R2 improve transfer speed or latency?

What is the reason behind proxying Wasabi

For caching and authentication. In order for to be cached by the client, the same URL must be used, and cookies must be used for authentication.

We have not measured the cache effect precisely, so perhaps a presigned S3 URL may be sufficient.

This is very interesting

We haven't profiled any other S3 providers so it's hard to say. Certainly R2 isn't in a particularly optimized form yet and there's a lot of improvements we'll be making to it. What is the latency/throughput you currently see from Workers to Wasabi?

I've uploaded 100 MiB of random data to Wasabi ap-northeast-1 (Tokyo) and created a Workers script that downloads it. The bucket can be accessed by both

https://s3.ap-northeast-1.wasabisys.com/

and a custom domain, with the custom domains proxied by Cloudflare's Free plan. In this case, I measured four patterns:

cf.cacheEverything

true or false, and direct access or custom domain.

The results are as follows. TTFB is the time taken for

await fetch()

, DL is the time taken for

await res.arrayBuffer()

, and Total is the sum of both. (I also checked cases where the HEAD method was used and cases where

await res.arrayBuffer()

was omitted, but these had no effect on TTFB.) * cacheEverything: false / cf proxied (custom domain): no

Colo: NRT / TTFB: 897ms / DL: 12563ms / Total: 13460ms

* cacheEverything: false / cf proxied (custom domain): yes

Colo: NRT / TTFB: 927ms / DL: 12889ms / Total: 13816ms

* cacheEverything: true / cf proxied (custom domain): no

Colo: NRT / TTFB: 9ms / DL: 379ms / Total: 388ms

* cacheEverything: true / cf proxied (custom domain): yes

Colo: NRT / TTFB: 942ms / DL: 12193ms / Total: 13135ms

(I don't know why, but it doesn't appear to be cached.) so the latency (ping) was about 900ms and throughput was about 64Mbps. I expect better performance than these (except cached one) when accessing R2 from Workers. (because they're in the same data center?)

I don't yet know what we're going to blog about with regards to the configuration of R2 but I can say that Workers and R2 are unlikely to run in the same data center (think of R2 more like Durable Objects than traditional edge compute). Cache is a separate layer to R2 so those numbers should be similar (albeit maybe caching would work more consistently with Workers bindings). FWIW I have seen better numbers from our currently unoptimized stack but we also currently have significantly less load than Wasabi. I don't know what performance will start to look like on a properly loaded system. Focusing on improving performance bottlenecks as we scale will definitely be a major theme during Open Beta and beyond.

Hey there, is there any way to see my place in line to access r2?

There's not really a "line", it's more based upon need and amount of use (right now it's mostly enterprises).

Can the R2 buckets be regionalized? This is for a use case where customer may want to make sure that their data does not leave Australia for example

> We plan on starting from automatic global distribution and adding back region-specific controls for when data has to be stored locally, as described above.

that's from the blog - hope it's from release, lots of our stuff can't leave the EEA