nodes issueshttps://git.duniter.org/groups/nodes/-/issues2024-02-19T13:02:10+01:00https://git.duniter.org/nodes/duniter-squid/-/issues/13Remove change owner key from genesis2024-02-19T13:02:10+01:00Hugo TrentesauxRemove change owner key from genesisIt is not possible anymore to change owner key in genesis. So we should panic if
```javascript
if (idty.value.old_owner_key != null) {
```It is not possible anymore to change owner key in genesis. So we should panic if
```javascript
if (idty.value.old_owner_key != null) {
```https://git.duniter.org/nodes/duniter-squid/-/issues/11listen to balances events to get the balance of an account2024-02-13T21:36:18+01:00Hugo Trentesauxlisten to balances events to get the balance of an accountThere are a lot of balances events (https://duniter.org/wiki/duniter-v2/runtime-events/)
![image](/uploads/61331b66e432ad38aa96a55cfc822ed1/image.png)
Some of them are meaningful (transfer), some are more technical (withdraw, deposit, ...There are a lot of balances events (https://duniter.org/wiki/duniter-v2/runtime-events/)
![image](/uploads/61331b66e432ad38aa96a55cfc822ed1/image.png)
Some of them are meaningful (transfer), some are more technical (withdraw, deposit, slash...).
Because they are common to any blockchain using the balances pallet, there is a chance that code already exist to deal with these.
Once these events are handled, we can create transaction timeseries view like what was prototyped in duniter-indexer (https://git.duniter.org/nodes/duniter-indexer/-/blob/e726bf9448f688e5df79c83e10893586eaade4e1/hasura/migrations/default/1671158661370_create_table_public_transaction_timeserie/up.sql).
If we do not take all events into account, the account balance will be false (for example not accounting for transaction fees).https://git.duniter.org/nodes/duniter-squid/-/issues/10add genesis linked accounts2024-02-12T16:28:04+01:00Hugo Trentesauxadd genesis linked accountsGenesis account can be already linked to an identity but only account_id is used.
https://git.duniter.org/nodes/duniter-squid/-/blob/28a9e7e1a09325115a45232aca522b9c74617b1e/src/genesis.ts#L40Genesis account can be already linked to an identity but only account_id is used.
https://git.duniter.org/nodes/duniter-squid/-/blob/28a9e7e1a09325115a45232aca522b9c74617b1e/src/genesis.ts#L40https://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/184Remove unused values in currencyParameters2024-01-31T13:00:25+01:00pokaRemove unused values in currencyParametersComme `minCertForMembership` par exemple. Ca permettrait d'éviter la confusion côté client.Comme `minCertForMembership` par exemple. Ca permettrait d'éviter la confusion côté client.https://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/duniter-squid/-/issues/2Add timestamp with historical values2024-01-22T11:20:49+01:00Hugo TrentesauxAdd timestamp with historical valuesIn transfer we have blockNumber as well as timestamp:
```
type Transfer @entity {
blockNumber: Int! @index
timestamp: DateTime! @index
```
This is convenient because:
- most UI will display timestamp to the user instead of blocknum...In transfer we have blockNumber as well as timestamp:
```
type Transfer @entity {
blockNumber: Int! @index
timestamp: DateTime! @index
```
This is convenient because:
- most UI will display timestamp to the user instead of blocknumber, so this avoids fetching time from blocknumber (but this is redundant)
- it allows to have the real v1 timestamp even when the blocknumber is 0 (genesis)
We could extend this to other places where there is a blocknumber to make migration more "smooth" for the users. This would for example allow to see the v1 history of membership.
In order to do this, we will have to add a `membership_history.json` and `certification_history.json` along with the `transaction_history.json` at the output of `py-g1-migrator`. This is a bit of work but is linked to the forum topic https://forum.duniter.org/t/v2s-smooth-gradual-migration-clients-and-indexers-side/9827.pokapokahttps://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/v2s-datapod/-/issues/1feat: check transaction id validity via RPC2024-01-15T19:29:57+01:00pokafeat: check transaction id validity via RPChttps://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-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/149update technical committee according to identities2023-11-29T21:52:44+01:00Hugo Trentesauxupdate technical committee according to identitiesThis could be nice to also update the technical committee when an identity changes its owner key.
We could also remove from technical committee and identity that is revoked.This could be nice to also update the technical committee when an identity changes its owner key.
We could also remove from technical committee and identity that is revoked.Horizonhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/145(opti) use StorageDoubleMap to store certifications2023-11-27T12:50:25+01:00Hugo Trentesaux(opti) use StorageDoubleMap to store certificationsThis could be a performance optimization.
https://paritytech.github.io/polkadot-sdk/master/frame_support/storage/trait.StorageDoubleMap.htmlThis could be a performance optimization.
https://paritytech.github.io/polkadot-sdk/master/frame_support/storage/trait.StorageDoubleMap.htmlHorizonhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/144Automatically publish ARM images of indexer2024-02-21T13:00:13+01:00Cédric MoreauAutomatically publish ARM images of indexerActuellement les images de l'indexeur ( `duniter/duniter-indexer` et `duniter/duniter-hasura`) sont publiés sur hub.docker.com uniquement en version amd64 :
* https://hub.docker.com/r/duniter/duniter-indexer/tags
* https://hub.docker.c...Actuellement les images de l'indexeur ( `duniter/duniter-indexer` et `duniter/duniter-hasura`) sont publiés sur hub.docker.com uniquement en version amd64 :
* https://hub.docker.com/r/duniter/duniter-indexer/tags
* https://hub.docker.com/r/duniter/hasura-indexer/tags
Il faudrait aussi disposer des images arm64, car cette architecture tend à se répandre dans le domaine des serveurs. Moi-même, mon serveur est de ce type.runtime-802https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/141Have a testing strategy2024-02-21T13:00:10+01:00Cédric MoreauHave a testing strategyImagine a testing plan to ensure the covering of:
* code (with coverage %)
* featuresImagine a testing plan to ensure the covering of:
* code (with coverage %)
* featuresruntime-802Cédric MoreauCédric Moreauhttps://git.duniter.org/nodes/rust/duniter-v2s/-/issues/130Implement a circular buffer double ended queue for quotas `RefundQueue` inste...2023-11-15T15:31:24+01:00Hugo TrentesauxImplement a circular buffer double ended queue for quotas `RefundQueue` instead of a vecIn !183, I wanted to use a `BoundedVecDequeue`, but it is not implemented in substrate yet.
See discussion https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/183#note_38444 for details.In !183, I wanted to use a `BoundedVecDequeue`, but it is not implemented in substrate yet.
See discussion https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/183#note_38444 for details.Horizon