CIP-0072 | Off-chain schema fixes

[danielmain]

By creating a product on top of this specification we came up with two small fixes on the schnma definiton of the off-chain JSON

Fixes:

• We use anyOf instead of oneOf for the logo, by accepting any image format like png/jpeg/svg
• We use anyOf instead of oneOf for the screenshots, by accepting any image format like png/jpeg/svg
• The subject accpets any string and dots, adhering to the reverse domain name pattern commonly employed as the package or bundle identifier in Android and iOS applications. This widely accepted convention serves to guarantee uniqueness and mitigate naming conflicts, having established itself as a standard within the development community. For example: com.company.application
• Small text in long-descriptoion changed. (Removed the word optional)
• Limitations in size of metadata and having each picture in base64 makes it difficult to handle big pictures. Setting maximum of logo and screenshots.
• Added a requirement of minimum one social link and at least one screenshot to add in the offchain json.
• Added regex pattern to validate that the string matches base64 images

Since this a fix we are upgrading the version of the schema file to 2.0.1

[rphair]

To me this seems like both a justification of the semantic versioning previously debated and an example of a change editors can approve as a matter of routine.

[Ryun1]

LGTM

[rphair]

@Crypto2099 I believe it makes sense to wait for your input before merging 🤓

[danielmain]

Thank you @rphair and @Ryun1 for your patience. As we embark on translating this specification into a tangible product, we inevitably encounter elements that require modification. I apologize for the frequency of these changes. 🙇🏻

We do not need to merge it now, I will definetly participate in the next CIP Editors meeting if we think whe should to merge it soon 🙏🏻

[Quantumplation]

@danielmain re your comments in the CIP editors meeting on "subject" vs "domain" validation;

I really like the idea, my only suggestions would be:

• make it an explicit domain field, rather than something like a subject
• don't use the "reverse-domain" convention from Java; it's not widely adopted in the industry, and IMO is confusing as hell haha

[rphair]

👍 @Quantumplation #631 (comment) above... in this particular (crypto) industry the "app stores" should be able to support plenty of "headless" dApps without web sites, and reverse domain name notation relies apparently on DNS and nothing else to avoid collisions:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.1

The name of a package is not meant to imply where the package is stored on the Internet. The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.

[danielmain]

make it an explicit domain field, rather than something like a subject

You are totally right! We will make this change 👍

don't use the "reverse-domain" convention from Java; it's not widely adopted in the industry, and IMO is confusing as hell haha

I'm mainly familiar with the two industry leaders, Google Play Store and iOS App Store 🤷‍♂️.

Google Play Store follows this method (originally due to its Java roots).

Similarly, the second largest app store, 🍏 Apple, also adopts this approach. You can see how Apple apps are structured here: https://support.apple.com/en-gb/guide/deployment/depece748c41/web.

Given that the majority of the industry, or at least a significant portion, adheres to this pattern, @Quantumplation, what are your thoughts? Wouldn't it make sense for us to align with what's widely recognized and familiar?

[danielmain]

👍 @Quantumplation #631 (comment) above... in this particular (crypto) industry the "app stores" should be able to support plenty of "headless" dApps without web sites, and reverse domain name notation relies apparently on DNS and nothing else to avoid collisions:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.1

The name of a package is not meant to imply where the package is stored on the Internet. The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.

Good point, @rphair, but isn't the domain a shared element across all dapps 🤔? Are there any Cardano dapps that operate without a domain?

However, it's important to note that the subject or bundleID isn't the domain itself, but rather an identifier. Often it's in the reverse-domain format, which is common for many apps on iOS/Android.

While we can recommend using a specific 'reverse-domain', the choice is ultimately yours to make 🙂

Also, it's not just Java that follows this practice; Apple does too: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier
A bundle ID uniquely identifies a single app throughout the system. The bundle ID string must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). Typically, you use a reverse-DNS format for bundle ID strings. Bundle IDs are case-insensitive.

[rphair]

@danielmain we are not in a hurry to close this but we do need to know where this submission is going. Do you still want/need to make these changes? It's been 7 months... do your plans still look this same? When will this be ready for review? What issues are you looking at now, as updated from last year when you submitted this? Please let us know what we are waiting for (tagging Waiting for Author in the meantime). (cc @greatertomi)

[rphair]

@danielmain if this is going to move forward as a document (as we would definitely hope, if you have been progressing this effort in the development world!) then please let us know soon (marking potentially "abandoned"). cc @greatertomi @Quantumplation @Ryun1