Currently we have problems with dependencies at our development cycle with staging node. For example when we develop feature for both node and wallet. At this case wallet should specify last actual staging github revision at 7 Cargo.toml files, it creates additional work on merging, cause different PRs can have different revisions.
Also at time of release to crates.io we need to publish node first, then change wallet deps again after some delay. After merge grin-wallet repo to grin it will be easier to create release of node and wallet at same time, I am personally using node and wallet as git submodules at gui repo for some time to avoid such issues: https://code.gri.mw/GUI/grim
I’am asking old members @david@tromp do you have any suggestion why it was not done before? If such decision will be approved we can prepare PR shortly.
No one cares what I think (that much is clear), but there’s pluses and minuses to both options imo.
a huge plus, would be when working with Ai, it would be easier for the Ai to understand wallet or node changes and their effect across the entire ecosystem in a single repo.
at the same time, wanting to work with just the wallet or just the node, it may be less token-resource-intensive to deal with the repos separately.
I’m curious to see if any of the big dawgs even address this. You are the lead dev @ardocrat so I’d say whatever you think is best. That’s why your payed the big bucks lol
Personally, I prefer to have separate repos and allow other people build things separately rather everything in one big repo.
I don’t know rust so can’t suggest much but I think now AI can manage most of repeated tasks
I list few pros and cons generated by Grok
Pros (Advantages)
Independent Release Cycles
The biggest reason for the split. The wallet can be updated, fixed, or have new features released without forcing a new node release (and vice versa). This was explicitly stated by Yeastplume when he did the split.
Cleaner Codebase & Maintainability
Node code (consensus, p2p, blockchain validation) and wallet code (key management, transaction building, Slatepack, etc.) have different concerns. Mixing them creates a bloated, harder-to-navigate codebase.
Easier for Third-Party Developers
This matches what you said. Other teams can:
Build alternative wallets using the official grin-wallet as a library/API (JSON-RPC + libwallet).
Focus only on the node if they’re building mining pools, explorers, etc.
Create ecosystem tools without pulling in the entire node.
Better Security & Auditing Focus
Wallet code is more security-sensitive (private keys, spending). Separating it makes it easier to audit the wallet independently.
Flexibility for Users & Builders
People can run just the wallet connected to a remote node, or just the node, or both. This encourages a richer ecosystem (Grin++, Grim GUI, mobile wallets, etc. all benefit from this).
Cons (Disadvantages)
Slightly Higher Coordination Effort
Core developers now need to maintain two repositories instead of one. Version compatibility between node and wallet must be managed carefully.
Duplicated Work / Overhead
Some shared logic (e.g., types, crypto primitives) might need to be duplicated or moved into a third common crate. Build scripts, CI/CD, and release processes are doubled.
Slightly More Complex for Beginners
New users have to install/download two things instead of one combined package (though in practice this is minor — many projects do this).
Potential for Desynchronization
If the wallet and node drift too far apart in features or versions, it can cause temporary friction for users.
Overall Verdict
The split is generally better for a project like Grin, especially long-term.
Grin’s philosophy is minimalism and strong separation of concerns. Keeping everything in one repo would make the node unnecessarily heavy and slow down wallet innovation.
Your point is spot on: it enables a healthier ecosystem. Third-party wallets and tools can depend on a stable grin-wallet library without needing the full node, which is exactly what happened with several community wallets.
Perhaps instead of looking into whether we should we put it all in one repo, we should search for methods to make working with two repo’s with shared dependencies more painless.
My AI suggested the following options:
1. Cargo Workspace (Best for Rust Projects)
If both projects are Rust-based, the cleanest solution is a Cargo Workspace. This keeps them in separate directories but manages dependencies centrally.
Benefits
Single Cargo.lock ensures consistent versions across both projects
Shared dependencies are downloaded once
cargo update updates all projects simultaneously
No version drift between repos
2. Git Submodules (Keep Repos Separate)
If you need to keep repositories truly separate (different teams, different release cycles):
# In project_a
git submodule add https://github.com/your-org/shared-lib.git shared-deps/
# In project_b
git submodule add https://github.com/your-org/shared-lib.git shared-deps/
Benefits:
Repos remain independent
Each can have its own release cycle
Easy to pin specific commits
Drawbacks:
Submodule management can be painful (need to update both)
CI/CD needs to handle submodule fetching
Developers need to remember git submodule update --init --recursive
It reads like Option 2 is our current situation, with the above mentioned Drawbacks.
build can be done separately, its about code storage, node release will not include wallet code, statements that AI described above is not about what I meant.
Using node submodule for node at wallet to use local deps instead of crates/git deps in cargo.toml looks like a better solution by this moment. We’ll need to update single file at least, better control on merge, the only problem PR creator can use outdated version of submodules, need to control this.
I don’t like the submodule approach. As Ardocrat mentioned, a developer has to remember to update it while working on the code.
What would change for a third-party developer if we merge these two repositories?
@ardocrat, since you are a developer of Grim wallet, and since Grim uses grin-wallet under the hood, could you clarify whether this merge might introduce any inconveniences for you?
I don’t mind merging the repositories if that will improve development. I don’t see any issues with this, other than the question I raised above.
Correct if i’m wrong, you mean to ‘combine’ (shared code, dependencies, versioning…) from both repo but the released binary will be still in separate file?
Submodule or merge will not make difference for me, just easier to manage deps, currently the only difference for me I need to keep custom cargo.toml with monorepo deps at separate branch and resolve conflicts on merge
I prefer to keep wallet and node code separate. Each has a lot of complexities of no concern to the other.
Wallet code has to deal with key management. and all the security concerns that brings.
Node code has to deal with peer discovery and management, syncing, chain storage, etc.
Ideally, the code would be split up even more, with a separate consensus library that both node and wallet build on top of.
That said, I don’t have the experience with large scale github repo organization that Yeastplume and ardocrat have, and I recognize that separating things introduces problems as well.
But I would advocate for trying to tackle those problems in other ways than merging codebases that already have their fair share of complexity.
I am currently seeing submodules of grin dependencies at grin-wallet as the best solution here, also will be better for security, so we will not need to download grin-related wallet deps from 3rd party source like crates.io
