safe-global / safe-config-service Goto Github PK

The /safe-apps endpoint should include data about the provider if any

For improved compatibility between the data stored in the config service and the clients that will consume the theme payload (web, iOS, Android), we should remove the Alpha channel support from the color formats of theme.

Endpoints consumed by the clients should have the JSON keys in camel case. By having them camel case, it follows the formatting that we have in other services.

In addition to the current chain information, in order for the client gateway and the clients to use the services provided by the Safe Transaction Service, the transaction service url should also be returned:

{
   "chainId": <stringified-int>,
   ...
   "transactionService" : <url-string> // optional 
}

• Create project safe-config-service on dockerhub (Uxío)
• Configure environment variables DOCKER_USER and DOCKER_PASSWORD (Uxío)
• Configure deployment. Take a look on https://github.com/gnosis/safe-transaction-service
• Prepare deployment doc with @jpalvarezl

Frontend clients have a theming option for each L2 chain. This information should be stored and retrieved with /api/v1/chains so that clients can render the respective theme for each chain.

The following should be added to the /api/v1/chains endpoint.

Initial proposal:

{
  ...
  "theme": {
       "light": {
           "textColor": <hex-color-string>,
           "backgroundColor": <hex-color-string>
       },
       "dark": {
           "textColor": <hex-color-string>,
           "backgroundColor": <hex-color-string>
       }
   }
}

Update on the payload: #86 (comment)

In case the ENS registry is present on the Chain, then its address should be returned:

GET /api/v1/chains/

{
  ...
  "ensRegistryAddress": "<checksummed-address>" // optional
}

@gnosis/safe-android @gnosis/safe-ios @gnosis/safe-web

To provide more flexibility when setting up the ports for a given environment, we should not use static ports in docker-compose. Instead those ports should be extracted to the .env file.

