> Rouslan, it looks to me like the API is designed to support multiple stores, right? > For example if Samsung decided that they wanted to support connecting it up to > both the Android Play Billing API (so SBrowser could provide equivalent user > experience to Chrome) AND to the Samsung store (so merchants could have > a choice in stores, perhaps competing on terms like commission rate) they > could do that with the current API shape, right?
That is correct. The API shape has been generalized enough to be store-agnostic and browser-agnostic. We have <https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9> been <https://www.w3.org/2021/10/28-wpwg-minutes.html#t04> pitching the API to other stores and browsers as well. On Wed, Feb 2, 2022 at 10:31 AM Rick Byers <rby...@chromium.org> wrote: > +1 to Yoav's perspective here. Our job is not to force interoperability > but to create the conditions to make future interoperability as easy as > possible. We have multiple examples of APIs where originally Chrome was the > only interested browser, but once sites started to adopt them and > demonstrate the value, other browsers decided they wanted to provide their > users with that value too. I would hate to create a condition where, for > example, Brave, Edge or Samsung browser felt compelled to support an API > with 'Chrome' in it's name once there was clear user value to supporting > the use case. Further, if we put Chrome in the name that could be perceived > as indicating that we were actively trying to create such browser lock-in > or otherwise create conditions for Chrome to have an unfair advantage over > other browsers when nothing could be further from the truth. > > Rouslan, it looks to me like the API is designed to support multiple > stores, right? For example if Samsung decided that they wanted to support > connecting it up to both the Android Play Billing API (so SBrowser could > provide equivalent user experience to Chrome) AND to the Samsung store (so > merchants could have a choice in stores, perhaps competing on terms like > commission rate) they could do that with the current API shape, right? > > We've fought hard to get away from the webkit-prefixed and "chrome apps" > world and we know it's not possible to know up front that an API will never > have interoperable implementations. I think the downside of potentially > using up a small piece of the global API namespace for an API that fails to > achieve interoperability is much smaller than the downside of > disincentivizing other implementations or burning a Chrome/Play API name > into the web for what may become more general. > > At the same time, the TAG has been clear that their time is best spent on > the APIs that are most likely to become interoperable standards. Dan told > me at one point that it might be best if we didn't even both asking for TAG > review that didn't have engagement from a 2nd browser., so I don't think we > should expect them to have any real interest in reviewing this API. They've > already marked this review as closed, so I don't think we should expect a > response. > > Rego, what do you think? I'll give my LGTM3 but also happy to keep > discussing the tradeoffs here. I really appreciate having the non-google > API owners perspective here, it's always possible that us Googlers have > some unconscious bias influencing our thinking. > > Rick > > > On Wed, Feb 2, 2022 at 6:52 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Wednesday, February 2, 2022 at 9:25:54 AM UTC+1 Manuel Rego wrote: >> >>> TAG suggested back in July that this API something specific to Chrome or >>> Google Play Store. It looks like this hasn't been done, any good reason >>> to not doing that? >> >> >> From my perspective, I believe that piece of feedback runs contrary to >> Blink's >> interoperability principles >> <https://docs.google.com/document/d/1romO1kHzpcwTwPsCzrkNWlh0bBXBwHfUsCt98-CNzkY/edit#heading=h.t71a2ioil8j0>, >> and is contrary to what we (well, I) told the API's developers when they came >> to this list with a proprietary proposal >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs/m/Gt4sKECQEgAJ> >> . >> The proposal got a lot of interest >> <https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350> >> on >> WICG, and even if the only store that implements it is the Google Play >> Store, I think there's value in having an interoperable API that would >> enable other Chromiums to ship, as well as enable implementations in >> non-Chromium Android browsers. I'd also be hesitant to exclude the >> possibility >> of other stores >> <https://github.com/w3ctag/design-reviews/issues/571#issuecomment-861188412> >> implementing this API as well in the future. >> >> >> >>> >>> Also there's been an update on the TAG about the plan of shipping this >>> API without changing the name. But that was just 1 week ago, should we >>> give them some time to reply before shipping? >>> >>> Cheers, >>> Rego >>> >>> On 01/02/2022 20:41, Yoav Weiss wrote: >>> > LGTM2 >>> > >>> > On Tue, Feb 1, 2022 at 8:00 PM Chris Harrelson <chris...@chromium.org >>> > <mailto:chris...@chromium.org>> wrote: >>> > >>> > >>> > LGTM1 >>> > >>> > On Tue, Feb 1, 2022 at 6:16 AM Rouslan Solomakhin >>> > <rous...@chromium.org <mailto:rous...@chromium.org>> wrote: >>> > >>> > Contact emails >>> > >>> > mgi...@chromium.org <mailto:mgi...@chromium.org>, >>> > rous...@chromium.org <mailto:rous...@chromium.org>, >>> > glen...@chromium.org <mailto:glen...@chromium.org> >>> > >>> > >>> > Explainer >>> > >>> > https://github.com/WICG/digital-goods/blob/main/explainer.md >>> > <https://github.com/WICG/digital-goods/blob/main/explainer.md> >>> > >>> > >>> > Spec >>> > >>> > https://wicg.github.io/digital-goods/ >>> > <https://wicg.github.io/digital-goods/>- Currently being >>> > reviewed by a spec mentor, so some details may change >>> > (hopefully, only formatting). >>> > >>> > >>> > Summary >>> > >>> > An API for querying and managing digital products to facilitate >>> > in-app purchases from web applications, in conjunction with the >>> > Payment Request API (which is used to make the actual >>> > purchases). The API would be linked to a digital distribution >>> > service connected to via the user agent. In Chrome, this is >>> > specifically a web API wrapper around the Android Play Billing API. >>> > >>> > >>> > Origin trial analysis >>> > >>> > DGAPI v2.0 is currently in an origin trial with M99 being the >>> > last milestone. So far, 40 people have responded to the origin >>> > trial survey. Notable data points: >>> > >>> > >>> > How easy was it to use the feature:4.1 out of 6. >>> > >>> > (0 - extremely difficult … 6 - extremely easy.) >>> > >>> > >>> > How likely are you to keep using this feature:5.5 out of 6. >>> > >>> > (0 - extremely unlikely … 6 - extremely likely.) >>> > >>> > >>> > The most common comments were about improving feature >>> > documentation and debuggability. That is being tracked in >>> > https://github.com/WICG/digital-goods/issues/33 >>> > <https://github.com/WICG/digital-goods/issues/33>. >>> > >>> > >>> > Blink component >>> > >>> > Blink>Payments >>> > < >>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> >>> >>> > >>> > >>> > Search tags >>> > >>> > payments <https://chromestatus.com/features#tags:payments>, >>> > billing <https://chromestatus.com/features#tags:billing> >>> > >>> > >>> > TAG review >>> > >>> > https://github.com/w3ctag/design-reviews/issues/571 >>> > <https://github.com/w3ctag/design-reviews/issues/571>TAG >>> > recommends making a Chrome-specific API. Other issues addressed. >>> > >>> > >>> > TAG review status >>> > >>> > Issues addressed >>> > >>> > >>> > Risks >>> > >>> > Interoperability and Compatibility >>> > >>> > Similar to Payment Request: this API is used to talk to specific >>> > store backends, and so its usage is tailored to the specific >>> > store. The reason it's a proposed web standard is so that the >>> > same code (which is specific to one store) is portable across >>> > browsers. >>> > >>> > >>> > Gecko: No signal >>> > (https://github.com/mozilla/standards-positions/issues/349 >>> > <https://github.com/mozilla/standards-positions/issues/349>) >>> > Requested 2020-05-27. >>> > >>> > >>> > WebKit: No signal >>> > ( >>> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html >>> > < >>> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html>) >>> >>> > Requested 2021-10-08. >>> > >>> > >>> > Web developers: Positive >>> > ( >>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350 >>> > < >>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350>). >>> >>> > >>> > >>> > Other signals: rouslan@ presented DGAPI at 2021 TPAC >>> > <https://www.w3.org/2021/Talks/rouslan-dgapi-20211028.pdf>(meeting >>> > notes <https://www.w3.org/2021/10/28-wpwg-minutes.html#t04>) and >>> > at a recent PWA Dev Sync >>> > < >>> https://drive.google.com/file/d/1a_6_QVEQrEeUduc8nPE-uc7PKCr-Yhx7/view>(meeting >>> >>> > notes >>> > < >>> https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9>). >>> >>> > Other browser implementers and app stores do not appear to have >>> > immediate plans to engage with DGAPI. There were some questions, >>> > no objections. >>> > >>> > >>> > Ergonomics >>> > >>> > Digital Goods API is used in tandem with the Payment Request API. >>> > >>> > >>> > In order for another browser to implement Digital Goods API for >>> > Play Billing in the same way as Chrome, they would need to >>> > implement something like the Trusted Web Activity >>> > <https://developer.chrome.com/docs/android/trusted-web-activity/>(TWA) >>> >>> > feature and then invoke the TWA shell methods for communicating >>> > with Play Billing. The android-browser-helper >>> > <https://github.com/GoogleChrome/android-browser-helper>is a TWA >>> > template code that we have been recommending app developers to >>> > use for the Play Billing integration. >>> > >>> > >>> > >>> > Debuggability >>> > >>> > We have had several requests from developers to make the API >>> > easier to debug, but it is difficult due to the interaction with >>> > a backing service based in an app/store context. We are looking >>> > for suggestions (https://github.com/WICG/digital-goods/issues/33 >>> > <https://github.com/WICG/digital-goods/issues/33>) on how we >>> > might improve the debuggability of the API. >>> > >>> > >>> > Is this feature fully tested by web-platform-tests >>> > < >>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? >>> >>> > >>> > The tests are in >>> > //third_party/blink/web_tests/wpt_internal/digital-goods. >>> > >>> > >>> > I think these could move to WPT proper with .tentative file names? >>> > >>> > >>> > >>> > Flag name >>> > >>> > DigitalGoods >>> > >>> > >>> > Requires code in //chrome? >>> > >>> > False >>> > >>> > >>> > Tracking bug >>> > >>> > https://crbug.com/1248319 <https://crbug.com/1248319> >>> > >>> > >>> > Launch bug >>> > >>> > https://crbug.com/1250123 <https://crbug.com/1250123> - There >>> > are no code changes from the current origin trial to what we >>> > intend to ship to stable. Therefore, there is no new tracking >>> > bug or launch bug being filed. >>> > >>> > >>> > Estimated milestones >>> > >>> > Origin trial end: 99 >>> > >>> > Ship to stable begin: 100 >>> > >>> > >>> > Link to entry on the Chrome Platform Status >>> > >>> > https://chromestatus.com/feature/5339955595313152 >>> > <https://chromestatus.com/feature/5339955595313152> >>> > >>> > >>> > Links to previous Intent discussions >>> > >>> > Intent to prototype 1.0: >>> > >>> > https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs >>> > <https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs>. >>> > >>> > Intent to experiment 1.0: >>> > >>> > >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ >>> > < >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ>. >>> >>> > >>> > Intent to continue experimenting 1.0: >>> > >>> > https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o >>> > <https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o>. >>> > >>> > Intent to experiment 2.0: >>> > >>> > >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ >>> > < >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ>. >>> >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the >>> > Google Groups "blink-dev" group. >>> > To unsubscribe from this group and stop receiving emails from >>> > it, send an email to blink-dev+unsubscr...@chromium.org >>> > <mailto:blink-dev+unsubscr...@chromium.org>. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com >>> > < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "blink-dev" group. >>> > To unsubscribe from this group and stop receiving emails from it, >>> > send an email to blink-dev+unsubscr...@chromium.org >>> > <mailto:blink-dev+unsubscr...@chromium.org>. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com >>> > < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "blink-dev" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an email to blink-dev+unsubscr...@chromium.org >>> > <mailto:blink-dev+unsubscr...@chromium.org>. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com >>> > < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58d2ff10-efe9-470c-9ed6-9ec555a44194n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58d2ff10-efe9-470c-9ed6-9ec555a44194n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWGvt-NRov%3D3M8sCw9SzzKPcq3fC8CLRuQtv2xnhxmPZOg%40mail.gmail.com.
