Split out the gateway project into it's own repo

[olizilla]

The IPFS Gateway Racing Gateway™️ worker in /packages/gateway isn't coupled to nft.storage and would make more sense as a seperate repo. I'd put it under the web3-storage org as it's not NFT specific code either.

mono-repos are great for managing interdependent puzzle pieces where edits to one often require edits to the other (e.g. api and api-client), but where a thing is seperate, keeping it in it's own repo can help avoid un-intended cross-dependencies appearing, or just dependenncy bloat... where a dev has to install and update many packages for many projects that they dont need to use to work on the main thing.

[olizilla]

@vasco-santos why do we track record the winning gateway for every CID in a durable object? Where do we use that data?
https://github.com/nftstorage/nft.storage/blob/main/packages/gateway/src/durable-objects/cids.js

[vasco-santos]

I'd put it under the web3-storage org as it's not NFT specific code either.

We have talked before about specific logic for NFTs on top of the gateway. We still need to figure out how to have a core version that we can use for everything else.

Anyway, I agree that we should move out of the monorepo. There will be new repos for the gateway, and I will look into how to structure it.

why do we track record the winning gateway for every CID in a durable object?

It is not winning gateway, but all gateways that could previously resolve a given CID. We don't use this information yet, but this opens lot's of opportunities for us:

• easily debug if a given CID was ever successfully fetched and from where (we will likely want a protected route for this)
• create "badge like" check if CID is available