
Before your first PR on a Nano Collective project, read the Economics Charter. It spells out scope-before-money, that nothing is paid retrospectively, and how a bounty actually gets agreed. Ten minutes of reading now is weeks of mismatched expectations avoided later.



The default deal with sponsors is quiet influence. Bigger cheque, softer feedback, roadmap drifts toward the money.

At the Nano Collective, sponsors fund the work and do not direct it. Written on the sponsor page, same on every surface, enforced as a hard rule.


Before you write a whitepaper, raise the idea. Discord, the docs repo, or the organisation repo: any of the three. Most answers are yes, and the rest save you a month of writing for an idea that was never going to fly.



The reflex: durable OSS needs a backer. A corp, a foundation grant, something.

The Nano Collective has none of those. No investors. No equity. No profit-taking. Fiscally hosted by Open Source Collective. Books public, on the ledger, in real time.



A whitepaper the original author abandons usually dies. At the Nano Collective it doesn't. Add your name as proposer in the file, open an issue, carry on. 60 days idle and it goes to Paused, not to the bin. Someone else can pick it up.



Converting your own HTML to Markdown shouldn't need a cloud account. get-md's local LLM path runs ReaderLM-v2 on-device via node-llama-cpp. No API key, no round-trip, no quota. The principle: tools that touch your files should run on your hardware.


The reflex is to throw an LLM at HTML-to-Markdown. get-md ships Turndown + Mozilla Readability as the fast path instead, sub-100ms per page, deterministic, zero API spend. An LLM mode is there for when the structure actually needs it.


DOM parsers assume a browser. JSDOM assumes Node. Mobile apps get a fork.

get-md ships against happy-dom-without-node instead, so the same convertToMarkdown() runs in Node, in a React Native app, and in the browser. One call, three runtimes, no platform branch.


Most tools treat a sitemap like an open tap. get-md ships --max-urls, --max-depth, and repeatable --include/--exclude globs by default, so the crawl has a kill switch before it starts.


Most HTML-to-markdown tools hand you the page chrome and let a regex clean it up after.

get-md runs Mozilla Readability first. The extraction layer throws the chrome out, then Turndown sees only the article. Clean at the content layer, not at the markdown layer.



Parsing error messages in a catch block is a smell. json-up throws 3 named errors - ValidationError, MigrationError, VersionError - so you branch on the type, not the string.



The reflex for JSON versioning is a schema table in the database next to the rows. json-up puts `_version` on the data itself and treats unversioned input as v0. The migration ships with the file, no schema table, no coupling, works the same on disk, in a blob, in a local store.



Two functions and a builder, that's the whole sync API in json-up. createMigrations().add().add().build() and migrate({state, migrations}). The surface is small because the problem is small.


The reflex is migrations in a separate CLI or service, far from the code that reads the data. json-up keeps them in the consuming repo as a Zod-typed chain, so schema, migration, and reader age together instead of drifting apart.



0. That's the version json-up assigns your JSON when there's no `_version` field - and it runs every migration in your chain to catch it up. Legacy data stops falling through.



Your coding agent's scheduler should live on your machine, not someone else's cloud.

Nanocoder ships a per-project daemon that fires commands on file changes and cron, with no TUI open and no remote worker involved.


Picking up a new editor shouldn't mean rebuilding your agent integration from scratch. Nanocoder speaks ACP, so it slots into Zed as a native agent with a single settings.json entry - no per-editor extension, no rewrite.



Four extension systems is three too many.

Nanocoder collapses commands, subagents, tools, and event triggers into one primitive: a Skill. One .md file, or one bundle under .nanocoder/skills/, same surface either way.



You paste real code into a coding agent every day. You do not want it phoning home. Nanocoder ships zero telemetry, zero install ping, zero usage metrics, so the whole loop runs on a local model with no outbound traffic at all.



A 4B model carrying a 700-token system prompt has forgotten the question by the second tool call.

Nanocoder's /tune auto-resolves: 4B and below get nano, 15B and below get minimal, no config to set.



A fine-tuned model you can actually run at home: `nanotune train`, then `nanotune export` fuses the LoRA into the base and writes GGUF directly. Drop the file in Ollama, no cloud, no PyTorch, no llama.cpp build. The laptop does the whole loop.


"Write a haiku about coding" breaks string-match benchmarks. Default modes like contains or startsWith score CLI answers fine, fail on open-ended output. Nanotune ships an LLM-as-a-judge for those: configurable criteria, 0-10 scores, reasoning per criterion.


A fine-tune producing nonsense almost always traces back to silent data bugs. Run `nanotune data validate` before `nanotune train`: duplicates, broken role alternation in multi-turn JSONL, missing context messages. Seconds of work, hours of debugging later.


Hearing "fine-tune a model" and reaching for an A100 rental is the default. Nanotune runs LoRA on Apple Silicon via MLX, with a guided install that handles the setup. No remote runner, no spot instance, just your Mac.


Your first benchmark on a new Mac should not end in an OOM, and you should not need a cheat sheet for threads, GPU layers, and ctx-size. Nanotune ships presets. `nanotune benchmark --preset medium` sets sane defaults for a modern laptop, so it finishes.



A VPN, Tor, or a proxy hides the route. None rewrite email, path, or API key in the prompt.

prompt-scrub fixes the leak at the content layer: identifiers become placeholders before they leave the machine, then rehydrate locally. Compose it with any network tool you trust.



Eight detectors, one priority chain, and the order is the point.

prompt-scrub puts SecretDetector first because missing a credential is worse than missing a name. Then Email, URL, Path, Phone, Address, Name, CodeTell. Overlapping spans resolve by priority, not detector race.


1 byte off, and the cache misses. prompt-scrub's scrub() is byte-stable per session, so placeholder order stays fixed and prompt caches stay hot. inspect --hash prints the SHA-256 so you can check.



Your `ls` output is part of your prompt. So is `git log`, `cat`, and `grep`.

prompt-scrub runs on every message regardless of origin. Tool results get scrubbed before the next LLM turn, not just what you typed.

The leak surface is the whole conversation, not the user input.


The detector set shouldn't grow by patching the engine. prompt-scrub ships detectors as npm rule packs, so a domain-specific check is a package that exports a Detector array, not a fork. The principle: the core stays small, the rules travel.