Chrome looks set to ship an LLM Prompt API to the web platform.

[north@xn--8r9a.com]

@firefoxwebdevs that's rich

[firefoxwebdevs@mastodon.social]

@xela it's possible an LLM API will come along that solves the issues, but yeah… it seems really tricky. The open ended nature of it will always be a huge interop problem.

If the use-cases are tightened, e.g. translation, the problem is reduced.

[marc_eu@veganism.social]

@stux @firefoxwebdevs
Read first before you react. Mozilla opposes the *API*.

[stux@mstdn.social]

@marc_eu @firefoxwebdevs Yes, AI API

[wcbdata@vis.social]

@firefoxwebdevs I'm assuming @Vivaldi will disable the whole thing, yes?

[marc_eu@veganism.social]

@stux @firefoxwebdevs
En dus is de reactie van Mozilla niet zo gek?

[xela@troet.cafe]

@firefoxwebdevs honestly, currently I couldn't think of any "magical twist", that makes the problems (model neutrality, legal pitfalls) go away.

Our perspectives seem to differ a bit - to me yours reads like
"is it technically feasible, is it fun to implement?"
while mine's rather
"do I want that in my browser and which problem does that solve, anyway?".
But that's only my interpretation, of course.

[firefoxwebdevs@mastodon.social]

@wcbdata @Vivaldi tagging the unimpeachable @brucelawson to answer that one.

[aedius@lavraievie.social]

@toldtheworld @firefoxwebdevs

Yes but it mean that they still burn money for crap.

[firefoxwebdevs@mastodon.social]

@xela eh I'd say my view is "is this good for the web?", and I don't think this API is. If the technical issues were sorted, then maybe it's worth another look, but like I said in the standards position, I think developer desire of this API is being massively overstated by Google.

[scudo@antani.cyou]

@firefoxwebdevs@mastodon.social the same guys that have put AI in Firefox said "we won't put AI in Firefox"

[toldtheworld@mastodon.social]

@Aedius @firefoxwebdevs ah, you mean during development? I suppose there's no good alternative right now; I can't imagine a browser developer not using LLMs for coding. The biggest problem I see arises from lack of transparency on energy usage (and environmental impact) on the part of providers. Blaming them would be more productive. If we can get them to report the true impact of each inference request, I'm pretty sure people will freak out and slow down.

[aedius@lavraievie.social]

@toldtheworld @firefoxwebdevs

The alternative is to continue the human development, lower the entry level for contribution.

LLM development is producing technical debt faster than ever before.

[placebo@mastodon.ie]

@stux @marc_eu @firefoxwebdevs if only you guys knew how many times I typed openai instead of openapi and vice versa

[yokhai@gaygeek.social]

@marc_eu if not for the fact that Mozilla ships Firefox with AI chatbots despite a majority of people telling them, "don't do that"...this *would* have been a noble cause.

[phl@mastodon.social]

@firefoxwebdevs @valpackett Incidentally that links to a github md file which itself says merely positive and links further to an issue with ONE comment, and a blog that doesn't exist — and two other things. That's not exactly overwhelming support and excitement.

[marc_eu@veganism.social]

@yokhai
Yeah, but in all fairness, they're focusing on only local LLM's and, more importantly they implemented a AI kill switch that turns every AI functionality off and is enabled (= no AI) by default.

[rejzor@mastodon.social]

@firefoxwebdevs Thing is, Google doesn't care what anyone thinks, especially not Mozilla unfortunately because they own the internet with Chrome. And they push shit that entirely benefits them and not the internet as ecosystem.

[yoasif@mastodon.social]

@marc_eu @yokhai None of their LLMs are local, what are you talking about?

PS: Link Previews is enabled by default (and is disabled by the kill switch - weird, right?): https://www.quippd.com/writing/2026/01/06/architecting-consent-for-ai-deceptive-patterns-in-firefox-link-previews.html

[techienotnetie@social.vivaldi.net]

@wcbdata @firefoxwebdevs @Vivaldi We have been disabling Gemini (GLIC) at compile-time for a while (and we needed to redo that recently after the Chromium team removed all the ifdefs). Several others features are disabled by overriding the "Is this feature enabled?" logic, and in this case, AFAICT this particular API depends on a component that is already disabled that way. (Actually disabling the code for most of those features when building would require hundreds of large and small patches, which would be a maintenance nightmare; I just tried that last week.)