describe alternate solution 'Use w3-filecoin Directly from nft.storag…

…e (without w3up)'

decisions/20240313-try-w3up.md

@@ -115,6 +115,20 @@ This project can't succeed without a sponsor from nft.storage and willingness to
 
 I don't know of any alternate solutions I can link to that provide a path to servicing nft.storage's web3 storage needs without relying on dagcargo. If you know of some, please add them here.
 
+### Use w3-filecoin Directly from nft.storage (without w3up)
+
+The subsystem of w3up that does filecoin dealmaking is called [w3-filecoin](https://github.com/web3-storage/specs/blob/main/w3-filecoin.md) and has an API that nft.storage could call directly (just like other parts of w3up call it directly).
+
+@vasco-santos proposed this in [api.nft.storage onboarding to w3filecoin](https://hackmd.io/0K9xlcQRTp6pLps1bffxHQ).
+
+@vasco-santos has weighed in on the tradeoffs of that proposal vs the decision documented here (emphasis added):
+
+> w3filecoin was designed for multiple storefronts, so w3up/others, and my idea was to not go through w3up to avoid mixing the data at that level. And this together with the separate aggregation process for both. The general sense though is that **using w3up makes more sense on a perspective on having nft.storage as a user of w3up in the long run**. But if the expectation we have is it to be 3 months, making it a client of w3filecoin, while continuing to write to old bucket and so on, would make more sense to me.
+>
+> But after talking with Alan, Hannah, Reid, we opted on the w3up lane, and that is why I say that it seems out of the table. **I generally agree with using w3up because it is simpler if we won't care about splitting aggregation + have nft.storage in the long run as a client of w3up**
+
+If we determine it is not desirable for nft.storage to use the entirety of w3up's normal functionality, we may still pursue this alternative solution.
+
 ## Implementation and Rollout Plan
 
 Prototype Happy path