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:
- Required: Name
- Recommended: Icon, Description, Supported Protocols, Category, Banner Image, Network, Link, Age restriction
- Optional: Theme color, Background Color, etc… (all other webmanifest fields + our own)
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.