The nice thing about open protocols is that we don't have to endorse or use one implementation over another, yet, somehow, the browser monopoly continues to be a standing dilemma. There are nice projects, like ungoogled chromium, tor, and many more, but I find the biggest issue is that there isn't a voice out there for the average person and a project that connects with the masses. I think another issue is that a lot…
Mozilla's opposition to Chrome's Prompt API
111–120 of 248 posts
Re: Mozilla's opposition to Chrome's Prompt API
#112Earlier quoted context omitted.
We start by not shipping Chrome with "native" applications instead of learning the platform APIs. Followed by creating Web applications based on Web standards, instead of whatever Chrome does, and then complain about Firefox and Safari not being up to the game.
I really don't see how Electron is connected here. When you're an Electron app, you really don't have to care about which web APIs Chrome implements, you can just use the native NodeJS equivalents, which will usually give you a better UX anyways. But absolutely on the second point. A standard with one implementation is not a standard. Regardless of market share, in a market with three providers, if two out of three d…
Electron is Chrome packaged with the application.
If those devs cared about Web standards, it would be a pure Web application, or an headless executable, system/daemon conecting to the system's browser.
Re: Mozilla's opposition to Chrome's Prompt API
#113The objections seem clear: tight-coupling of prompts to models, and model neutrality in the TOU. From https://github.com/mozilla/standards-positions/issues/1213 : "A personal example: I created a system prompt for creating announcements for a home automation system. The Gemini model I was using initially responded in a very US-American way, which didn't fit the British voice of my speaker. I told the model, via the s…
If that was a good argument to not support an LLM feature, then it would be a reason to not add it to any platform API. And yet, it has been added to numerous platforms already. Different models are just a core aspect of how the technology works. It's like a canvas can have different possible width and height depending on the device or it's orientation. Or the geolocation API giving more or less accuracy depending on…
The important part was the following paragraph(s) that explained why this coupling is a compelling problem. It's not the same as just having a platform API.
Re: Mozilla's opposition to Chrome's Prompt API
#114So we can’t have XSLT fast and efficient templating syntax but Prompt APIs with potential attack injection vectors are cool as long as they’re generic enough for all megacorps to drop in? No security risks here huh? Not trying to increase the attack surface huh?
Re: Mozilla's opposition to Chrome's Prompt API
#115Earlier quoted context omitted.
> Meaning you do not want text generation in the web API at all, or you think the prompt API needs to be different? Not OP but I think you are misunderstanding the interaction as a whole here. The Chromium team made a proposal, then the Chromium team asked the Firefox team for a position on the proposal. Whether or not the Firefox team or anyone on the Firefox team has any goals around AI or whatever, this response w…
You didn't read my comment carefully enough. It was not about AI in general. It was about the text generation API. And it is perfectly reasonable to ask if he wants to reject the feature entirely or if he can give a one sentence overview of how it might be fixed. There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable a…
> There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable ask.
I do think it is a bit unwarranted, actually. This isn't a press release, it's a technical discussion somewhat deep into a technical process that's open for archival purposes. His audience is not people skimming through, it's the Chromium team and other members of the standards body.
You're sort of overhearing a conversation and injecting yourself into it.
Re: Mozilla's opposition to Chrome's Prompt API
#116Is this going to be another situation, like WebSQL, where Firefox torpedos a broadly useful feature?
Re: Mozilla's opposition to Chrome's Prompt API
#117The Prompt API has some advantages like being a little simpler for some things and some potential to standardize a little bit more in some way, but it looks like from this that it will be delayed unfortunately.
However, WebLLM (a library, not actual Web API) https://github.com/mlc-ai/web-llm is more capable and will already work using WebGPU.
Re: Mozilla's opposition to Chrome's Prompt API
#118Earlier quoted context omitted.
I really don't see how Electron is connected here. When you're an Electron app, you really don't have to care about which web APIs Chrome implements, you can just use the native NodeJS equivalents, which will usually give you a better UX anyways. But absolutely on the second point. A standard with one implementation is not a standard. Regardless of market share, in a market with three providers, if two out of three d…
Electron is Chrome packaged with the application. If those devs cared about Web standards, it would be a pure Web application, or an headless executable, system/daemon conecting to the system's browser.
I'm not saying the Electron UX is better than a native app. I'm saying Electron apps using NodeJS libs have better UX to Electron apps using Web APIs. At best there's no difference for the user, but at worst, they get permission popups and limited access just like they would in a browser.
This is why Electron app devs prefer NodeJS libs to Web APIs and consequently have no impact on the adoption of a large chunk of the new Web APIs (not counting DOM and CSS things because those are rarely controversial and usually broadly implemented).
So yes, those devs don't care about these kinds of new web "standards", because they don't work with them. The people who use them are the ones who are dangerous and that's almost exclusively web app authors, because they can't just pull in a native library to do the same things.
Re: Mozilla's opposition to Chrome's Prompt API
#119Earlier quoted context omitted.
You didn't read my comment carefully enough. It was not about AI in general. It was about the text generation API. And it is perfectly reasonable to ask if he wants to reject the feature entirely or if he can give a one sentence overview of how it might be fixed. There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable a…
> There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable ask. I do think it is a bit unwarranted, actually. This isn't a press release, it's a technical discussion somewhat deep into a technical process that's open for archival purposes. His audience is not people skimming through, it's the Chromium team and other memb…
And so are you injecting yourself and objecting to me even discussing on HN.
And this is not really a technical issue. It's a worldview issue no matter how much you or others try to pretend it's a technical problem or that I am violating etiquette or something.
Re: Mozilla's opposition to Chrome's Prompt API
#120The objections seem clear: tight-coupling of prompts to models, and model neutrality in the TOU. From https://github.com/mozilla/standards-positions/issues/1213 : "A personal example: I created a system prompt for creating announcements for a home automation system. The Gemini model I was using initially responded in a very US-American way, which didn't fit the British voice of my speaker. I told the model, via the s…
> but the result was a bad US-American impersonation of British ("a'waight guv'nor apples and pears" etc etc)
sounds like adversarial mode mocking