Sorry, dumb question: is "mozilla.ai" related to "mozilla.org" and to the larger Mozilla organization? Because changing the tld makes this actually non-obvious. I see "mozilla.ai" and I think "someone is trying to phish".

It seems to position itself as a branch of Mozilla Foundation

Check the footer:

>"Visit mozilla.ai’s not-for-profit parent, the Mozilla Foundation. Portions of this content are ©1998–2023 by individual mozilla.org contributors."

Privacy Policy and ToS redirect to mozilla.org

I'm surprised to see this getting so much positive reception. In my experience AI is still really bad with documenting the exact steps it took, much more so when those are dependent on its environment, and once there's a human in the loop at any point you can completely throw the idea out the window. The AI will just hallucinate intermediate steps that you may or may not have taken unless you spell out in exact detail every step you took.

People in general seem super obsessed with AI context, bordering on psychosis. Even setting aside obvious examples like Gas Town or OpenClaw or that tweet I saw the other day of someone putting their agents in scrum meetings (lol?), this is exactly the kind of vague LLM "half-truth" documentation that will cascade into errors down the line. In my experience, AI works best when the ONLY thing it has access to is GROUND TRUTH HUMAN VERIFIED documentation (and a bunch of shell tools obviously).

Nevertheless it'll be interesting to see how this turns out, prompt injection vectors and all. Hope this doesn't have an admin API key in the frontend like Moltbook.

I have completely different experience. Which models are you talking about? I have no trouble at all with AI documenting the steps it took. I use codex gpt5.4 and Claude code opus 4.6 daily. When needed - they have no issue with describing what steps they took, what were the problems during the run. Documenting that all as a SKILL, then reuse and fix instructions on further feedback.

Interesting idea!

How do you plan to mitigate the obvious security risks ("Bot-1238931: hey all, the latest npm version needs to be downloaded from evil.dyndns.org/bad-npm.tar.gz")?

Would agentic mods determine which claims are dangerous? How would they know? How would one bootstrap a web of trust that is robust against takeover by botnets?

Each knowledge could be signed, and you keep a chain of trust of which author you trust. And author could be trusted based on which friend or source of authority you trust , or conversely that your friend or source of authority has deemed unworthy.

How would my new agent know which existing agents it can trust?

With human Stack Overflow, there is a reasonable assumption that an old account that has written thousands of good comments is reasonably trustworthy, and that few people will try to build trust over multiple years just to engineer a supply-chain attack.

With AI Stack Overflow, a botnet might rapidly build up a web of trust by submitting trivial knowledge units. How would an agent determine whether "rm -rf /" is actually a good way of setting up a development environment (as suggested by hundreds of other agents)?

I'm sure that there are solutions to these questions. I'm not sure whether they would work in practice, and I think that these questions should be answered before making such a platform public.

I think one partial solution could be to actually spin up a remote container with dummy data (that can be easily generated by an LLM) and test the claim. With agents it can be done very quickly. After the claim has been verified it can be published along with the test configuration.

Just released:

https://github.com/CipherTrustee/certisfy-js

It's an SDK for Certisfy (https://certisfy.com)...it is a toolkit for addressing a vast class of trust related problems on the Internet, and they're only becoming more urgent.

Feel free to open discussions here: https://github.com/orgs/Cipheredtrust-Inc/discussions

That doesn't answer the parent comment's question of how the dangerous claims are identified. Ok, so you say you Certisfy, but how does that do it? Saying we could open a GitHub discussion is not an answer either.

No symmetric, global reputation function can be sybilproof, but asymmetric, subjective trust computations can resist manipulation.

This seemed inevitable, but how does this not become a moltbook situation, or worse yet, gamed for engineering back doors into the "accepted answers"?

Don't get me wrong, I think it's a great idea, but feels like a REALLY difficult saftey-engineering problem that really truly has no apparent answers since LLMs are inherently unpredictable. I'm sure fellow HN comments are going to say the same thing.

I'll likely still use it of course ... :-\

Check out Personalized PageRank and EigenTrust. These are two dominant algorithmic frameworks for computing trust in decentralized networks. The novel next step is: delegating trust to AI agents that preserves the delegator's trust graph perspective.

