# flybrainlabs node is an authority service assembled from pinned components

> The flybrainlabs node repository holds the authority and service APIs behind flybrain.work, but it cannot be built on its own: the sources are checked out and assembled by a separate infra workspace with pinned commits. It suits contributors already inside that monorepo setup, and it does not suit someone looking for a standalone clone and run.

**flybrainlabs/node** — flybrainlabs authority nodes, complete simulation replay, archives, and service APIs.

- Repository: https://github.com/flybrainlabs/node
- Website: https://flybrain.work/
- Stars: 780 · Forks: 53
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/flybrainlabs-node

## An authority service that only exists as a component

The flybrainlabs node repository is described as the authority and service APIs for flybrain.work, and its scope is unusually broad for something that looks like one service. It covers durable goal competition, commit and reveal processing, full replay coordination, private artifacts, scientific publication, customer tickets and accounting APIs. What it is not is a self-contained application you can clone and run. The README is direct about this: each imported file has one owning repository, component.json maps maintained files into the shared build layout, and dependencies are pinned by commit in an infrastructure release manifest. Cloning this repository alone does not supply its external components. That makes the project interesting but awkward. The interesting part is that it implements an authority model where goals compete, commitments are revealed, and replays are coordinated, with an economic ledger and a market catalog sitting underneath. The awkward part is that the unit of work is a component within an assembled workspace rather than a repository you can build alone.

## The source map tells you which files you actually own

The source map is short and it is the most useful thing in the README for anyone landing in the repository. The listed entries are src/target_authority.rs, src/product.rs, src/economic_ledger.rs, the src/market/ directory, and config/. Those five locations cover the authority service, the product service, the economic ledger, the market and the configuration. The repository layout at the top level backs that up, with src/, tests/, tools/, web/, config/ and a component.json that describes the mapping. The Cargo manifest names the crate flypow, version 0.1.0, with publish = false, which is a strong signal that this crate is never meant to reach a registry. The workspace lists ten members, including crates for receipts, simulation core, task catalog, campaign core, target protocol, economic core, service core and mining v3, plus two Solana programs. The runtime stack is Rust with axum for HTTP, tokio for async work, rusqlite with the bundled feature for SQLite, memmap2 for memory mapped files and ed25519-dalek for signing, with serde and serde_json for serialisation.

## Assembling the workspace before you can build anything

The build and test section is the operational heart of the project, and it starts with an explicit warning that this is a transition state. You need Rust 1.90 or newer because the source uses edition 2024, Node 22 or newer and Python 3.11 or newer. Optional scientific Python dependencies live in tools/requirements-research.txt in the assembled workspace, and SBF builds require the compatible Solana or Agave build tools. The first step is to clone the infra repository and let its workspace tooling fetch the exact source revisions.

```sh
git clone https://github.com/flybrainlabs/infra.git flybrainlabs/infra
python3 flybrainlabs/infra/tools/workspace.py checkout --repos flybrainlabs
python3 flybrainlabs/infra/tools/workspace.py assemble --repos flybrainlabs --output flybrainlabs-workspace
cd flybrainlabs-workspace
npm ci
```

The checks then run from the assembled workspace.

```sh
cargo test -p flypow --lib --test target_authority --test product_api --test market_catalog
cargo build --locked --release --bin target_authority
```

Note that the test line names three test targets explicitly, which suggests the integration suites are separated by service area rather than run as one blob.

## Why workspace.py sync and a component diff review sit in the workflow

The rule that all maintained edits belong to the owning repositories, and not in the assembled layout, is the reason the workflow has a sync step at all. The assembler creates what the README calls a disposable build layout, and then the instruction is to use workspace.py sync for intentional changes made in that layout, then review the component diffs and validate them before publication. So the loop is: assemble, change something locally to work out what the change should be, sync it back through the tooling, then review the resulting component diffs. The diff review is the safety net, because a sync can touch files that live in other repositories. Development policy adds that completed, verified updates are committed and pushed automatically to flybrainlabs/node using normal fast forwards, which means the merge to the owning repository happens through the tooling rather than through a hand-copied patch. Keys, wallets, customer inputs, node databases, private artifacts, browser profiles and model caches stay outside Git and website exports, which is a sensible line to draw for a project that touches wallets and accounting records.

## Scope boundaries: no production payments, isolated chain checks

The scope statement is where this project is honest about what it cannot do yet. The Marketplace catalog and the checked financial domain are under development, and production payments are not enabled. Payment and reward configuration stays disabled until its actual asset identities, authorities, funds and operating gates are satisfied, which is a longer list than it sounds and points to a design where each precondition is checked rather than assumed. The testing rules reinforce the same posture. Full-model and browser integration checks require existing, verified local resources and explicit arguments, and they do not download a model or reset a browser profile by default. Isolated chain checks require their own local bank, and production funds and addresses are never substituted. The wallet mining extension section adds a further layer: the two-unit acceptance budget is complete, future paid work requires a new prospectively frozen finite plan, and actual extension-wallet and physical-device confirmation remain separate gates. If your requirement is a working payment path today, this is the wrong project stage.

