-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
id
member reuse in MiniApps Manifest (no document URL
)
#1048
Comments
Maybe a wild idea:
Am I on the right track here for what you are interested in? |
Thanks @dmurph , the problem I see is that there may be mini apps with no origin (distributed through non-HTTP ways). This is why we cannot find that absolute URL. |
How is the app authenticated? Is it signed for integrity but not from a source? I'm not sure the best way to do this - you could just require that the id is full absolute URL (with origin) anyways, which would make it compatible. IDK if you could "verify" that origin though. |
[Bringing the discussion from w3c/miniapp-manifest#43]
We want to align the MiniApp identifier (
app_id
) with the web app manifest'sid
. It would make sense to reuse it directly. It fits in terms of semantics ("a string that represents the identity for the application.")But there is a big difference, the (web app manifest's)
id
takes the form of a URL, which is the same origin as the start URL. MiniApps are packaged and can be distributed by different means, not only through the web (so not necessarily must have a start URL). In some cases theapp_id
follows the Java package naming (e.g.,org.example.app
).Since we are using the manifest extension mechanism, is it possible to reuse the member but refine the processing algorithm?
Also, reviewing the main algorithm, I see another relevant challenge, the
document URL
must not be null. Any idea how to relax or bypass this dependence?The text was updated successfully, but these errors were encountered: