nodes issueshttps://git.duniter.org/groups/nodes/-/issues2024-03-21T18:44:36+01:00https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/225Benchmarks error2024-03-21T18:44:36+01:00Benjamin GalloisBenchmarks errorThe benchmarks for pallet certification and identity include extra methods within the weight trait implementation generated by the benchmarks.The benchmarks for pallet certification and identity include extra methods within the weight trait implementation generated by the benchmarks.runtime-802Benjamin GalloisBenjamin Galloishttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/221Oracle : ne pas se bloquer à cause des clés2024-03-28T16:29:14+01:00Cédric MoreauOracle : ne pas se bloquer à cause des clésAujourd'hui l'Oracle se bloque après des rotateKeys :
```rust
let &[owner_key] = owner_keys else {
log::error!("🧙 [distance oracle] Expected exactly one Babe owner key, found {}: oracle cannot work", owner_keys.len());
return Ok(sp...Aujourd'hui l'Oracle se bloque après des rotateKeys :
```rust
let &[owner_key] = owner_keys else {
log::error!("🧙 [distance oracle] Expected exactly one Babe owner key, found {}: oracle cannot work", owner_keys.len());
return Ok(sp_distance::InherentDataProvider::<IdtyIndex>::new(None));
};
```
Or on pourrait utiliser un autre mécanisme pour savoir si l'on a déjà publié un résultat en blockchain, par exemple en utilisant des fichiers locaux.runtime-802Benjamin GalloisBenjamin Galloishttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/218Protocole : ne pas autoriser la création d'une identité où le compte n'existe...2024-03-13T16:22:12+01:00Cédric MoreauProtocole : ne pas autoriser la création d'une identité où le compte n'existe pasPendant les RML 18 : la création d'une identité sur un compte qui n'existait pas (aucun provider, aucun suficient) est possible.
C'est gênant, on pourrait définir comme prérequis que le compte existe et possède des fonds pour pouvoir su...Pendant les RML 18 : la création d'une identité sur un compte qui n'existait pas (aucun provider, aucun suficient) est possible.
C'est gênant, on pourrait définir comme prérequis que le compte existe et possède des fonds pour pouvoir subir une création d'identité.runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/213Consider using subxt::OnlineClient instead of sc_service::TFullClient in dist...2024-03-06T13:34:41+01:00Hugo TrentesauxConsider using subxt::OnlineClient instead of sc_service::TFullClient in distance clientMore details on comment https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/252#note_42404
Summary: we are using hardcoded keys instead of keys from runtime metadata. Using subxt online client would fix this but make `create...More details on comment https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/252#note_42404
Summary: we are using hardcoded keys instead of keys from runtime metadata. Using subxt online client would fix this but make `create_distance_inherent_data_provider` asynchronous with possible consequences far in the code.Horizonhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/212Add test to ensure distance oracle does not try to re-publish a result2024-03-09T18:00:52+01:00Hugo TrentesauxAdd test to ensure distance oracle does not try to re-publish a resultIn MR !252, #207 was fixed, but the behavior still has to be tested to avoid undetected breaking if storage key name changes.In MR !252, #207 was fixed, but the behavior still has to be tested to avoid undetected breaking if storage key name changes.HorizonBenjamin GalloisBenjamin Galloishttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/211decrease size of `duniter-polkadot-sdk` fork2024-03-21T18:44:37+01:00Hugo Trentesauxdecrease size of `duniter-polkadot-sdk` forkThe repo size is way too large, which makes download stage of building docker images of Duniter and Ğcli longer than needed.
https://github.com/duniter/duniter-polkadot-sdk/The repo size is way too large, which makes download stage of building docker images of Duniter and Ğcli longer than needed.
https://github.com/duniter/duniter-polkadot-sdk/HorizonBenjamin GalloisBenjamin Galloishttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/210Smith documentation is not up-to-date2024-03-01T14:18:17+01:00Cédric MoreauSmith documentation is not up-to-date[https://forum.duniter.org/t/apprentis-forgerons/10665/48](https://forum.duniter.org/t/apprentis-forgerons/10665/48?u=cgeek)[https://forum.duniter.org/t/apprentis-forgerons/10665/48](https://forum.duniter.org/t/apprentis-forgerons/10665/48?u=cgeek)runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/208allow identity revocation with v1 certificate2024-03-01T01:15:30+01:00Hugo Trentesauxallow identity revocation with v1 certificateWe should make this possibleWe should make this possibleĞ1 real migrationhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/206Rethink state pruning2024-02-24T15:26:53+01:00Hugo TrentesauxRethink state pruningSeveral problems are linked with the in chain pruning of useless data like old identities. We have to rethink this and find better solutions.Several problems are linked with the in chain pruning of useless data like old identities. We have to rethink this and find better solutions.Horizonhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/204cert_validity_period different from g1 is inconsistent2024-02-23T20:19:45+01:00Hugo Trentesauxcert_validity_period different from g1 is inconsistentin "certByIssuer" field of genesis, we can see something like:
```
"11937": {
"6222": 7854073,
"7030": 7221464,
"7159": 6596517,
"7946": 6054186,
"8343": ...in "certByIssuer" field of genesis, we can see something like:
```
"11937": {
"6222": 7854073,
"7030": 7221464,
"7159": 6596517,
"7946": 6054186,
"8343": 5721823,
"10662": 6770773,
"10675": 5726937,
"10739": 5722153,
"11106": 5723004,
"11194": 5721471,
"12456": 6745296,
"14152": 10517942
```
this means that the cert 11937 → 14152 is set to expire at block 10517942 = 10,517,942 = 63107652 s ≃ 2 years but the genesis parameters in yaml says:
```
# Validity duration of a certification, 2102400 blocks = 146 days.
cert_validity_period: 2102400
```
So we have old certs form g1 with the 2 years delay but the new certs in gdev with the 6 month delay.
This is not really an issue but is good to notice.Ğ1 real migrationhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/200debian package2024-02-22T13:22:08+01:00Hugo Trentesauxdebian packageWhile most of us start being familiar with docker, Ğ1 community will most likely use debian package and yunohost config.While most of us start being familiar with docker, Ğ1 community will most likely use debian package and yunohost config.runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/197Use IdtyIndex as Session ValidatorId2024-02-27T16:00:53+01:00Hugo TrentesauxUse IdtyIndex as Session ValidatorId> this issue was renamed after discussion
We have a strange pattern: only member identities are allowed to be validators, and they are identified by their accountid which can change.
There are too many layers:
1. pallet identity
2. ...> this issue was renamed after discussion
We have a strange pattern: only member identities are allowed to be validators, and they are identified by their accountid which can change.
There are too many layers:
1. pallet identity
2. pallet membership (sorry)
3. pallet smith-members
4. pallet authority-members
5. pallet session
I think we should at least merge `smith-members` and `authority-members` which are both adapters for pallet session.
Authority-members already provides an interface for pallet session with `pallet_session::Call::<T>::set_keys` and `pallet_session::SessionManager` implementation (that uses the results coming from `go_online` and `go_offline`).
Two options here:
- use identity index as validator id
- keep account id as validator id but update it on change_owner_key (implementation already available) so it still has a meaning
In both case, the `Members` storage item does not need to map to somthing and can simply be a set (a map to `()`).
Marking this as #bug because it's unspecified behavior. Not sure however in which scenario it could be problematic.runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/195Dissociate release of Runtime and release of Client2024-02-21T13:00:11+01:00Cédric MoreauDissociate release of Runtime and release of ClientTo describe.To describe.runtime-802Cédric MoreauCédric Moreauhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/183Refac generated documentation2024-03-12T14:37:01+01:00Hugo TrentesauxRefac generated documentationIn 1.6.0 substrate upgrade, the call documentation disappeared from runtime metadata. We then have to rethink the way we generate documentation.
See discussion: https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/229#note_40...In 1.6.0 substrate upgrade, the call documentation disappeared from runtime metadata. We then have to rethink the way we generate documentation.
See discussion: https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/229#note_40999
Ideas:
- [x] keep `cargo xtask gen-doc` but remove generated files from git index
- [x] generate documentation with `cargo doc` and host it somewhere online, built by a CI
- [ ] add an other CI which runs the gen doc xtask and output the results somewhere for Duniter website to take from
- [x] modify the xtask doc template to link to the doc generated with `cargo doc`runtime-802Benjamin GalloisBenjamin Galloishttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/182smiths-members: Unscheduling2024-02-21T13:00:11+01:00Cédric Moreausmiths-members: Unscheduling> Ticket repris de https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/173
On est toujours sur le système `ExpiresOn` qui regarde juste si le `expire_on` a bougé, donc pas de unscheduling, normalement les forgerons ne spammeront pas...> Ticket repris de https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/173
On est toujours sur le système `ExpiresOn` qui regarde juste si le `expire_on` a bougé, donc pas de unscheduling, normalement les forgerons ne spammeront pas `go_online`/`go_offline` à tous les blocs, ce qui pourrait faire grandir le storage linéairement pendant `SmithInactivityMaxDuration`runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/181smith-members: supprimer CurrentSession2024-02-21T13:00:11+01:00Cédric Moreausmith-members: supprimer CurrentSession> Ticket repris de https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/173
Le storage `CurrentSession` duplique ce qu'on pourrait récupérer avec `Session::current_index()` si la pallet dépendait fortement de la pallet session plutôt...> Ticket repris de https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/173
Le storage `CurrentSession` duplique ce qu'on pourrait récupérer avec `Session::current_index()` si la pallet dépendait fortement de la pallet session plutôt que simplement par le hook. Je ne sais pas ce qui est le mieux, mais en fait les deux me semblent bien.runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/179Merge identity/pubkey "conversion" trait into one2024-02-21T13:00:14+01:00Hugo TrentesauxMerge identity/pubkey "conversion" trait into oneCurrently we have two traits to perform accountid ←→ identityindex "conversion".
```
IdtyIdOf: Convert<Self::AccountId, Option<Self::IdtyIndex>>;
OwnerKeyOf: Convert<Self::IdtyIndex, Option<Self::AccountId>>;
```
This is not really a c...Currently we have two traits to perform accountid ←→ identityindex "conversion".
```
IdtyIdOf: Convert<Self::AccountId, Option<Self::IdtyIndex>>;
OwnerKeyOf: Convert<Self::IdtyIndex, Option<Self::AccountId>>;
```
This is not really a conversion and I see no case where we should be able to go in one way but not in the other.
We could merge this in a single trait like
```
IdtyAttr: Idty<Self::IdtyIndex, Self::AccountId>
trait Idty {
fn owner_key(index: IdtyIndex) -> Option<AccountId>
fn idty_index(owner_key: AccountId) -> Option<IdtyIndex>
}
```runtime-802Hugo TrentesauxHugo Trentesauxhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/172Optimisation: transactional opt out2024-02-21T13:00:13+01:00Hugo TrentesauxOptimisation: transactional opt outSince https://github.com/paritytech/substrate/issues/10806, extrinsic spawn a transactional layer by default which can be opted-out with `#[without_transactional]`. Most of our code follow the "verify first, write last" practice this iss...Since https://github.com/paritytech/substrate/issues/10806, extrinsic spawn a transactional layer by default which can be opted-out with `#[without_transactional]`. Most of our code follow the "verify first, write last" practice this issue mentions anyway (i.e. `check_*` functions doing nothing returning `Result` and infaillible `do_*` functions), so it can easily benefit from this optimisation.
It's not necessary but it's possible, and worth noting if we want to avoid this pattern for simplicity.runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/171Generate scale metadata during build2024-01-31T20:48:24+01:00Pascal EngélibertGenerate scale metadata during buildMaybe `build.rs` can generate the metadata, to avoid having to run the node and use subxt.
Since the node includes subxt parts (distance client), it still has to build without these features first, generate the metadata, then build with...Maybe `build.rs` can generate the metadata, to avoid having to run the node and use subxt.
Since the node includes subxt parts (distance client), it still has to build without these features first, generate the metadata, then build with all the features.Horizonhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/158Identity creation should only be possible for an account that already "exists"2024-03-13T16:22:13+01:00Hugo TrentesauxIdentity creation should only be possible for an account that already "exists"Since identity confirmation requires some funds for the tx fees, an identity should not be created on an "empty" account. Therefore the `create_identity` call should check that account exists ~~with sufficient balance~~.Since identity confirmation requires some funds for the tx fees, an identity should not be created on an "empty" account. Therefore the `create_identity` call should check that account exists ~~with sufficient balance~~.runtime-802