LibertyNetLibertyNet Developers

AI assistant

Ask questions in the docs, and get code that actually runs. Plus what the assistant will refuse to write, and why.

Press ⌘K (or click Ask AI) anywhere in these docs. The assistant reads this entire documentation set and answers with sources.

Free to use, with a per-visitor rate limit. No account needed.

What it is good at

Finding the right page

"How do I check if a node is really online?" beats guessing which section that lives in.

Explaining an error

Paste an error code or a stack trace. Every error in this system has a documented cause and fix.

Writing starter code

"Give me a script that lists inference nodes in Asia and verifies them."

Answering what exists

"Can I transfer credits?" — a straight no, with the reason.

What it will not do

This is the part worth reading.

Warning

It will not write code against capabilities that do not exist.

Ask for a wallet transfer and you should get: there is no wallet system, no endpoint in this API moves value, here is capability status. Not a plausible-looking function that fails at runtime.

It will not present unwired values as measurements.

Ask for a credits balance and it should tell you the endpoint returns 0 with "source": "not_yet_wired" — meaning nothing is counting, not that you earned nothing — and show you the reader that surfaces the caveat.

It will not hard-code secrets.

Generated code reads keys from the environment or an OS keychain. A snippet that ships a literal key teaches every reader that literal keys are normal.

It will not disable identity verification.

There is no skipVerify option to suggest, in any SDK, by design.

How the guardrails work

Not by asking the model nicely. Three structural things:

  1. The docs it reads are honest

    Every capability carries a status badge derived from one machine-readable matrix, and a drift checker fails the build if a page disagrees with it. The assistant cannot learn from this corpus that credits work, because no page says they do.

  2. The SDKs refuse at runtime

    Even if the assistant generated ln.wallet.transfer(), it raises a NotYetWiredError naming the real status. The failure is loud, immediate and explanatory rather than silent.

  3. Assistants can check before asserting

    Via the MCP server, an assistant can call capability_status before writing code and verify_identity instead of eyeballing a DID.

Note

Point 1 is the one doing most of the work. An AI assistant is a mirror of its corpus — the real defence against a confidently wrong answer is a documentation set with nothing confidently wrong in it.

Getting better answers

Say which language and runtime

"In Python 3.11, list online nodes with the inference capability" beats "how do I list nodes". The SDKs differ in naming (freshness_s vs freshnessMs) and the assistant should not have to guess.

Paste the actual error, whole

Including the code and the docs link. Every SDK error carries both:

text NotYetWiredError [NOT_YET_WIRED]: ... → https://docs.libertynet.ai/status

Ask what is real before asking how

"Is X built?" is a cheap question with a definitive answer, and it saves you from a beautifully-written implementation of something that does not exist.

Ask it to verify

"Verify this DID against this key" is arithmetic — it has a right answer, and with the MCP server the assistant computes it rather than judging by appearance.

Use your own assistant instead

Everything here works better in a tool you already have open:

MCP server

Claude Desktop, Claude Code and Cursor get six tools — docs, status, live network, identity verification.

Raw context

llms.txt, per-page markdown, and what to paste into an assistant with no MCP.

If it gets something wrong

Tell us

A wrong AI answer usually means a documentation page is ambiguous. Report both — the fix is almost always the page, which fixes every future answer at once.