Private beta
-Connect private beta
++ When an app asks to use a collection, Connect shows whether it wants + to view, change, or delete records. You choose the collection and can + change or revoke access at any time. +
+ -- Start in the app you want to use. mdbase Connect opens when that app - needs a collection, shows what it is asking for, and lets you choose - the folder or hosted collection it can use. -
- + +Access request
+Project app
+For people using apps
-- Connect keeps the same request open while it helps you sign in, pair this - computer, and choose or create a collection. -
-How it works
+- A collection kept on your computer remains ordinary Markdown in the - folder you chose. The app and account service do not receive that - folder path. + Connect keeps the request open while you sign in, choose a collection, + and decide what the app may do.
-For developers
-- Connect is optional. Applications can also use a conforming mdbase - implementation directly. Connect provides a common approval and routing - path when independent applications need access to a user's collections. -
-+ The request names the app and the actions it needs. The app cannot + use a collection before you make a decision. +
++ Use a folder on this computer or a hosted collection. Remove any + requested permissions you do not want to grant. +
++ The approved access stays attached to that app and collection. You + can narrow, pause, or revoke it later. +
+- Applications use the same SDK and operation envelopes. Routing changes - according to which connector or provider currently holds the collection's - authority. -
-| Authority | -Where Markdown lives | -Application route | -What the control plane sees | -
|---|---|---|---|
| Local connector | -A folder on the user's computer | -Direct loopback, then encrypted relay fallback | -Account, grant, operation name, routing metadata, timing, and sizes | -
| Hosted provider | -Encrypted provider storage, with optional local mirror | -Direct, short-lived provider capability | -Account, grant, capability issuance, and provider routing metadata | -
- The provider must decrypt collection data to execute canonical mdbase - operations. The provider acts as a trusted data processor for hosted - collections. -
-- Authority is a coordination role, not the only copy of a collection. - Writable mirrors can keep ordinary Markdown on several devices, accept - changes while offline, and synchronize them later. One authority orders - the final accepted changes, enforces collection-wide rules, and gives - every mirror the same history to converge on. -
-- Removing that role would not remove coordination. It would require every - peer—including filesystem editors that only know how to rewrite a - Markdown file—to preserve causal history and agree continuously about - concurrent edits, renames, deletes, schema changes, revocation, and - garbage collection. -
-| Concern | -Equal peers would require | -One movable authority provides | -
|---|---|---|
| Ordinary Markdown tools | -CRDT or event metadata preserved by every writer | -Open files remain the editable local format | -
| Concurrent changes | -A deterministic merge for every body and frontmatter value | -Revision checks, durable mutation receipts, and explicit conflicts | -
| Renames, deletes, and configuration | -Distributed agreement over paths, tombstones, schemas, and constraints | -One canonical order for collection-wide decisions | -
| Offline devices | -Split-brain reconciliation and peer-membership machinery | -Queued local work that safely converges when the mirror reconnects | -
Where your collection lives
+- Authority transfer preserves the collection and record identities, - advances an authority epoch, and retires the previous authority. When - the previous authority was a local folder, that folder can continue as - a mirror. A stale authority cannot accept writes after cutover. + Apps use the same approval flow in both cases. The location of the + collection determines which component can open the records and execute + approved operations.
-{step.copy}
-On this computer
++ In an ordinary folder you choose. The files remain available to + your text editor and other local tools. +
++ The local connector and apps using an active grant. The Connect + control plane cannot read local operation payloads or results. +
+- Connect limits the components that can read records. Local and hosted - collections have different trust boundaries. -
-| Component | -Can read collection records? | -Responsibility | -
|---|---|---|
| Application | -Only through its current grant | -Uses authorized results and protects its local SDK credentials | -
| Local connector | -Yes, for registered local collections | -Final local authorization boundary and operation executor | -
| Connect control plane | -No local operation payloads or results | -Identity, pairing, grants, short-lived tokens, and relay routing | -
| Hosted provider | -Yes, for hosted collections | -Encrypted storage, canonical execution, sync, and durable receipts | -
Release status
-- The private-beta stack includes local and hosted authorities, encrypted - relay operations, grant narrowing and revocation, sync, notifications, - the browser SDK, and key-bound authorization for downloaded HTML files. - The npm packages have not yet received their first public release. Public - registration, a production restore drill, signed desktop releases, and - abuse-response operations are still required before public registration. -
- diff --git a/src/pages/sdk/contracts/index.astro b/src/pages/sdk/contracts/index.astro index 9ce3b2d..1bdf2c5 100644 --- a/src/pages/sdk/contracts/index.astro +++ b/src/pages/sdk/contracts/index.astro @@ -152,7 +152,7 @@ export class WorklogCollection {Event sources and action providers declare executable implementations - through the interoperability bridge, not through a - type file. + through the interoperability bridge, not + through a type file.
diff --git a/src/pages/sdk/index.astro b/src/pages/sdk/index.astro index 53beba7..89688da 100644 --- a/src/pages/sdk/index.astro +++ b/src/pages/sdk/index.astro @@ -34,12 +34,12 @@ export async function listOpenTasks(client: MdbaseCollectionClient+ The current site records mdbase specification 0.3.0 claims for the + TypeScript 0.3.0-rc.4 and Rust 0.4.0-rc.3 implementations, with evidence + dated 29 July 2026. Review conformance resources.
This example uses the real typed collection client and the deterministic
developer sandbox. It keeps every record in memory and makes no network
diff --git a/src/pages/testbed/index.astro b/src/pages/testbed/index.astro
deleted file mode 100644
index b01002a..0000000
--- a/src/pages/testbed/index.astro
+++ /dev/null
@@ -1,573 +0,0 @@
----
-import BaseLayout from "../../layouts/BaseLayout.astro";
-import CodeBlock from "../../components/CodeBlock.astro";
-
-const runCommand = `npm install --save-dev @callumalpass/mdbase-testbed
-
-npx mdbase-testbed validate
-npx mdbase-testbed run \\
- --adapter ./scripts/testbed-adapter.mjs \\
- --evidence ./conformance/testbed-evidence.json`;
-
-const protocol = `your-adapter describe
-# writes one adapter-description JSON document
-
-your-adapter run
-# reads one scenario request from stdin
-# writes one observable transcript to stdout`;
-
-const rings = [
- {
- id: "contract",
- number: "01",
- title: "Contract",
- count: 1,
- summary: "One contract, one implementing type, one record, two consumers.",
- scenarios: [
- ["core.shared-contract-consumers", "Both consumers receive the same validated contract view."]
- ]
- },
- {
- id: "interop",
- number: "02",
- title: "Interop",
- count: 11,
- summary: "Live sources, consumers, callers, and providers cross an authorization boundary.",
- scenarios: [
- ["interop.event-multicast", "One event reaches every compatible consumer."],
- ["interop.action-single-provider", "One eligible provider is selected."],
- ["interop.action-ambiguous", "Two eligible providers stop implicit dispatch."],
- ["interop.action-explicit-provider", "An explicit selector resolves ambiguity."],
- ["interop.provider-disappearance", "An unloaded provider is unavailable."],
- ["interop.contract-digest-drift", "Same version with a different digest is rejected."],
- ["interop.invalid-payload", "Schema-invalid data never reaches a handler."],
- ["interop.authority-boundary", "Compatibility cannot grant authority."],
- ["interop.request-replay", "A logical request is not applied twice."],
- ["interop.application-provider-lifecycle", "A real app provider registers, validates, runs, and unloads."],
- ["interop.application-event-multicast", "A real app source reaches two independent consumers."]
- ]
- },
- {
- id: "runtime",
- number: "03",
- title: "Runtime",
- count: 3,
- summary: "Durable admission, recovery, and worker fencing are observed through the store.",
- scenarios: [
- ["runtime.crash-recovery", "A lost outcome reuses the same attempt and invocation."],
- ["runtime.competing-workers", "A stale worker cannot commit after its lease expires."],
- ["runtime.application-execution", "A real app catalog produces one exact successful run."]
- ]
- }
-];
----
-
- Portable testbed 0.1
- One neutral suite tests TypeScript, Rust, plugins, desktop services,
- and future implementations through a process boundary. Products keep
- their own architecture; users get comparable evidence.
- The black-box boundary
- Each scenario starts a fresh adapter process. Only stable facts cross
- the boundary; generated IDs, database keys, and wall-clock timing stay
- inside.
-
- Draft 2020-12 schemas define neutral fixtures, run requests, adapter
- descriptions, transcripts, and evidence. Every expected transcript
- lives beside its scenario.
-
- An adapter drives public collection, bridge, provider, runtime, and
- store boundaries. It reduces observations to stable facts; it does
- not reimplement the feature.
-
- Passing proves behavior, not permission. A transcript cannot grant
- access, register a provider, publish an event, or authorize a side
- effect.
- 15 scenarios · 3 rings
- Small scenarios isolate failures. Application scenarios then repeat
- the critical paths with real product contracts and providers.
- {ring.summary} Fresh process per scenario
- The runner launches an executable directly—never through a shell—and
- validates both sides of every exchange before comparing observations.
-
- A passing run can emit a machine-readable evidence document containing
- the implementation identity, scenario IDs, profile names, and canonical
- transcript digests. Attach it to a conformance claim to make the tested
- behavior reproducible.
-
- A complete profile claim still runs every normative conformance test
- for that profile. The testbed adds cross-language behavioral evidence;
- it does not silently widen the claim.
-
-
-
-
- Make the same promise. Prove the same behavior.
-
-
-
-
-
-
- The spec asks. Your implementation answers.
-
-
-
- Neutral scenario
- Process adapter
- Canonical transcript
-
- {
- rings.map((ring) => (
-
-
- ))
- }
-
- {ring.number}
- {ring.title}
-
-
-
-
-
- describe
- run
- PASS{String(ring.count).padStart(2, "0")}
- What the testbed separates
-
-
- The question and the oracle
- The behavior under test
- Authority
-
-
-
-
- The portable inventory
-
- {
- rings.map((ring) => (
-
-
-
- {ring.count}
- {ring.title}
-
- {
- ring.scenarios.map(([id, description]) => (
-
- {id}
- {description}
-
-
-
-
- Run it from any language
-
-
-
-
-
- Install and verify
-
-
- Implement two commands
- Evidence is precise—and deliberately limited
-
- Supplemental evidence, not a blanket badge
-
-