There is significant developer confusion regarding the current status of the Aquarius metadata cache and the recommended way to interact with Ocean Protocol on remote networks (e.g., Mainnet, Sepolia).
While trying to develop a dApp, I encountered the following issues:
- Unresponsive Aquarius URL: The public URL
https://v4.aquarius.oceanprotocol.com/ returns an unresponsive error.
- Outdated Documentation/Code: The official documentation, specifically the [old infrastructure doc](https://docs.oceanprotocol.com/developers/old-infrastructure), suggests a move away from the "Barge" setup. This is reinforced by a
barge commit that removes Aquarius from docker-compose files.
- Conflicting Information: Many code examples, such as those in the [ocean.js repo](https://github.com/oceanprotocol/ocean.js/blob/main/CodeExamples.md), still explicitly mention or require Aquarius URLs, creating a conflict.
Problem
When using ocean_lib or ocean.js to connect to a remote network (e.g., Sepolia), the get_config_dict function or similar logic points to an unresponsive local or old Aquarius URL, leading to an Invalid or unresponsive aquarius url error. This happens even for remote networks where a local instance is not required.
Expected Behavior
- The documentation and code examples should clearly reflect the current best practices for metadata discovery.
- The libraries should be configured to automatically use the correct subgraph or remote endpoint for a given network without requiring developers to manually provide local Aquarius URLs.
- If Aquarius is still a required part of the stack, a clear guide on its new URL or configuration method should be available.
Request
Could you please provide:
- Clarification on the current status of Aquarius. Is it meant to be run locally, or is it a fully managed service for each network?
- Updated code examples for
ocean.js and ocean.py that demonstrate how to correctly initialize the libraries for a remote network without relying on get_config_dict or an old, unresponsive Aquarius endpoint.
- A reference to the new infrastructure (e.g., the correct subgraph URLs) that should be used for production applications.
Thank you for your help!
There is significant developer confusion regarding the current status of the Aquarius metadata cache and the recommended way to interact with Ocean Protocol on remote networks (e.g., Mainnet, Sepolia).
While trying to develop a dApp, I encountered the following issues:
https://v4.aquarius.oceanprotocol.com/returns an unresponsive error.bargecommit that removes Aquarius fromdocker-composefiles.Problem
When using
ocean_liborocean.jsto connect to a remote network (e.g., Sepolia), theget_config_dictfunction or similar logic points to an unresponsive local or old Aquarius URL, leading to anInvalid or unresponsive aquarius urlerror. This happens even for remote networks where a local instance is not required.Expected Behavior
Request
Could you please provide:
ocean.jsandocean.pythat demonstrate how to correctly initialize the libraries for a remote network without relying onget_config_dictor an old, unresponsive Aquarius endpoint.Thank you for your help!