d-inference: Darkbloom's Apple Silicon provider for local model serving

What lives in the d-inference repository

This repository is the Darkbloom provider. It holds the Apple Silicon provider, the native inference runtime integrations and the marketing site, and it also retains a console source snapshot together with its existing build, test and hosting configuration. The provider runs models locally with MLX, and it can either connect to the Darkbloom network or serve a local OpenAI-compatible API.

The name is misleading if you meet it without context. The repository is called d-inference and its topic is a private inference network on idle Macs, but the code inside is the provider half of a two-repository project, and the first section of the documentation is about keeping the two apart.

The tree at the top of the repository shows the intended arrangement, with sibling checkouts and never one repository nested inside the other:

Darkbloom/
  d-inference/          Swift provider, local native APIs, MLX and landing
  darkbloom-platform/   Coordinator, prompt sidecar, consumer console and admin

The division is a governance decision as much as a technical one. Centralized backend, console and admin code belongs exclusively in darkbloom-platform, and the documentation states plainly that new backend, console or admin code should never be implemented, committed, pushed or uploaded in this repository. The retained `console-ui/` snapshot stays locally available, but retaining it does not transfer new development ownership back from the platform.

The top level of the tree itself gives a sense of scale. Alongside `provider-swift/`, `libs/`, `landing/`, `console-ui/`, `coordinator/`, `docs/`, `fixtures/` and `scripts/` there are `infra/`, `papers/`, `reports/`, `status/`, `output/`, `automations/`, `changelog.d/`, a `JOURNAL.md`, an `AGENTS.md`, a `mise.toml` and a `Makefile`.

The project is written in Swift, the site is at darkbloom.dev, the repository is not archived, and the last push was on 2026-10-20.

The provider is the plaintext inference endpoint, and the docs say so

The most valuable paragraph in this documentation is the shortest. The provider is the plaintext inference endpoint, and network encryption does not hide prompts from that process or from the coordinator's transient request processing. The documentation then points at the encryption and storage trust model and at provider attestation, and adds a warning not to infer security guarantees from a repository split.

That warning is aimed at readers who saw two repositories and assumed a security boundary. It is a fair assumption to make and an expensive one to hold. Splitting source ownership says who may commit where, which is a process control. It says nothing about where a prompt exists in memory, who can read it while it is being processed, or how long the coordinator keeps it around.

So the honest picture of the trust model has three parts. The provider holds the plaintext because that is where inference happens, and the model weights are local. The coordinator handles requests in transient form. The transport between them can be encrypted without changing either of the first two facts. Provider attestation is the mechanism the documentation points at for the device side, and its details live in a separate document rather than in this repository's overview.

The cache storage documentation is the other place the boundary is drawn more concretely, and it covers encrypted SSD storage and daily write limits. Encryption at rest on the device and encryption in transit between machines are two different properties, and this project distinguishes them rather than using one word for both.

The practical consequence for a reader: if you are evaluating this for prompts you cannot afford to have sit in plaintext anywhere, the answer is not in the repository layout, and the files to read are docs/architecture/security/encryption.md and docs/provider/attestation.md.

Building the Swift provider and running its tests

Development is driven by mise for tool versions and make for the commands. The documented sequence is:

mise install
make provider-build
make provider-test
make ui-install ui-lint ui-test ui-build
make landing
make docs-check

`make provider-build` compiles the Swift provider CLI with its source-matched metallib. The build itself is a Swift Package Manager build inside `provider-swift/`, followed by a script that fetches the metallib into the binary path that `swift build --show-bin-path` reports. The metallib is the compiled Metal shader library, and the point of the script is that the shader binary has to match the source revision that produced it, which is a detail that only matters if you have been burned by a stale shader.

`make provider-test` is heavier. It runs a Python check over the protocol fixture resources, stages test metallibs, stages SwiftPM resource bundles, builds the test target, stages the test metallib and then runs the provider test script from the parent `scripts/` directory. The test run therefore depends on a build with matching metallibs, which is why the target does not simply call `swift test`.

The Makefile also exposes targets with no GPU or weights attached: `benchmark-wrapper-test` unit-tests the benchmark wrappers, and the target list includes `benchmark-gemma-contbatch`, `docs-check`, `docs-impact-check`, `docs-stamp`, `changelog-check` and `changelog-preview`. A `help` target prints the list of targets with their descriptions, which is the fastest way to see what the project expects you to run.

The build requirements are stated and they are not negotiable: provider builds require Apple Silicon, the documented Xcode toolchain, and the recursive MLX dependencies. The MLX dependencies are pinned under `libs/`, and the presence of a `.gitmodules` file at the top level suggests they arrive as submodules rather than as vendored copies, so a clone without submodule initialisation will not build.

The documentation is also careful about what the test evidence means. Public golden vectors check fixed expected behaviour, and the documentation says explicitly that they are not private cross-implementation qualification and not live fleet evidence. That is a distinction worth keeping in mind, because a green test run tells you the provider matches recorded expectations, not that it matches another implementation or that it behaves the same way on a real network.

Running a provider: direct mode, hardware fit and cache storage

The operational documentation is split into several files under `docs/provider/`, and the entry point is installation followed by the quickstart.

Direct mode is the local path, and it is the one to understand first, because it is the mode with the fewest moving parts: local inference, no network involvement, and the provider serving an OpenAI-compatible API on your own machine. The value of that endpoint is that any client that already speaks the OpenAI API shape can point at it, which turns a local Mac into a drop-in backend for a tool that expects a hosted model. The OpenAI-compatible framing is the interoperability contract, and the documentation states that the provider can either connect to the Darkbloom network or serve that local API.

