We are proposing a specification for a format in which æpps provide metadata to wallets/æpps browsers/æpps listing services.
The proposal is in very early draft. We would like to first get any community feedback on adopting a modified version of the webmanifest format vs specifying an aeppmanifest format.
An extension of this proposal will be added later to address the internationalization of the metadata which aepps need to provide.
My 2 cents, here is the format we currently use to provide info about connected applications.
Example for the ThorBlock app {"name": "ThorBlock", "description":"The first communal funding turnkey solution on the VechainThor Blockchain", "url": "https://thorblock.io"}
I’m aware that it might not cover all use cases but for now it works for us, so I thought I might share it.
We also store the app icon (separately), so having a url that points to a svg version of the app icon would be very interesting as well.
Add a version so we know what kind of format to expect.
The icon field should either only allow URLs, or be optional. In cases where size matters a base64 encoded image would be bad.
Fields that could be added:
Supported Blockchains (Array of identifiers, eg. [‘ae’, ‘eth’] => Would solve the problem of knowing whether a random webmanifest file is compatible with our aepp browser.
Tags: List of user provided keywords that describe the app, limited to a certain number (5?) eg. [‘gambling’, ‘beta’]
Regarding the format, I think it would make sense to use the webmanifest file. Not only might developers already be familiar with it, but there is also good documentation available. Also, if we use the standard, users can add metadata in only one place and then whoever knows how to parse a webmanifest file (browser, aepp browser) can instantly make use of all the properties available.
We should also define which properties are required to be correctly displayed in an aepp browser, which are recommended and which are optional. In the official webmanifest standard, as far as I know, only the name property is required.
But we should probably recommend that developers provide an icon, description and maybe some other fields.
How do you see the distinction between required, recommended, and optional? I don’t think there is any way to distinguish required from optional… because in reality I don’t think we would not list aepps because a field is not filled out…
What would the difference between recommended and optional be?
I don’t think the image should be optional… I think it greatly improves the UX. I think it can be specified as a URL. Could it be an SVG?! I’m not sure what the browser support is for that these days (I assume not uniform/full)…
The list of supported protocols makes sense to me.
Having a version field makes sense to me… You are referring to a version of the format right?
In regards to taxonomy… I was thinking we should have “categories” not “tags”… The difference being that the categories are decided by the spec (while tags I assume to be freeform). I think having a set of predefined categories makes more sense (because I hesitate to suggest that anyone could come up with their own tags… that could be messy)… but maybe you have an argument for the opposite?!
It’s also ok if we say every field is optional, but as I mentioned, the name (or short_name) field is the one required field in the webmanifest specs. So I believe that should also be required for us so that we are in compliance with the standard (otherwise “our” webmanifests can not be read by the browsers).
For me the distinction is:
Required: If not provided, the aepp will not be displayed
Recommended: Should be provided, if not, a fallback will be shown
Optional: Can be provided, if not, a fallback will be shown
Recommended and optional are basically the same thing, but it helps the developers to know what the standards are and what others are doing. For example, it could look something like this:
Maybe we don’t have to make this distinction in the proposal, but I think we can all agree that some fields will probably be used in every aepp browser (eg. name, icon, description) and should be provided by every aepp. So if they are not required, we should at least tell developers that these are recommended for the best user experience. There are many more fields like background_color, banner_image, etc. that might also be useful, but they not that important. So these fields would just be optional and only the developers who really want to get the most out of their aepp listing can invest the extra time to provide them.
Having a list of recommended fields allows us to define a clear guideline for aepp developers what they should provide, but still allows “incomplete” manifests where the browser just shows a fallback. (In contrast to that, if the fields are required, the browser should probably not include that aepp in the list)
But again, maybe this distinction doesn’t make sense and it’s best to just provide an example and hope people use that as a starting point.
I guess SVGs should also be ok, as long as it’s not provided as a data blob.
If only URLs are allowed, then I’m ok with it being “required”.
Otherwise if it’s required (and data is allowed) it might be tricky in situations where size is important (eg. If we want to display information about an Aepp in the Vault, that information has to go through a QR code.)
Yes
If we have to decide between categories and tags, then I’m definitely for categories as well.
I think it’s a personal preference. I always thought “freeform tags” are a good way for people to kind of “summarize” things (in this case aepps) in a very short form. But I know many people strongly dislike that concept of “freeform tags”. So it’s only a suggestion, I don’t have strong feelings about it.
The one thing I see is that it’s more flexible than the categories. Categories should probably be more high level, tags can be very specific, and they can also evolve (if new features get added like state channels) without changing the specs and adding a new category.
If we would add that, it should definitely be limited to 3 or 5 tags per aepp.
