Roadmap
v3 is graduation day, not the finish line.
The coordinated release of ngit v3, ngit-grasp v3, ngit-ci v0.1 and GitWorkshop v4 in September 2026, together with the merging of GRASP-03 and GRASP-08, marked a key milestone for GRASP and this product family. The implementation and protocol foundations are now in place. Three big opportunities come next:
- Private repositories beyond self-hosters: enable GRASP operators to offer private service endpoints without every team having to run its own.
- Moderation that can scale: turn synchronised collaboration history into maintainer-selected rules that servers apply and clients can respect.
- A marketplace of CI providers: separate coordinators from compute across platforms and architectures, opening the way for CI at scale that is safe and convenient.
Each moves another part of development infrastructure from a fixed platform to a service that projects can choose, combine, and replace.
Private repository providers
Projects with public repositories can already choose and combine several GRASP providers. GRASP-08 defines how a GRASP service can be private, and ngit-grasp implements that model for self-hosters today. The next leap is making that freedom available to teams that do not want to run the infrastructure themselves.
To get there, operators need to provision and manage many small private GRASP service endpoints alongside their public service. A team can then combine provider-operated services with one it self-hosts, gaining redundancy without handing its repository identity to any of them.
More providers should not mean more permission systems. Maintainers should manage access once through an existing Nostr group protocol such as Concord, then add or replace a service without moving the repository, changing contributors' remotes, or rebuilding its membership by hand.
Moderation for open source projects
Open source works by inviting people in. To keep that invitation open as a project grows, maintainers need moderation that can grow with it.
GRASP-03 has shipped the crucial foundation. A repository's GRASP servers synchronise its accepted issues, patches, pull requests, and conversations from across Nostr. Clients can ask any one of those servers for the complete collaboration history instead of chasing every relay involved.
Now that history has a dependable home, the next step is maintainer-selected moderation rules and actions that GRASP servers apply while synchronising. Clients can respect the project's decisions without each having to implement difficult moderation logic client-side. Independent providers remain free to apply their own infrastructure policies.
A marketplace of CI providers
The future of CI should not be another fixed runner fleet. It should be a maintainer-selected coordinator choosing the right compute provider for each job at the right time, mixing a project's own machines with capacity from an open market.
That future is possible because the CI model keeps three roles separate:
- 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.
Those boundaries exist today. The marketplace does not. ngit-ci currently keeps the coordinator and compute provider within one operator's deployment. The operator can choose embedded act or an attached adapter, but even a separate coordinator and microVM adapter remain one deployment and identity.
The first step is tooling that lets a coordinator route jobs across several machines within one operator's trust boundary, matching each job to runner capabilities across multiple platforms and architectures.
From there, the same coordinator can reach independent compute providers. It can choose with the job in front of it, weighing the provider's identity and history, the risk of the code, secret exposure, isolation, available platforms and architectures, capacity, and cost.
Nostr can turn that matching into a market instead of a fixed integration. Providers advertise what they can offer, coordinators choose among them, and users choose which coordinators and signed results they trust. Paying for compute never makes its answer true. Signed provenance and each participant's explicit trust policy remain essential.
The money follows the same shape. Maintainers or benefactors fund a repository's coordinator through a subscription or shared pot. The coordinator pays for its own machines, pay-per-use market compute, or a mix chosen by availability and trust. For now, maintainers and operators arrange billing out of band.
This vision does not start from a blank page:
- 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 Hive informed its event design. A remote Loom marketplace has not shipped yet, and the CI protocol remains a draft. Understanding Nostr CI shows exactly where ngit-ci stands today.
Runner choice
A compute marketplace can only be as broad as the jobs its runners can execute. act is a practical bridge for projects that already know GitHub Actions-compatible workflows, but it also sets the current ceiling. It splits a workflow into jobs internally while keeping them on the same machine. It does not support cross-architecture execution, Windows runners, or macOS runners, and Docker is an awkward fit inside a KVM-isolated adapter. GitHub integrations can also carry unexpected dependencies outside GitHub. Forgejo has forked act to add some of this capability, but those additions are tightly coupled to Forgejo itself.
That is why an efficient, Nix-native CI option is so exciting. It can leave the GitHub legacy behind and use Nix's reproducible builds and caching directly. An experimental branch already runs isolated jobs with Firecracker across multiple platforms, and the early results look very promising.
It will remain one runner choice among many. The events, coordinator policy, and runner boundary are designed for different workflow languages and execution software to share the same wider CI model. Runner diversity is the point.
The thread through all three directions is choice. Self-hosting remains a first-class option, repository and CI providers remain replaceable, moderation decisions remain portable and understandable, and no provider owns a project's identity.