Using the URL as a unique identifier for the safe-app is error prone as the same app can be represented in multiple forms (eg.: https://example.com, https://example.com/, https://example.com/?, https://example.com/# etc...

We should then generate a unique identifier to represent each app instead of relying on the uniqueness of the url.

GET /api/v1/safe-apps/

[
  {
    "id": <int>,
    ...
  }
]

The service should (optionally) include information about the provider of the application.

The provider information should have at least the following fields:

{
  "name" : <string>,
  "url": <string>
}

• Deployment
• Create superuser
• Load initial data
• Test on the clients

In order to avoid exposing service names when deploying the application we should use a socket to bind the connection between Nginx and the Gunicorn.

• The renderer in production should show the json payload without a browsable API

For some chains a fixed gas price can be used (instead of relying on a gas price oracle).

On the safe-react, the GasPrice can be either given with gasPrice | gasPriceOracle? or gasPrice? | gasPriceOracle:
https://github.com/gnosis/safe-react/blob/ae206843c86aa1663ca6db66d3662c1882d36991/src/config/networks/network.d.ts#L80-L89

Given this, if gasPrice is given then gasPriceOracle should be null and if gasPriceOracle is given then gasPrice should be null.

Open Questions

1. Is the gasPrice considered to be in gwei
2. Is it correct to assume that only one can be provided and not both?

cc/ @gnosis/safe-web

To improve the constraints with the chainId we should avoid using a CharField and use a numeric representation that can encapsulate a a big enough range to cover the existing chains.

In order to provide information for the clients whether a safe is "Up to date" we need to know which is the version of the master copy that, as a minimum, is recommended.

This information can change from chain to chain, therefore we would like to have a field that specifies the version in the ChainInfo object.

ChainInfo {
  "minMasterCopyVersion" : "<semver-str>"
}

Tagged versions should be published to Docker Hub. These images will then be published in the production environment.

networks currently represents chainId so it can be a source of confusion where networks can have a value of 1 (network_id of Ethereum and Ethereum Classic) but the application is only available in one of the chains (that share the same network_id)

The Provider field of a SafeApp is currently required for validation even though its contents can be null in the database. This field should be optional on the validation phase.

The chains returned by the /chains endpoint should allow the option to sort them by a relevance field (set manually)

ALLOWED_HOSTS and DEFAULT_RENDERER_CLASSES are both using list comprehensions which are not evaluated lazily. Instead they are evaluated when the image is built and those environment variables do not exist.

We can add an optional pre-commit hook so that Black runs on each commit: https://black.readthedocs.io/en/stable/version_control_integration.html

Since CORS headers are missing, resources from this application cannot be accessed by other domains

Add chain information to the model and admin. The endpoint will be available under /api/v1/chains.
Each chain should have the following data:

{
   "chainId": <stringified-int>, // stringified-int due to int size constraints
   "chainName": <string>, // optional
   "nativeCurrency": {
       "name": <string>, // optional
       "symbol": <string>,
       "decimals": <uint>,
   },
   "rpcUrl": <url-string>,
   "blockExplorerUrl": <url-string>
}

Optional fields are marked with // optional

⚠️ Note: this does not include parameters regarding client theme and gnosis/safe-client-gateway. The data represented here is only related with "core" chain data.

The cache should be invalidated on model updates (create, update, delete). This can be accomplished by storing the cache entry in a separate cache (due to the complexity of retrieving the correct cache key) and clearing that cache.

The endpoint /api/v1/safe-apps is currently under the v1 namespace and safe-apps endpoint name.

To align it better with the future endpoints the following should be changed:

• the namespace changes from v1 to safe-apps
• the endpoint name changes from safe-apps to list

This results in a reverse url resolution with safe-apps:list instead of v1:safe-apps

The endpoint GET /safe-apps returns a list of safe-apps that can be cached (eg.: 1h) due to the nature of the endpoint (frequency of updating the app list is low). Updating the list should invalidate the cache.

This endpoint should be used to check if the server is alive and ready to receive requests

Currently requests don't have a version set. This can be done for example with URLPathVersioning or NamespaceVersioning.

NamespaceVersioning seems to integrate quite well with drf-yasg

The currency logo should be returned for each native currency in GET /api/v1/chains/

"nativeCurrency": {
  ...
  "logoUrl" : <url-string>
}

The service should integrate with a Logging Middleware in order to follow the standard logging structure that https://github.com/gnosis/safe-transaction-service follows.

See Logging Middleware here: https://github.com/gnosis/safe-transaction-service/blob/ed0720ce238153e678d0e6df5d48707c7be99fdd/config/settings/base.py#L91

When the database is created and the service is running, we should offer the option/utility to bootstrap it with the default list of safe-apps.

Default database should contain the following data: https://github.com/gnosis/safe-apps-list/blob/development/public/gnosis-default.applist.json

We should be able to hide a safe-app from the admin interface easily without having to delete its entry. This would provide more flexibility in case there's any concern regarding a specific entry or to add the possibility of adding a new entry without revealing it right away in the endpoint.

Client should be able to use a gas price oracle that is associated with a specific chain. Given that, the oracle information and parameters should be retrieved with each chain.

{
  ...
  "gasPriceOracle": { // optional
       "url": <url-string>,
       "gasParameter": <string> // eg.: safeLow | average | fast
   }
}

Open Questions:

1. Do we require that added chains have a Gas Price Oracle?

Chains

• BSC: api.bscscan.com
• Arbitrum: uses the eth_gasPrice RPC method

Add pagination support to api/v1/chains

The current README goes through the instructions on how to setup the services via docker-compose

It should also guide developers on how to setup an environment where Django runs on the host Python environment.

In addition to the public transaction url returned for each chain, an internal one should be returned and should be only used by the client gateway.

GET /api/v1/chains/

[
  {
    ...
    "transactionService": <url>,
    "transactionServiceCluster": <url> // this should only be used by the client gateway and not exposed to the clients
  }
]

@gnosis/safe-services

In case the Unstoppable Domains registry is present on the Chain, then its address should be returned:

GET /api/v1/chains/

{
  ...
  "unstoppableDomainsRegistryAddress": "<checksummed-address>" // optional
}

Update 1 (payload changes): #125 (comment)

Update 2 (no changes required): #125 (comment)

@gnosis/safe-android @gnosis/safe-ios @gnosis/safe-web

• Add custom Admin models with list_display, display_filter (for example, by network), ordering and search_fields: https://docs.djangoproject.com/en/3.2/ref/contrib/admin/
• Use admin decorator https://docs.djangoproject.com/en/3.2/ref/contrib/admin/#the-register-decorator

• Do not use Docker for running tests and linter
• Cache dependencies
• Enable parallel workflows whenever possible

This is likely due to the rule:

https://github.com/gnosis/safe-config-service/blob/227df740327663368a191d2aa2f49aa59f28d132/.github/workflows/test.yml#L3

It should run on each new commit once and only once.

Something like https://safe-transaction.mainnet.gnosis.io/api/v1/about/ so we get information about the configuration (the not private one) and the version running

Instead of https://github.com/gnosis/safe-config-service/blob/main/src/safe_apps/tests/test_views.py#L49 use https://factoryboy.readthedocs.io/en/stable/orms.html#django

In order to make it easier to deploy and run the image, it should include the default entrypoint to the application

• Currently on the other services we are using isort. Configuration is here https://github.com/gnosis/safe-transaction-service/blob/master/setup.cfg
• I recently discovered black, but didn't configure it yet as it's breaking some formatting. Maybe for a new project we can try it.
• Use same flake8 configuration (if you think it's alright 😉 )

When running the application with Nginx as reverse-proxy, static files (such as Admin CSS) are not correctly collected and served