@jyasskin @slightlyoff the reaction to https://github.com/mozilla/standards-positions/issues/1213#issuecomment-4347988313, and the responses on social media and Hacker News. What's the evidence for "strongly positive"? https://github.com/webmachinelearning/prompt-api/issues/74 was cited in the Intent to Ship.
Post
Replies:
14
@jaffathecake @slightlyoff Those aren't limited to developers, right? Was the reaction to the Prompt API more or less strong than the reaction to Firefox's AI features? I personally share the "hate everything to do with AI" sense, but I think the API owners would focus on developers actually building sites over random people with opinions on the internet.
If you look at https://api.github.com/repos/webmachinelearning/prompt-api/issues/74/reactions, all but one -1 is April 30 or later, a month after the I2S. That's an internet mob, not developer sentiment.
@jyasskin @jaffathecake In fairness to folks spotting the I2S late, I did too. I'm not sure how that cuts one way or the other on the substantive critiques, but it seems to me that not having +1s from API OWNERS outside Google when this was known to be controversial is at least a misread of the room.
@jyasskin @slightlyoff yes, plenty of the negative reaction to the prompt API is from web developers.
Do you feel the evidence given in the I2S justifies saying developers are "strongly positive" about this feature?
@jaffathecake @slightlyoff https://groups.google.com/a/chromium.org/g/blink-dev/c/iR6R7-nQeHI/m/9Sb7o12jAgAJ lists some more sources for developer feedback, but it looks mostly private, so it's all about whether you trust the team to grade their own homework, which we generally shouldn't. Even if it were public, I don't think I'd have the expertise to tell whether it was net positive, given the selection bias introduced by hosting a hackathon.
@jyasskin @slightlyoff the I2S points to https://github.com/webmachinelearning/prompt-api/blob/main/README.md#stakeholder-feedback for evidence which includes "developer surveys", which is a link to a survey that appears to have asked if developers would be happy with this as an "extension API". So yeah, there's something a little fishy going on.
"Misrepresentation" is one of the things disallowed in Google's ToU for the Prompt API. I guess, therefore, summarising the I2S with the Prompt API would be breaking the rules.
@jaffathecake @jyasskin Sorry for slow reply.
I don't credit much of the developer feedback I've seen, so to your first question, I think a tentative "maybe." That's part of what I'm arguing in the blink-dev thread, and why I think this needs, at a minimum, to go back to OT and bake. That is, hold Blink participants to the Blink Launch Process, rather than decry a vendor leading when others aren't offering alternatives.
I.e., value responsibility and honesty.
@slightlyoff @jyasskin I think it's reasonable to complain about an abuse of position without offering an alternative.
@slightlyoff @jyasskin some thoughts on this on the other site https://bsky.app/profile/jakearchibald.com/post/3mkrt2wswpk2k
@jaffathecake @jyasskin "abuse of position" doesn't assume good faith, and I think folks working inside Blink need to extend that assumption towards each other (until proven otherwise). That isn't Mozilla's job, of course, but heating the rhetoric after I've called the question on blink-dev may not achieve your goal.
@slightlyoff @jaffathecake From the outside of the Webstandards process this all looks very much like Google pulling a “fuck your complaints, we’re shipping it.” and should be treated as a hostile act
@ash @jaffathecake "web standards" are misunderstood, in part, because trailing vendors have had a long history of trying to obscure the central role of voluntary adoption in Internet Standards. That's a problem that I've written about:
https://infrequently.org/2025/08/how-do-committees-fail-to-invent/
The firmer ground to argue from is that there doesn't appear to be a path to plausible interoperability.
@slightlyoff @ash …and that the API requires complying with a Google ToS. And that developer sentiment was (assuming good faith) poorly represented.
@jaffathecake @ash So the API itself doesn't need any ToS, at least not in other browsers. That's a Chrome product attribute that lots of folks will object to, but it's not part of the API any more than Web MIDI requiring an extension in FF is.
The deeper problem is model interoperability. No idea how we'll get close to that with an API that has no way to specify model or version.
@slightlyoff I think you're underestimating the ToS issue. See the problem I laid out here https://github.com/mozilla/standards-positions/issues/1213#issuecomment-4347988313. If we allow APIs to have ToS, it creates an environment where developers are encouraged to block usage in other browsers in case they release with a ToS that'll get them sued.
