The Manifest.json epic

[mmv08]

Background

Before we had a dedicated backend that would store a list of Safe Apps with all the app info, we needed to retrieve app information from somewhere, and we chose to use the manifest.json file that also happened to be a standard for PWAs. It required each Safe App to provide such a file with basic info (name, short_name, description, path to the icon). It's impossible to add a safe app without the manifest.json file.

What problems does manifest.json solve?

• Safe App compatibility check
• Providing app information
• Applicable only to the custom apps: App information updates (since we used to rely on the manifest.json file only, the developer has to update the file, and next time the app is fetched, the info is updated)

manifest.json problems

Not following the standard

• We introduced properties that are not part of the standard but have their analogues in the standard For example, non-standard iconPath could be replaced by a standardized icons array
• By the standard, the manifest is served from the root website level, but we fetch it relative to the URL For URL https://company.xyz/app it would fetch the manifest from https://company.xyz/app/manifest.json, but according to the standard, it should be https://company.xyz/manifest.json The problem is that if we imagine each app is safe-compatible by default without developers even knowing it, the chances that they have standardized properties in the manifest.json file are way higher than custom ones.

With the addition of safe-config-service, it's not clear if we should require manifest.json for default apps

Currently, the interface doesn't need a manifest.json file for apps that are already on the app list

dApp developers require features that are part of the standard

Few developers asked us to support the start_url property to trigger custom flows and analytics purposes. https://github.com/gnosis/safe-react/issues/2404

Inefficiency of dApp Safe App compatibility check

When you load a custom app in the interface, we check the app's validity by fetching the manifest.json file. It works because we introduced our custom properties (iconPath), and thus chances are very low that somebody adds them to their manifest.json if they're not a Safe App

It's yet another step to make a dApp safe-compatible

Theoretically, the app name, description, and logo are already encoded in the index.html file, and we can get it from there. This would make it easier to turn dApp into the safe app

Possible solutions

None of the solutions would solve everything, and some of them would solve only one specific problem, I more wanted to outline possible directions

Continue supporting manifest.json and follow the standard (partly)

I guess we don't want to be compatible with each property, but at least ones that are requested and we're already using

Introduce a separate file like safe_app_manifest.json

This means that we don't have to follow other standards, but still, one would have to add it to be safe app compatible, but this way if the app has such a file, we can be 99% sure it's safe app compatible

Fetch app info from the index.html

It could be tricky to implement on the client-side because of CORS and hard to check safe app compatibility

Allow loading dApps without a manifest.json

Show a message "We couldn't verify safe app compatibility on our end. Do you want to load it anyway?"

It would be awesome to hear your thoughts and vision for the safe app onboarding :)

[groninge01]

Hey @mmv08,

See here too.

TLDR: (in the near future) we will be building 2 apps from the same repo. They should then also be addable as 2 separate Safe apps with appUrls pointing to https://balancer.fi/pools and https://beets.fi/pools.

But because it's the same repo it will be the same static manifest.json. Now we can dynamically generate 2 different manifests using nextjs but then the name will be manifest.webmanifest.

But the Safe app only looks for appUrl + '/manifest.json'. And it also only looks at that url for any icons.

So I proposed this change. This will retrieve the url to the manifest file from the page at the appUrl. And it will also use the icon src paths given by the manifest so those can just stay in one place.

Let me know what you think about this?