Undocumented Duniter concepts

I’m creating this thread to list undocumented Duniter concepts that I do not understand or that I do not have time do document in the code yet.

1 Like

I started documenting in the code why we have an AccountData different from substrate’s one. Still not very clear to me, but has to do with the random_id: Option<H256> which also has to be documented.

(see La solution pour des identicones sécurisées: le random id for reference)

  • accounts corresponding to an identity are allowed to exist without deposit

AccountIdToSalt the account id (e.g. 32 bytes of pubkey) is used as a salt to generate the random id from the vrf.

MaxNewAccountsPerBlock. Seems to be related with the random id. Not sure why we would limit the number of new accounts per block in an other way that extrinsic costs provides if not for random id. I whish we could remove this layer of complexity which makes the migration more difficult to perform as there is more useless code to understand, test, and document. But apparently for @elois this is the opposite:

Same for PendingRandomIdAssignments, PendingNewAccounts, RandomIdAssigned event… What a level of complexity for a feature that does not make consensus, will not be implemented in the main clients, and was added by a guy blaming other for slowing down the migration process.

1 Like

Duniter cli commands are mainly managed directly by substrate. But you should know that Duniter itself introduces subtleties. For example the build-spec command ignores the DUNITER_GENESIS_CONFIG environment variable if you provide --chain gdev and not --dev. But since it’s not documented you have to read the (without comments) code to get it. That’s an example why relying on environment variable is weak because it short-circuits substrate command line parsing.

WASM_BINARY ad WASM_BINARY_BLOATY is a Substrate concept but is seems very strange. I have to understand what it is and document it.

[edit] What are the differences between WASM_BINARY and WASM_BINARY_BLOATY - Polkadot Forum

IdtyCertMeta has a next_issuable_on field and IdtyValue have next_creatable_identity_on field. I do not understand yet how these two work together.

Membership events are defined both in Duniter primitives and Membership pallet:

in Duniter primitives

pub enum Event<IdtyId, MetaData = ()> {
    /// A membership has acquired
    MembershipAcquired(IdtyId, MetaData),
    /// A membership has expired
    MembershipExpired(IdtyId),
    /// A membership has renewed
    MembershipRenewed(IdtyId),
    /// An identity requested membership
    MembershipRequested(IdtyId),
    /// A membership has revoked
    MembershipRevoked(IdtyId),
    /// A pending membership request has expired
    PendingMembershipExpired(IdtyId),
}

in Membership pallet

pub enum Event<T: Config<I>, I: 'static = ()> {
    /// A membership has acquired
    /// [idty_id]
    MembershipAcquired(T::IdtyId),
    /// A membership has expired
    /// [idty_id]
    MembershipExpired(T::IdtyId),
    /// A membership has renewed
    /// [idty_id]
    MembershipRenewed(T::IdtyId),
    /// An identity requested membership
    /// [idty_id]
    MembershipRequested(T::IdtyId),
    /// A membership has revoked
    /// [idty_id]
    MembershipRevoked(T::IdtyId),
    /// A pending membership request has expired
    /// [idty_id]
    PendingMembershipExpired(T::IdtyId),
}

Not sure if it is useful or redundant.