Hardware requirements is a separate document, and the project's topic gives the reason: the point of the network is to use idle Macs. A provider has to fit a model on the machine it is running on, so the document is about model fit rather than about installation. If you plan to run a large model on a laptop with a small unified memory budget, that document is where the answer is.

Cache storage is the third, and it is the one with a number attached. It covers encrypted SSD storage and daily write limits. The write limit is the detail that changes behaviour: a provider that downloads and caches model weights writes to disk in a way that can be bounded per day, which matters on a shared or metered connection, and it is not something you would infer from the phrase private inference.

The top level of the repository also carries `fixtures/` described as public, revision-bound test inputs, `scripts/` for provider builds, native qualification, install and publication helpers, and `docs/` for provider and native explanations, references, operations and historical evidence.

Source ownership is not deployment authority, and the changelog is not a release record

Two lines in the documentation deserve separate treatment because they are about how the project is run rather than about what it contains.

The first is that source ownership does not grant deployment authority. Infrastructure, hosting and traffic changes require specific human approval, and release and model registration remains an external API operation. In other words, having the right to commit to the provider repository does not give you the right to put a node on the network, and registering a model with the coordinator is something done outside the code. For a distributed system where each node holds a copy of a model, that separation is sensible: the code that runs inference is not the code that decides who runs inference.

The second is about the changelog. The existing changelog history in CHANGELOG.md remains a record of work before and after the ownership split, and the documentation says it is not evidence of a new release or deployment. The repository also has a `changelog.d/` directory and `changelog-check` and `changelog-preview` make targets, which suggests a fragment based changelog workflow alongside the historical file.

Both statements exist because inference about the project from its artefacts is easy to get wrong. A large changelog does not mean many releases, and a split repository does not mean a split trust boundary.

On the release side, the tagged versions are frequent: v0.9.20 on 2026-10-12, v0.9.21 on 2026-10-14 and v0.9.22 on 2026-10-15, with the last push on 2026-10-20. The version numbers are still below 1.0, which is the usual signal that the interfaces are expected to move.

A custom licence that no standard label describes

The licence is not one the platform could classify. The project is listed under a custom licence with the instruction to see the LICENSE file, and the documentation points at both LICENSE and ACKNOWLEDGEMENTS.md. It also states that the published privacy policy and terms of service remain unchanged by the source cleanup, with those documents living under `docs/legal/`.

That combination is worth a moment of thought. A custom licence is common in a project that mixes open source components with a commercial service, and this repository does exactly that: it contains provider code that is open, a `landing/` marketing site, `console-ui/` code, and links to a hosted platform. The ACKNOWLEDGEMENTS file exists to record third-party components, and the `libs/` directory holds pinned native MLX dependencies with their own licences. Neither the AGPL nor the MIT nor any other label describes the terms, so any summary of the licence derived from a badge or a classifier is wrong by construction.

The practical rule is narrow and firm: read LICENSE and ACKNOWLEDGEMENTS.md, and if you intend to run the provider against sensitive data, check the terms of service and the privacy policy as well, because the licence governs the code and the terms govern the service. That is not a legal opinion, just a reading of where each document sits in the repository layout.

There is a second reason the licence matters here. The provider is the point where plaintext prompts exist, and the obligations you take on when you deploy a node are set by the licence and the terms rather than by the fact that the code is publicly visible.

Where d-inference is the wrong tool

The first limit is hardware. Provider builds require Apple Silicon, the documented Xcode toolchain and the recursive MLX dependencies, and the hardware requirements document exists because model fit is the binding constraint. On a machine without Apple Silicon, or with a unified memory budget that cannot hold the model you want to serve, this is not a slow path, it is not a path.

The second limit is the plaintext endpoint. If your requirement is that prompts never exist in plaintext outside your own control, the documentation rules this project out as stated. It says so itself, and it points you at the encryption and storage trust model and at provider attestation, which is the right place to look for what the project does offer.

The third limit is scope. Centralized backend, console and admin code lives in a different repository, and this one is explicitly not the place for it. If your task is to change the coordinator, the consumer console or the admin surface, you are looking at the wrong checkout, and the documentation says to contact the maintainer or open an issue for substantial work rather than to start implementing.

The fourth is the testing evidence. The golden vectors are described as checking fixed expected behaviour and explicitly not as cross-implementation qualification or live fleet evidence. If you are qualifying a provider against another implementation for a procurement or compliance decision, this repository's test suite is not that evidence, and the documentation does not claim it is.

Compare that with running the model yourself on a single machine with a local serving tool, where you own the weights, the process and the storage, and no network layer is involved at all. The difference in approach is that d-inference adds a distributed model of idle machines contributing to a shared network, along with the coordinator, the attestation and the registration steps that a network implies, and it buys back the ability to serve a model you do not own hardware for. If your problem is one machine, the network is a complication you do not need.

Editorial conclusion

d-inference fits an engineer on an Apple Silicon Mac who wants to serve a model locally through an OpenAI-compatible endpoint or contribute to the Darkbloom provider, and the Swift provider, the pinned MLX dependencies and the source-matched metallib build are real engineering rather than a wrapper script. It does not fit anyone who assumes the repository split delivers confidentiality, because the documentation states the provider is the plaintext inference endpoint and that network encryption does not hide prompts from that process or from the coordinator's transient request processing. Before you build it, read docs/architecture/security/encryption.md and docs/provider/attestation.md, and treat the LICENSE file rather than a licence identifier as the source of truth, since the terms are custom and cannot be summarised from a standard label.

Frequently asked questions

Official sources

1. Issues
2. Layr-Labs/d-inference on GitHub
3. Project website
4. README
5. Releases