---
# System prepended metadata

title: Alt.-clients 2022 Roadmap

---

# Alt.-clients 2022 Roadmap

The first step is to get users to create, publish and share code reliably.
To do this, we are going to:

1. Work on a new CLI-based user flow which doesn't rely on radicle-link networking and replication, but uses radicle-link identities and storage and is thus compatible. This CLI will allow you to: create and manage your off-chain identity, create and manage projects, and publish projects to the network. The goal is to have new users be able to publish code to the network and have it viewable on the web within minutes.
2. Fully integrate radicle-link signing keys and identities with SSH and git, to be used for server-side authentication.
3. Deploy some new community seed nodes with radicle-client-services on them, to use for user onboarding. These will be serviced by us, but will not run the radicle-link networking stack.
4. Enable radicle-interface to browse un-anchored projects that are not part of any org and improve online code browsing by giving access to branches, peers and commits.

This flow will enable decentralized code sharing without ethereum, though it does have some trade-offs. Hence, the next steps after the above is working is to:

1. Release radicle-cloud, which will allow anyone to offer or purchase hosting services using only an ethereum wallet. This offering will hopefully remove any central points of failure when it comes to seed hosting, while allowing for a 1-click deployment for any user or team interested in reliable hosting for their projects. Users will have a choice of which hosting provider to use, based on cost, reputation, and location of datacenters.
2. Start deploying indexing nodes which will create a searchable database of project metadata on the network. This should help with discovery as well as provide a way to know where projects can be fetched from. Regular nodes that want to be discovered will have the option to query the index nodes when they come online, to announce themselves. These index nodes will be registered on chain with a DNS fallback, so users bootstrapping their clients will be able to discover seeds on the network.
3. Provide a more extensive integration with ENS as an identity service for projects, orgs and users: when registered, it should be possible to find projects using their ENS names. This will involve creating a subdomain registrar that can be deployed for registering project subdomains, eg. `rx.cloudhead.radicle.eth`.
4. Provide a way to link radicle-link keys with ethereum addresses. This will probably involve publishing a proof within the personal identity document in radicle-link. We will leverage this for cases where code and money need to relate with each other, eg. retroactive contributor rewards based on commit history, proofs-of-commit etc.

Finally, work will be done to improve anchoring and code governance. We will:

1. Re-think how anchoring works, by potentially batching anchors to dramatically reduce the gas cost and/or implement gasless anchoring. This would involve some kind of off-chain accumulator that would turn a batch of anchors into a merkle tree that can be rooted on chain. The goal is to reduce the marginal gas cost of anchors, the more anchors are created.
2. Re-think orgs  according to (1).
3. Automate anchoring using server-side hooks. This would make anchoring a side-effect of pushing code, eg. once 2-of-3 maintainers push a certain commit hash, that hash gets anchored.
4. Keep improving our multisig flows for code governance, both on the web, and on the CLI.

**What we hope to have by the end of the year is a reliable decentralized code hosting network with an sovereign identity layer on top, that is easy to access, browse, use, search and discover.**

---

If time permits, we may work on a few other things:
* Depending on the state of collaborative objects, we may work on a CLI and read-only web view for them.
* If radicle-drips is successful, we will consider integrating it into radicle-interface.
* We will look into low-hanging GitHub integrations, eg. mirroring.
* We will research potential social features around code, eg. activity feeds and stars, to integrate in the web experience.