## The Social service and its loopback isolation

Community work is described in a separate section with its own service. The Social service lives in tools/social_server.mjs, shares existing wallet sessions and SQLite or WAL storage while running separately on loopback 8791. The separation is the point: it can reuse the wallet session and the database without becoming part of the main service's runtime. The database change is additive and checksummed, config/social-community-v1.sql is described as an additive checksummed migration, which is the right way to apply a schema change to a shared store. The checks are also separated into their own scripts, run in the assembled workspace. The three checks are named npm run test:community, npm run typecheck:community and npm run lint:community.

The typing story is nuanced and worth knowing. The new API, provider and client modules opt into JavaScript type checking, while legacy financial modules retain their existing validation suites. So the typecheck gate covers the new surface rather than the whole tree, which is a reasonable incremental path but means a green typecheck is not proof that the legacy modules are typed. The service starts no relayer and performs no asset execution, so it is a social layer and not a transaction path.

## Licence, provenance and what the import did not change

The licensing position has two layers that are easy to conflate. Project code retains the declared MIT OR Apache-2.0 licence, and the repository carries both LICENSE-MIT and LICENSE-APACHE files. Data descriptors and third-party assets retain their own source attribution and licences, and the code licence does not relicense MaleCNS data or third-party libraries. The import is described as preserving numerical and identity fixtures without reinterpreting existing scientific or financial records, with provenance detail in the NOTICE file. That is a narrow but meaningful claim for a project whose ledger holds financial records: the migration did not quietly recompute or normalise anything. The same section on governance notes that maintained documentation, commit messages, issues, pull requests and release notes are all written in English, while product interfaces may remain bilingual, which tells you where the bilingual surface actually sits.

## A research prototype with a service API on top

The crate description in the manifest is worth reading against the README's ambitious scope list: flypow is described as a deterministic, FlyHash-inspired proof-of-work research prototype. That single line reframes everything else. Durable goal competition, commit and reveal processing and the economic ledger are not the internals of a commercial platform in this repository, they are the mechanisms of a research system that exposes them through service APIs. The dependencies support that reading: memmap2 and rusqlite point at local, file-backed state rather than a distributed datastore, axum and tokio provide the service layer, and ed25519-dalek handles signing. The release profile with thin LTO and codegen-units = 1 is a performance-conscious build setting. For an adopter, the practical question is which of the two things you want: the mechanisms, in which case the crate is a research codebase you read and extend, or the running service, in which case you need the assembled workspace, the pinned component set and the infra tooling rather than a git clone.

## Conclusion

Adopt flybrainlabs/node if you are working inside the flybrainlabs component model and need the authority, economic ledger, market or product service layers, since it is the owning repository for those source files and the place where verified changes are pushed. Do not adopt it as a standalone artifact, because cloning it does not supply its external components and the build requires an assembled workspace created by the infra tooling with Rust 1.90, Node 22 and Python 3.11. Verify two things before you plan around it: that production payments are genuinely out of scope for your work, since the Marketplace catalog and checked financial domain are still under development and production payments are not enabled, and that the component you will edit has a single owning repository, since each imported file has one owner and edits belong there rather than in the assembled layout. The practical first step is to run the workspace checkout and assemble commands, then run the cargo test line from the assembled workspace to confirm your toolchain matches the pinned revisions.

## FAQ

### What is the flybrainlabs node repository?

It holds the authority and service APIs for flybrain.work, covering durable goal competition, commit and reveal processing, full replay coordination, private artifacts, scientific publication, customer tickets and accounting APIs. The crate is named flypow and is described as a deterministic, FlyHash-inspired proof-of-work research prototype.

### Why can I not just clone flybrainlabs node and build it?

Cloning that repository alone does not supply its external components. Each imported file has one owning repository, component.json maps maintained files into the shared build layout, and dependencies are pinned by commit in an infrastructure release manifest, so the sources have to be checked out and assembled first.

### What toolchain does building flybrainlabs node need?

Rust 1.90 or newer because the source uses edition 2024, Node 22 or newer and Python 3.11 or newer. Optional scientific Python dependencies are in tools/requirements-research.txt, and SBF builds need the compatible Solana or Agave build tools.

### Are production payments enabled in flybrainlabs node?

No. The Marketplace catalog and checked financial domain are under development, production payments are not enabled, and payment and reward configuration stays disabled until its asset identities, authorities, funds and operating gates are satisfied.

### Where do edits to flybrainlabs node code belong?

In the owning repository, not in the assembled build layout. The assembler creates a disposable layout, so intentional changes made there are pushed with workspace.py sync, and the resulting component diffs are reviewed and validated before publication.

## Sources

- [flybrainlabs/node on GitHub](https://github.com/flybrainlabs/node)
- [Issues](https://github.com/flybrainlabs/node/issues)
- [License: Apache-2.0](https://github.com/flybrainlabs/node/blob/main/LICENSE)
- [Project website](https://flybrain.work/)
- [README](https://github.com/flybrainlabs/node/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flybrainlabs-node