Roadmap
Last edited: 8 September 2026
The coordinated release of ngit v3, ngit-grasp v3, ngit-ci v0.1 and GitWorkshop v4 in September 2026 and the merging of GRASP-03 and GRASP-08 marked a key milestone for GRASP and this product family.
The release shipped the implementation foundations, and the GRASP merges established the protocol foundations. The roadmap builds on both in three directions:
- Private repository providers: enable operators to provision and manage many small private GRASP services alongside their public service, making the private service model defined by GRASP-08 available beyond self-hosters.
- CI providers: build tooling that separates compute providers from coordinators and enables runners across multiple platforms and architectures, opening the way for a provider marketplace and CI at scale that is safe and convenient.
- Moderation: GRASP-03 ensures a repository's GRASP servers are the only place clients need to query for synchronised collaboration history from across Nostr. This provides a simple foundation for maintainer-defined moderation policies and actions that GitNostr clients can respect without complex network-wide discovery.
Private repository providers
Public repositories can already use several GRASP providers. GRASP-08 defines how a GRASP service can be private, and ngit-grasp implements that model for self-hosters today. The hard work now is enabling operators to provision and manage many small private GRASP services alongside their public service. That is what will take private repositories beyond the self-hosting community.
A private repository should be able to use multiple provider-operated and self-hosted services for redundancy while managing permissions once through an existing Nostr group protocol such as Concord. Adding or replacing a service should not change the repository's identity, require contributors to update their remotes, or create a separate membership system for each provider.
Moderation for open source projects
Open source projects need moderation before they can welcome participation at scale. GRASP-03 synchronises accepted issues, patches, pull requests, and their conversation history from across Nostr to a repository's GRASP servers. Clients can query those servers for the repository's accepted collaboration history instead of discovering and following every relay involved.
That makes moderation practical without a complex implementation in every client. The next work is to define how maintainers express moderation policies and actions, how GRASP servers apply them while synchronising, and how GitNostr clients reflect them consistently. Independent providers must remain free to apply their own infrastructure policies.
A marketplace of CI providers
Coordinators and runners are already independently selectable. The CI model distinguishes three roles:
- the coordinator observes repository activity, applies policy, selects workflows, handles trust and secrets, and signs progress and combined results;
- the compute provider executes a job and signs its result; and
- the runner is the software that understands and executes a workflow format.
ngit-ci keeps the coordinator and compute provider within one operator's deployment today. The operator can choose embedded act or an attached adapter, but even a separate coordinator and microVM adapter remain one deployment and identity.
What is missing is tooling for a coordinator to delegate jobs to separately operated compute providers and match jobs to runner capabilities across multiple platforms and architectures. A first version could route work across several machines within one operator's trust boundary.
Beyond that, a trusted coordinator could assign jobs to independent compute providers. Its choices could account for the provider's identity and history, the risk of the code being run, secret exposure, isolation, available platforms and architectures, capacity, and cost.
Nostr can make that a market instead of a fixed integration. Providers can advertise capabilities and availability; coordinators can select among them; and users can choose which coordinators and attestations they trust. Market participation alone would not make a result trustworthy. Signed provenance and each participant's explicit trust policy remain essential.
The money is intended to flow in two stages. A repository's maintainers or benefactors pay a coordinator, either as a subscription or by topping up a per-repository CI funding pot that anyone can contribute to. The coordinator then covers execution from its own machines, from pay-per-use market compute, or from a mix chosen by availability and trust. Today, billing between a maintainer and an operator is arranged out of band, and the coordinator's advertisement only says whether it bills.
Two existing projects provide useful prior art:
- Loom explores a general Nostr compute market with worker discovery, job status, results, and payment; and
- Hive CI explores CI workflows executed through Loom workers.
ngit-ci already uses the shape of Loom's execution-adapter contract for its local sandbox boundary, and its event work has been informed by Hive. It does not yet implement a remote Loom marketplace, and the CI protocol is still a draft. Understanding Nostr CI records where ngit-ci sits inside the protocol and links the current specification.
Runner choice
act is a practical bridge for projects that already know GitHub Actions-compatible workflows. It splits a workflow into jobs internally, but keeps their execution on the same machine instead of exposing them to run independently elsewhere. It also does not support cross-architecture execution, Windows, or macOS runners. Its Docker execution model is an awkward fit inside a KVM-isolated adapter, while GitHub integrations can bring unexpected dependencies outside GitHub. Forgejo has forked act to provide some of this capability, but those additions are tightly coupled to Forgejo's implementation.
We are especially excited about an efficient, Nix-native CI option that does not inherit that GitHub legacy. An experimental branch already uses Firecracker for isolated execution with multi-platform support, and the early results look very promising. The aim is to use Nix's reproducible build model and caching directly while keeping it one runner choice among many.
The CI events, coordinator policy, and runner boundary are intended to support different workflow languages and execution software.
Other implementations should be able to make different choices while participating in the same wider CI model. Runner diversity is part of the design, not a compatibility problem to hide.
Across all three directions, self-hosting should remain a first-class option. Repository and CI providers should be replaceable, moderation decisions should be portable and understandable, and no provider should own a project's identity.