Packages, imports, and trust

The o keyword DONE

o is U's import and export mechanism. One keyword, several forms:

// Import a local module:
o "./router"              // makes router's exports available
o "./types"               // imports types (classes, type aliases)

// Import from the registry:
o "http"                  // resolves via u.json dependencies
o "json"

// Import with capability grant (JIT plugins):
plugin = o("./user-plugin.u", {
    Templates,               // grant: can use template tags
    Network.LLM.Summariser   // grant: can call the LLM
    // NOT granted: FileSystem, Network.HTTP
})

// Export from a module:
o => d Config              // declare and export in one line
    host: S
    port: I

o Router => (              // export a namespace
    f match(path: S) -> Route +N
    f add(path: S, handler: Handler)
)

Cross-module types resolve at compile time. The compiler receives all files as a bundle via /compile_project and resolves the full dependency graph before type-checking any file. A type declared in types.u is available everywhere that imports it — no forward declarations, no header files.

Package structure DONE

Every U project has a u.json at its root:

{
  "name": "my-app",
  "version": "1.0.0",
  "entry": "src/main.u",
  "dependencies": {
    "http": "^1.2.0",
    "json": "^0.9.0",
    "acme-auth": "git:github.com/acme/auth-u#v2.1.0"
  },
  "capabilities": {
    "allow": ["+IO", "+Net", "+DB"],
    "deny": ["+Exec", "+Unsafe"]
  },
  "trust": {
    "require": 2,
    "keys": ["developer.pub.pem", "auditor-1.pub.pem"]
  }
}

capabilities.deny is a hard constraint: any dependency — direct or transitive — that uses a denied capability fails at u install time. Not at runtime, not at code review.

Dependencies can come from the registry ("^1.2.0"), a git tag ("git:..."), a local path ("path:../shared"), or a direct URL. All sources require signature verification — the manifest travels with the package.

The lockfile (u.lock) records the exact version, hash, capability surface, and signer list for every resolved dependency. Same lockfile = same build = same binary.

M-of-N signing DONE

Every published package has a manifest listing every source file's SHA-256 hash, the capability surface, and cryptographic signatures. A signature covers file hashes AND the capability declaration — if the maintainer adds +Exec in a patch release, old signatures don't cover the new manifest.

require: 2 means the maintainer alone can't push a compromised version. A single auditor alone can't either. npm's trust model is "whoever has the npm token." U's trust model is M-of-N, from the start.

New packages start at require: 1. The registry displays signature counts as a trust score. Downstream projects set their own floor. Nobody dictates the trust level — it emerges from actual adoption.

Capability auditing DONE

Every package declares its capability surface, and the U compiler verifies it. +Net means the code makes network calls. Pure means it can't exfiltrate data, phone home, or write to disk.

$ u update analytics-sdk
analytics-sdk 2.0.0 → 2.1.0:
  Capabilities: [+Net] → [+Net, +IO]
  ⚠️  NEW CAPABILITY: +IO (filesystem access added)
  Changed files:
    src/cache.u: added filesystem.write() for local caching
  Signatures: 1 (maintainer only)
  ❌ Below trust threshold (require: 2, have: 1)

The manifest trail tells you things even without reading source:

v1.0.0  caps: []           sigs: 1   installs: 47
v1.1.0  caps: []           sigs: 2   installs: 1,203
v2.0.0  caps: [+Net]       sigs: 3   installs: 4,271
v2.0.1  caps: [+Net, +IO]  sigs: 1   installs: 12    ← red flag

A pure library adding +IO in a patch release with one signature is machine-detectable. No human review needed for that signal.

Who pays for audits

The hard problem with code auditing is economics. Maintainers don't have budget. U's answer: the demand side pays — through micropayments at deploy time, proportional to actual production usage.

Phase 1: Sponsored NOW

The U project runs LLM audits for free on every published version. A 500-line U package costs pennies to audit with a frontier model. The registry shows signature counts and capability diffs. This bootstraps the ecosystem with no payment infrastructure.

Phase 2: Safebux micropayments NEXT

When the registry outgrows sponsorship, developers pay at deploy time. Safebux handles amounts below credit card minimums — fractions of a cent per install.

$ u deploy --production
  http-client 1.3.0   2 sigs   [+Net]      funded ✅
  analytics   2.1.0   1 sig    [+Net,+IO]  underfunded ⚠️
    audit fund: $0.03 / $0.12 needed
    27 production installs this month
    Contribute $0.002? [Y/n]

Each production install contributes to the package's audit pool. When the pool crosses the cost of an LLM audit, it triggers automatically. When it crosses the cost of a human audit, a bounty is posted to the auditor marketplace.

Public projects citing public dependencies is just a dependency graph — useful transparency. Private projects contribute anonymously: the registry sees the total fund balance and install count, not who paid. OpenClaiming receipts prove the payment cryptographically without identifying the payer.

Phase 3: Intercloud currencies FUTURE

A Safebox processing $50K/day in community currency has more at stake than a dev blog. Intercloud currency volume through a Safebox is a real-time measure of economic value at risk. The audit micropayment scales proportionally — the contribution is organic, not imposed.

The emergent outcome

Nobody decides "this package needs 3 auditors." Production installs drive funding. Funding drives audits. Audits produce signatures. A critical infrastructure package installed by 10,000 production systems accumulates enough funding for continuous LLM auditing plus periodic human review. A niche utility used by three people has one signature and that's proportional to the risk. Like price discovery, the trust level is discovered by actual demand.

Production deployment WIP

u deploy is the production gate. It does everything u install does, plus:

Commands WIP

u init                      # create u.json
u install                   # resolve, verify signatures, fetch
u install http@^1.2         # add dependency
u update                    # update within semver + trust
u audit                     # capability diff since last lock
u audit watch "pkg-*"       # subscribe to changes (auditors)
u sign                      # sign the project manifest
u publish                   # push to registry
u deploy --production       # verify + fund + deploy
u trust add KEY             # add a trusted auditor key
u trust show                # show policy and auditor status
u build                     # compile project
u run                       # build + execute
u test                      # build + run tests

Roadmap