solana-mobile / dapp-publishing Goto Github PK

I'm running through the setup steps for the CLI as described here.

When running the last command: pnpm link . I am getting an error:

Lockfile is up to date, resolution step is skipped
ERR_PNPM_INVALID_PACKAGE_NAME  Package in . must have a name field to be linked

I am going to keep trying to go through the CLI steps and see if they work despite this error. I'll update this ticket as I learn more.

UPDATE

I continued following the steps and attempted to run the CLI. When I try and run even the help command on the dapp-store command I get an error:

npx dapp-store --help
node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_IMPORT_ASSERTION_TYPE_MISSING]: Module "file:///Users/awatson/Repos/app-publishing-spec/packages/core/lib/esm/validate/schemas/publisherJsonMetadata.json" needs an import assertion of type "json"
    at new NodeError (node:internal/errors:388:5)
    at validateAssertions (node:internal/modules/esm/assert:82:15)
    at defaultLoad (node:internal/modules/esm/load:24:3)
    at ESMLoader.load (node:internal/modules/esm/loader:431:26)
    at ESMLoader.moduleProvider (node:internal/modules/esm/loader:350:22)
    at new ModuleJob (node:internal/modules/esm/module_job:66:26)
    at #createModuleJob (node:internal/modules/esm/loader:369:17)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:328:34)
    at async ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:82:21)
    at async Promise.all (index 1) {
  code: 'ERR_IMPORT_ASSERTION_TYPE_MISSING'
}

Node version 18.4.0
NPM version 8.12.1
pnpm version 7.16.1

We need to get the decentralized upload URI for all of the files associated with publishers, apk, and icons first, then update the relevant JSON before final upload to arweave.

Right now the tooling only works within a very specific version range of nodejs 16. We should probably just make this work with whatever the latest nodejs version is for ease of use for the tooling.

As of this writing the latest versions are 18.x (LTS) & 19.x (Current).

Support for this should be evaluated and added in the future, when appropriate.

An app can have multiple ratings. As a baseline, we should support the same systems that Google Play Store does, limited to our launch markets: https://support.google.com/googleplay/answer/6209544

ESRB, PEGI, USK, ACB, IARC

Something like this:

"age_rating": {
"esrb": "10+",
"iarc": "12+",
}

where the fields and supported values are enumerated. No classification of a dApp is mandatory - it can provide no, some, or all ratings.

we have three primary schemas that are handled in the context of publishing information for the dapp-store:

1. the schema of config.yaml

2. an intermediary, in-memory representation / adaptation of the config.yaml + extra environmental information

3. the schema of the off-chain JSON metadata on the resultant NFT

4. goes in the cli package

5. and 3. go into core

this needs to be clear / streamlined so that we can be sure which representation we're working with and adapting to

The "core" module exposes the base helpers required to interact with publisher, app, and release NFTs.

One example of how this can be used will be the cli module. The core module is intended to operate in a web-based context, too.

We need to finalize the roles supported in the files region of the release JSON spec. We currently only have one:

• install - the APK file to download & install

There may not really need to be any other roles, but we should discuss at any rate.

The Publisher and App icon files should have the following constraints enforced by the CLI:

• Image files should be of the format JPEG, PNG, or WebP
• Dimensions no larger than 512x512

Media files included for app release should have the following constraints enforced by the CLI:

• Image files should be of the format JPEG, PNG, or WebP
• The purpose value in the resulting JSON should be only image, video, or screenshot

The files collection should have the following constraints enforced by the CLI:

• Only APK files are currently allowed
• The purpose roles should be set to install

Media files included for app release should have the following constraints enforced by the CLI:

• Image files should be of the format JPEG, PNG, or WebP
• They should have a reasonable minimum dimension (no aspect ratio enforced
• The puprose value in the resulting JSON should be only image, video, or screenshot

For the "files" section

This repo originally existed to just document the app publishing spec, but has since grown to encompass quite a bit more. I propose we rename the repo to signify all of what is contained here.

The new repo name could be something as simple as dapp-publishing. Let's discuss.

Companies will possibly need to provide "private" information in their testing notes, which live in the config.yaml. That yaml file may be made open source with the rest of the repo.

We'll need some facility to provide private information for store submissions that aren't in any mostly public file.

Dimensions should be 512x512

If a user uploads assets to the arweave devnet cluster, they will not be appropriately persisted.

We need to finalize the supported and/or required roles for media in a dapp release. We currently have:

• image
• video
• screenshot
• banner - this one is not final but we'll likely need something like it

Correspondingly, we need to come up with specifications around the assets to be included; e.g. dimensions, formats, etc.

In looking through the various issues here on GitHub and thinking about the publishing system, we very likely need to consider a plan for publishing schema upgrades & migrations. There are a number of fields that we may not be able to facilitate now but will need or want to add in the future. This means that we need a way to facilitate upgrades to our schema and have it propagate through the publishing workflow.

Some ramifications I can think of related to this:

• The CLI should validate the latest release a publisher creates against the latest version of the schema
• The CLI possibly need to check to see if there is an update to the JSON schema and/or itself
• We need to think about the workflow where a publisher mints a release, the spec upgrades, and they need to add or update fields in their metadata for the next release
• The dApp store API should probably filter out published NFTs based on some minimum/required schema version
• The relevant schema version should be included in the various JSON files
• We very likely need a separate versioning system for each of the 3 JSON files

This will very likely become relevant to us sooner than we'd like, hence why I'm starting the discussion now.

Localized strings are supposed to be setup in the resulting JSON schema as unique ID-based key-value pairs. This is not yet implemented.

When parsing all of the included media, both the mime type and sha hash need to be derived and put in the resulting JSON data.

i suspect that many teams will forgo the choice to internationalize properly given the choice to skip it. given the ability to automate this process, i think it should be a part of the publishing flow that at least collates the relevant information to submit to an API-based service like Smartling

due to the immutability of releases, this step may need to happen well ahead of publishing time. i'd be willing to make create releases that are mutable but where an entity we control retains update authority for the sole purpose of reconciling internationalization updates automatically with releases

Currently hard-coded to bundlr devnet.

i think it is pretty clear that we should have an out-of-band app verification flow, ideally supported by Hubspot. however, we do need to make a decision on how we surface that information into the Dapp store itself—how do we signal our "acceptance" of a particular published release? a few options for your perusal:

Entirely off-chain

have the GraphQL API that powers the Dapp Store join release address against acceptance status in HubSpot
pros

• easiest to implement

cons

• external consumers rely on the GraphQL API as the source-of-truth

Entirely on-chain

have a designated keypair "sign" the release NFT
pros

• easiest for external consumers; all information available on-chain without the use of GraphQL
• can add on-chain "notes" as part of the review process

cons

• rabbithole of corner-cases related to keypair management and maintenance
• limited amount of space on the NFT metadata creators array

Right in the middle

issue a well-formed transaction with a designated keypair

pros

• doesn't mess with release NFTs
• retains the ability to add "notes" or other metadata to the review process

cons

• operationally, slightly difficult to query for specific transactions and map them to releases

We need to enumerate what options available as values for the age_rating key in the release NFT JSON:

"age_rating": "3+",

The scope of this ticket is only to enumerate what options will be included in the JSON/tooling management. These values will be the result of larger discussions around app store policies, which should happen elsewhere.