---
# System prepended metadata

title: Alt Clients Roadmap

---

# Alt Clients Roadmap

- User profile:
    - Query by Radicle URN
    - [Show statistics by Radicle URN](#Show-statistics-by-Radicle-URN)
        - Amount of contributions
- [Commit signature verification](#Commit-signature-verification):
    - Verify against node peers by SSH key
    - [Verify unknown SSH keys](#Verify-unknown-SSH-keys)
    - [Allow other commit signatures (GPG)](#Allow-other-commit-signatures)
- [Distributed patch-based collaboration](#Distributed-patch-based-collaboration)
- Project starring
- [Discover projects and or orgs](https://radicle.community/t/rfp-radicle-discovery-analytics-work-in-progress/2689#radicle-discovery-analytics-1)

---
# Details
## Show statistics by Radicle URN

Users amass lots of information on their code activity, e.g. amount of contributions, patches, etc, which are interesting for themselves and others to see.
Currently platforms like GitHub store this information and relate to it by the users email or obfuscated GitHub email.

![Example of GitHub Statistics](https://i.imgur.com/yhAyNAO.png)

We could distinguish us from GitHub and other solutions by creating a way to allow users to obtain information regarding their code activity and link it against their Radicle URNs, instead of their email or GitHub username
Since we would still need some kind `(urn) => UserStats` maybe we can evaluate [CouchDB](https://couchdb.apache.org/)

## Commit signature verification

Git commit signing is a important security measure to ensure the identity of the committer, due to the use of SSH keys as Radicle Identity we should allow the user apart from verifying the commit signature by themselves to show them in the commit history, if the commit signature has been verified and if the signee is a delegate of the project.

![](https://i.imgur.com/sHOWSRH.png)


### Verify unknown SSH keys

Commits can be signed by keys unknown to the http-api which provides the UI with information.
A indexer/graph that iterates over commit signatures and tries to find user identities (through ENS perhaps?) that match, could be an option.

### Allow other commit signatures

There are still plenty of people that use GPG for commit signature and even GitHub embraces it still, so we should work on create a possibility to link a trusted GPG fingerprint to a Radicle URN (perhaps also through ENS?)

## Distributed patch-based collaboration

*Source: https://github.com/radicle-dev/radicle-cli/issues/10*

As a first attempt towards building collaboration tools, we'd like to put together something that would allow for developers to share and discuss patches with each other, and to integrate those patches into git repositories.

This would take the form of a shared inbox, eg. the "Pull requests" tab on GitHub, that anyone could add to, and would be distributed via Git, allowing for it to be replicated through Link, or simply via a git clone. Other replication mechanisms could be explored if they are as convenient as the above.

For a proof-of-concept, we would build a simple CLI that could be used to create patches, discuss them and merge them. For discussions, simply opening $EDITOR and typing comments inline, as when responding to an email, is perfectly sufficient for now.

These shared inboxes are to be scoped at the Radicle Project level, naturally, so each project would have its own inbox of patches.

The requirements for this follow the requirements of most radicle tooling: every object needs to be signed by a key that can be associated with the Radicle Identity, ie. either a Radicle key or an Ethereum key. Verification of the objects should be done client-side, there should be no trust assumptions. As for hosting/distribution, this should be compatible with the client services, ie. the org-node, but doesn't necessarily have to require it, ie. it can work in a "plain" p2p mode.