Show both estuary and dweb retrieval urls

[neelvirdy]

~Replaces any link that is intended to point to estuary-hosted content with the estuary gw instead of dweb.~ Shows both gateway links throughout the UI, labeled as "Estuary retrieval url" and "Dweb retrieval url". The estuary gw defers to dweb if the cid is not actively pinned by estuary or has been offloaded, so it is safe to point to the estuary gw as long as estuary API nodes are up. Dweb is still provided as a back up option until we decide to only show the estuary url.

Note: For pinned directory nodes, users will get a much faster response on average through the estuary url but a much less dressed-up gateway UI, until we update our gateway rendering.

• https://api.estuary.tech/gw/ipfs/bafybeidj7c2e3daplalccukbps4eze7473gyshspev76xi4sjfmfkuaofe/
• https://dweb.link/ipfs/bafybeidj7c2e3daplalccukbps4eze7473gyshspev76xi4sjfmfkuaofe

---

[alvin-reyes]

I say we should put both links (dweb and our gateway) for now until we stablize the gateway. There are instances where the gateway can't serve some old data.

Once we have the infra stable, we can remove the dweb link.

[neelvirdy]

I say we should put both links (dweb and our gateway) for now until we stablize the gateway. There are instances where the gateway can't serve some old data.

Once we have the infra stable, we can remove the dweb link.

Is the main concern estuary uptime, or the gateway implementation itself? On uptime - can we add a DNS failover to hit dweb.link if api.estuary.tech/gw is not responding?

On gateway implementation - is there a case where estuary thinks it has data available (according to db) but is still unable to serve it correctly? If so and we can't clean it up quickly, then agreed we should put both links. Otherwise it would seem to me like we could fully switch to our gateway if the DNS failover is possible.

[alvin-reyes]

I say we should put both links (dweb and our gateway) for now until we stablize the gateway. There are instances where the gateway can't serve some old data. Once we have the infra stable, we can remove the dweb link.

Is the main concern estuary uptime, or the gateway implementation itself? On uptime - can we add a DNS failover to hit dweb.link if api.estuary.tech/gw is not responding?

On gateway implementation - is there a case where estuary thinks it has data available (according to db) but is still unable to serve it correctly? If so and we can't clean it up quickly, then agreed we should put both links. Otherwise it would seem to me like we could fully switch to our gateway if the DNS failover is possible.

Right now, there is a case for that because of the corrupted lmdb. There are CIDs that are available and some that are not. Until we fix this (or AR has fully indexed all CIDs), we shouldn't solely use our gw. Add both dweb and the gw for now so that our users have options.

[neelvirdy]

gonna push a change soon to make formatting utils and just call them, i.e. U.formatEstuaryRetrievalUrl(cid) and U.formatDwebRetrievalUrl(cid)

[neelvirdy]

removed waiting condition since dweb link is also still available now