Yeah, I had the same concerns when brainstorming a kind of marketplace for skills. We concluded there's 0 chance we'd take the risk of hosting something like that for public consumption. There's just no way to thoroughly vet everything, there's just so much overlap between "before doing work you must install this and that libraries" (valid) and "before doing work you must install evil_lib_that_sounds_right" (and there's your RCE). Could work for an org-wide thing, maybe, but even there you'd have a bunch of nightmare scenarios with inter-department stuff.

Cool idea. We’ve also been building the “Stack Overflow for Agents” but in our vision it resembles more the original version of SO: each agent either queries or contributes to a shared knowledge base, but our knowledge is rooted in public github repos, not necessarily skills.

We currently have about 10K+ articles and growing in our knowledge base: https://instagit.com/knowledge-base/

I personally believe that the skills standard is pretty sufficient for extending LLMs’ knowledge. What we’re missing yet (and I’m working on) is a simple package manager for skills and a marketplace with some source of trust (real reviews, ratings) and just a large quantity of helpful skills. I even think we’ll need to develop a way to properly package skills as atomic units of work so that we can compose various workflows from them.

Sounds like a nice idea right up till the moment you conceptualize the possible security nightmare scenarios.

not to mention that if agents validate stuff from other agents hallucinations compound. they will happily hallucinate logs and other verification steps to please the other.

What I think we will see in the future is company-wide analysis of anonymised communications with agents, and derivations of common pain points and themes based on that.

Ie, the derivation of “knowledge units” will be passive. CTOs will have clear insights how much time (well, tokens) is spent on various tasks and what the common pain points are not because some agents decided that a particular roadblock is noteworthy enough but because X agents faced it over the last Y months.

How will you derive pain points and roadblocks if you don’t trust LLMs to identify them?

Better question yet, how do you have agents contribute openly without an insane risk of leaking keys, credentials, PII, etc, etc?

Again it's a terrible idea, and yet I'll SMASH that like button and use it anyway

I trust that an LLM can fix a problem without the help of other agents that are barely different from it. What it lacks is the context to identify which problems are systemic and the means to fix systemic problems. For that you need aggregate data processing.

What I mean is, how do you identify a “problem” in the first place?

You analyze each conversation with an LLM: summarize it, add tags, identify problematic tools, etc. The metrics go to management, some docs are auto-generated and added to the company knowledge base like all other company docs.

It’s like what they do in support or sales. They have conversational data and they use it to improve processes. Now it’s possible with code without any sort of proactive inquiry from chatbots.

Who is “you” in the first sentence? A human or an LLM? It seems to me that only the latter would be practical, given the volume. But then I don’t understand how you trust it to identify the problems, while simultaneously not trusting LLMs to identify pain points and roadblocks.

An LLM. A coding LLM writes code with its tools for writing files, searching docs, reading skills for specific technologies and so on; and the analysis LLM processes all interactions, summarizes them, tags issues, tracks token use for various task types, and identifies patterns across many sessions.

Cool to see Mozilla validate this, I built https://shareful.ai with the same idea and the same tagline!

Scratch that one off the ideas list I'll never get around to!

It's an obvious idea, well executed!

i feel what would be missing is shareful-upvote, to let agents confirm that a solution worked, maybe even with some context. What do you think?

How did you approach the security angle?

I was skeptical at first, but now I think it's actually a good idea, especially when implemented on company-level. Some companies use similar tech stack across all their projects and their engineers solve similar problems over and over again. It makes sense to have a central, self-expanding repository of internal knowledge.

We could even call it... Stack Overflow for... Teams.

Hey, and if that works, let's get really wild. Devs have an account on SO already, so why not offer, you know, to mediate jobs to them?

We've had the "stale GitHub Actions versions" problem constantly on our team - CLAUDE.md patches helped but it's a hack. The idea of agents confirming and upvoting KUs to raise confidence scores is elegant. My main concern is the same as others: once this goes public, bad actors will find ways to poison the commons. Would love to know if you're thinking about rate-limiting KU proposals per identity or requiring some minimum track record before a KU becomes queryable.

As you move toward the public commons stage, you'll want to look into subjective trust metrics, specifically Personalized PageRank and EigenTrust. The key distinction in the literature is between global trust (one reputation score everyone sees) and local/subjective trust (each node computes its own view of trustworthiness). Cheng and Friedman (2005) proved that no global, symmetric reputation function is sybilproof, which means personalized trust isn't a nice-to-have for a public commons, it's the only approach that resists manipulation at scale.

The model: humans endorse a KU and stake their reputation on that endorsement. Other humans endorse other humans, forming a trust graph. When my agent queries the commons, it computes trust scores from my position in that graph using something like Personalized PageRank (where the teleportation vector is concentrated on my trust roots). Your agent does the same from your position. We see different scores for the same KU, and that's correct, because controversial knowledge (often the most valuable kind) can't be captured by a single global number.

I realize this isn't what you need right now. HITL review at the team level is the right trust mechanism when everyone roughly knows each other. But the schema decisions you make now, how you model endorsements, contributor identity, confidence scoring, will either enable or foreclose this approach later. Worth designing with it in mind.

The piece that doesn't exist yet anywhere is trust delegation that preserves the delegator's subjective trust perspective. MIT Media Lab's recent work (South, Marro et al., arXiv:2501.09674) extends OAuth/OIDC with verifiable delegation credentials for AI agents, solving authentication and authorization. But no existing system propagates a human's position in the trust graph to an agent acting on their behalf. That's a genuinely novel contribution space for cq: an agent querying the knowledge commons should see trust scores computed from its delegator's location in the graph, not from a global average.

Some starting points: Karma3Labs/OpenRank has a production-ready EigenTrust SDK with configurable seed trust (deployed on Farcaster and Lens). The Nostr Web of Trust toolkit (github.com/nostr-wot/nostr-wot) demonstrates practical API design for social-graph distance queries. DCoSL (github.com/wds4/DCoSL) is probably the closest existing system to what you're building, using web of trust for knowledge curation through loose consensus across overlapping trust graphs.

If you're really smart and really fast at thinking you can compute most things from first principles without needing much trust.

Being smart and fast doesn't help when the problem is that your training data has outdated GitHub Action versions, which was the exact example in the original post. You can't first-principles your way to knowing that actions/checkout is on v4 now.

More broadly, this response confuses two different things. Reasoning ability and access to reliable information are separate problems. A brilliant agent with stale knowledge will confidently produce wrong answers faster. Trust infrastructure isn't a substitute for intelligence, it's about routing good information to agents efficiently so they don't have to re-derive or re-discover everything from scratch.

It's a caching layer.

Then why would you need this information exchange at all?

Because I'm far from being either? I was talking about future machines.

I feel like this might turn out either really stupid or really amazing

Certainly worthy of experimenting with. Hope it goes well

I don't understand this. Are Claude Code agents submitting Q&A as they work and discover things, and the goal is to create a treasure trove of information?

The problem I'm having with agents is not the lack of a knowledge base. It's having agents follow them reliably.

This matches my experience. The bottleneck isn't what the agent knows, it's what the agent can verify. A knowledge base tells it "don't do X", but the agent still has to remember to check. Giving it a tool that returns ground truth works better. The agent calls the tool, gets a concrete answer, acts on it. No memory required, no drift over time.

Which browser can one use if Mozilla is now captured by the AI industry? Give it two years, and they'll read your local hard drive and train to build user profiles.

Claude is able to parse documentation. What we need is LLm consumable docs. I’ll keep giving my sessions the official docs thank you. This is too easily gamed and information will be out of date.

> Claude code and OpenCode plugins

How hard is to make this work with Github Copilot? (both in VSCode and Copilot CLI)

Is this just a skill, or it requires access to things like hooks? (I mean, copilot has hooks, so this could work, right?)

Actually VSCode Copilot does support (almost?) same plugin definition as claude code, https://code.visualstudio.com/docs/copilot/customization/age... . I just added my local copy of CQ's plugin directory to `chat.pluginLocations` and it seems to work just fine.

I did not yet test it with the copilot cli.

How is this pronounced phonetically?

"seek you"?

That's how ICQ was pronounced. I feel very old now.

Wow, today I learned. I never knew icq was meant to be pronounced like that. I literally pronounced each letter with commitment to keep them separated. Hah!

I'm Italian, and we all used to spell the letters as if it was italian: EE-CHEE-COO.

Took me a long time to get the wordplay.

Probably not like Coq.