Distributed Gateways
This answers the question that if the gateway is a service within the object storage, can gateways be chained across object storage. Along the lines of the previous question, if the current object storage does not resolve the address for an object located in its storage pools, is it possible to distribute the query to another object storage. These kinds of questions imply that the resolver merely needs to forward the queries that it cannot answer to a default pre-registered outbound destination. In a distributed gateway, the queries can make sense simply out of the namespace-bucket-object hierarchy and say if a request belongs to it or not. If it does not, it simply forwards it to another object storage. This is somewhat different from the original notion that the address is something opaque to the user and does not have any interpretable part that can determine the site to which the object belongs.  The linked object storage does not even need to take time to search for an object within its store to see if it exists. It can merely translate the address to know if it belongs to it with the help of a registry. This shallow lookup means a request can be forwarded faster to another linked object storage and ultimately to where it may be guaranteed to be found. The Linked Storage has no criteria for the object store to be similar and as long as the forwarding logic is enabled, any implementation can exist in each of the storage for translation, lookup and return. This could have been completely mitigated if the opaque addresses were hashes and the destination object storage was determined based on a hash table.  Whether we use routing tables or a static hash table, the networking over the object storage can be its own layer facilitating request resolution at different object storage.