# Ğcli version 0.4.1

**URL:** https://forum.duniter.org/t/gcli-version-0-4-1/13052
**Category:** Ğ1cli
**Tags:** gdev, release
**Created:** [8 April 2025 19:00 UTC](https://forum.duniter.org/t/gcli-version-0-4-1/13052 "2025-04-08T19:00:48Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Nicolas80](https://forum.duniter.org/user_avatar/forum.duniter.org/nicolas80/32/11019_2.png) [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [8 April 2025 19:00 UTC](https://forum.duniter.org/t/gcli-version-0-4-1/13052/1 "2025-04-08T19:00:48Z")

</div>

> **[v0.4.1 · clients / Rust / Ğcli-v2s · GitLab](https://git.duniter.org/clients/rust/gcli-v2s/-/releases/0.4.1)**
>
> Latest changes: feat: Can choose between ed25519 ans sr25519 (

Change started by @poka to support both ed25519 and sr25519 crypto-scheme and use ed25519 by default - linked to this [post - Use ed25519 vs sr25519 for v2s clients](https://forum.duniter.org/t/use-ed25519-vs-sr25519-for-v2s-clients/12996)

Full release notes (also available in the release page and in [CHANGELOG.md](https://git.duniter.org/clients/rust/gcli-v2s/-/blob/master/CHANGELOG.md)):

## [0.4.1] - 2025-04-08

### Added / Changed

- We now use `ed25519` crypto scheme by default for all commands. It means that if you import your substrate mnemonic without giving a specific argument to change the crypto scheme, the resulting SS58 address will not be the same as before (it was using `sr25519` for substrate mnemonic previously)
  - Extra `-c` / `--crypto-scheme` argument allows to specify which crypto scheme to use (`sr25519` or `ed25519`) and having a default value of `ed25519` in most places.
    - this argument is present in all places where you could provide `-S` / `--secret-format` argument

  - Due to that change, the display of the vault (`vault list ...` commands) will not display the g1v1 public key of all `ed25519` \<Base\> keys by default anymore; you will have to provide an extra `--show-g1v1` argument for that.
  - Another impact is that we can now `vault derive` any key; including the ones with `ed25519` crypto-scheme.
    - It is still highly recommended to **only derive** keys based on a **substrate mnemonic** ; as old `g1v1` keys with their _manual_ `id` & `secret` are not as secure as using a generated substrate mnemonic.

  - There is an exception to the impacted commands: `vault migrate` will still import old key files as `sr25519` crypto-scheme keys; as it would otherwise not correspond to the SS58 Address of those key files.

- It is now possible to perform `vault import` and `vault derive` commands without interactive prompts if all necessary optional arguments are provided.
  - Please check for more details with commands:
    - `vault import --help`
    - `vault derive --help`

  - If the command tries to override an existing vault entry, then it will still require manual input from the user!

- Adapted commands `identity link-account` and `identity change-owner-key`
  - Made it clear that the arguments are meant to “target” another account
  - Added possibility to provide the “target” account from the vault
    - `-a` SS58 Address of target vault account
    - `-v` Name of target vault account

  - `-S` (secret\_format) doesn’t have a default anymore since it conflicts with using `-a` or `-v`

- Adapted `vault inspect` command to display more information
  - Substrate URI (was already present)
  - Crypto scheme: to be more coherent since both the `substrate uri` and `crypto-scheme` are needed to create the key with the proper `address`
  - Secret seed/mini-secret: only computed if no `soft` (single ‘/’) derivation are used
  - Public key (hex)
  - SS58 Address
  - (potential G1v1 public key if inspecting a \<Base\> account with ed25519 crypto-scheme)

- Small changes
  - In the vault, changed sorting of children account so that they are sorted by derivation `Path` value (makes more sense when viewing derivations of one account)

### Fixed

- None

### Deprecated

- Two commands are still deprecated and will be removed in a future release:
  - `gcli vault list-files`
  - `gcli vault migrate`

### Removed

- None

### CI/CD

- None

---

<div class="post-metadata">

### Author: ![ENO](https://forum.duniter.org/user_avatar/forum.duniter.org/eno/32/7840_2.png) [@ENO](https://forum.duniter.org/u/ENO)
#### Post date: [19 April 2025 23:41 UTC](https://forum.duniter.org/t/gcli-version-0-4-1/13052/2 "2025-04-19T23:41:32Z")

</div>

I have a question regarding the development of Gcli command line features.  
Given the ever-increasing number of commands and sub-commands, are there any plans to implement the auto-completion feature?  
That would be super useful.

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 April 2025 18:58 UTC](https://forum.duniter.org/t/gcli-version-0-4-1/13052/3 "2025-04-20T18:58:21Z")

</div>

This is a feature for @PacoVelobs who already added clap-complete on Duniter and might be interested to add it to Ǧcli 😉

---

<div class="post-metadata">

### Author: ![Nicolas80](https://forum.duniter.org/user_avatar/forum.duniter.org/nicolas80/32/11019_2.png) [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [12 May 2025 14:27 UTC](https://forum.duniter.org/t/gcli-version-0-4-1/13052/4 "2025-05-12T14:27:24Z")

</div>

New version with that change + ARM64 build :

> [@Ğcli version 0.4.2 - shell auto-completion & ARM64 build](https://forum.duniter.org/t/gcli-version-0-4-2-shell-auto-completion-arm64-build/13104):
>
> Added sh…