Ğ1nkgo v2 support progress, plan and pubkeys/address proposal

[vjrj]

I’m making a lot of progress with v2 support in G1nkgo and trying to support v2 gradually while maintaining v1 by finding time here and there on weekends and late-nights.

When I first tried the current v2 clients, I got a bit confused when using my main account. The lack of the classic avatars at the time, or the use of a new address (and not my classic v1 public key), not to mention the bip39 support only in English (a topic that has been discussed in this forum), confused me a lot.

My ideal is that the transition to v2 for the people in our community (“humans”) is as simple and transparent as possible. Basically that everything should work the same or better for them, faster, more robust and that there are not many difficulties, migrations, etc. That’s why I’m trying to support v2 in the same g1nkgo code and with the same user interface simultaneously.

There is one topic I want to talk about now, mainly, and it is the topic of public keys (the ones that were displayed in v1) and addresses derived from v2.

The people in my community have their public keys memorized, they have them printed and laminated in their markets, etc. Sometimes people use that pubkey to distinguish themselves from others (if they have very common names), and sometimes they have only simple wallets (people who do not want to be certified despite everything) and they always come with their public key written down.

Changing those public keys for those people would be a bit catastrophic, like changing my mother’s phone numbers and address book or changing her TV channels :-). So my proposal is to continue using the public keys from v1 and the new addresses from v2 transparently. I don’t know if this was discussed before, sorry.

In g1nkgo, right now, you can enter contacts, or search for people, or scan qrs with both (public keys from v1) and with others (5xxx addresses from v2). [1].

sin mucho esfuerzo
In this screenshot I show a part of my contacts with old/new keys. I would even like to only display the v2 address on new accounts (created after some date or similar) and the old key on accounts created in v1. Two keys is confusing.

In this sense I am not going to migrate any old g1nkgo wallets o (cesium v1 ones), those wallets will simply continue to operate with the v2 nodes using the v2 addresses while their v1 public key will be displayed. And the new created wallets will operate with the new v2 addresses and will be known as such. Or this is my goal, I think is technically posible.

I would like the rest of the clients (gecko/cesium2) to do something similar, to avoid confusion for our community. I was talking this weekend with @kapis and he liked the idea and I think he’ll try to do something similar in superbot.

Thanks and sorry for the length.

Bests,

[1]: Here is a snapshot of G1nkgo that I had no time to finish and stabilize this weekend so it’s not ready to publish it but it’s ok for some tests. See the switch:

and try to do some searches with different keys.

Update: Sorry I’ve just updated the snapshot with a more recent one

[HugoTrentesaux]

On b58 - ss58

@vjrj

the use of a new address

I agree that transition should be as simple and transparent as possible. It is fine to use b58 keys like in v1. I also did a post to explain why ss58 is a good idea (in French, but code examples should be understandable Format de clé et vérification - #3 by HugoTrentesaux), and that’s why it’s the format used internally in the v2 tools (like duniter-squid use this as primary key for accounts).

Your suggestion of keeping b58 for old accounts and ss58 for new accounts seems reasonable. The only challenge I see is to persist it between tools. For example if people re-install Ğinkgo on an other phone and import their accounts, the address format should be unchanged. We could add a helper field server-side in duniter-squid like a boolean “existed_in_v1”.

That way, Cesium also can choose to display b58 instead of ss58 if the account existed in v1. Do you think it would fix the issue?

---

Other topics

@vjrj

lack of the classic avatars at the time

You mean Cesium+ avatars? In which tools?

@vjrj

bip39 support only in English

True. Even old key generation methods are still perfectly valid.

[vjrj]

@HugoTrentesaux

That way, Cesium also can choose to display b58 instead of ss58 if the account existed in v1. Do you think it would fix the issue?

Off course. I was hoping that something similar exist already.

@HugoTrentesaux

You mean Cesium+ avatars? In which tools?

Yes, Cesium+ avatars. I know that Cesium2 is starting to implement datapod profiles.

Also my balance confused me, and the non member message.

Thanks indeed for your detailed reply.

[HugoTrentesaux]

Ok, I’ll be adding this. Tracked in #39. We can even specify block number of account creation and see if it is negative or positive.

About datapod profiles, Cesium2 should have them everywhere when available. However, the profiles imported in datapod are the one from import date. I can re-do the import to add profiles that were added later on. I added #23 to remind me of this.

What confused you about the balance? It is the one on gdev network. The non member message is also about gdev network. You can renew your membership by requesting distance evaluation, we have to add this in Cesium v2 (#4 and #36). In the meanwhile, you can do it with gcli or duniter panel.

[Maaltir]

@vjrj

]: Here is a snapshot of G1nkgo that I had no time to finish and stabilize this weekend so it’s not ready to publish it but it’s ok for some tests. See the switch:

and try to do some searches with different keys.

Ce bouton "Test V2, c’est juste pour pouvoir utiliser les clés au format V2. Tout en restant sur les nœuds DuniterV1.
Ce n’est pas vraiment pour tester la V2 de Duniter.
La V2 de Duniter fonctionne actuellement avec la Gdev, puis ce sera la Gtest, et enfin la G1 après la bascule.
Est-ce que tu prévois une version différente de Ğ1nko pour chaque monnaie, ou l’utilisation d’un “radio bouton” pour passer de l’un à l’autre ?

---

This ‘Test V2’ button is just to be able to use the keys in V2 format. While remaining on the DuniterV1 nodes.
It’s not really for testing Duniter V2.
Duniter V2 currently works with Gdev, then it will be Gtest, and finally G1 after the switchover.
Are you planning a different version of Ğ1nko for each currency, or the use of a ‘radio button’ to switch between them?

[vjrj]

@HugoTrentesaux

About datapod profiles, Cesium2 should have them everywhere when available. However, the profiles imported in datapod are the one from import date. I can re-do the import to add profiles that were added later on. I added #23 to remind me of this.

I’m there, but for some reason my profile was not visible in cesium2
https://duniter--vue-coinduf-eu.ipns.pagu.re/#/data/5DpRqhjEof2WMFoAYTAqqoQzyBH9zRRmAbBZGQm9uZSzNeY6
minor issue.

@HugoTrentesaux

What confused you about the balance? It is the one on gdev network.

But 300K? Newbie question probably … I was expecting some amount similar in size to my current balance (few thousands).

@HugoTrentesaux

The non member message is also about gdev network. You can renew your membership by requesting distance evaluation, we have to add this in Cesium v2 (#4 and #36). In the meanwhile, you can do it with gcli or duniter panel.

Merci! I was expecting to maintain my membership after the migration, without extra steps.

@Maaltir

Ce bouton "Test V2, c’est juste pour pouvoir utiliser les clés au format V2. Tout en restant sur les nœuds DuniterV1.
Ce n’est pas vraiment pour tester la V2 de Duniter.

When this button is on, I start to use v2 api calls instead of v1 calls, or to adapt the views to the v2 reality. But currently this part is a mix of v2 and v1 api calls. When I finish a new equivalent v2 call I start to use it here and there. Now I’m finishing the datapod part. In short I’ll continue with the transactions, later with the payments. The idea is to work similarly. But internally, many things are already adapted to v2 data.

My idea is to build only a single g1nkgo version for v1 and v2, and to start to use the v2 automatically proably via checking:

nodes / networks · GitLab

or similar. The switch is only to test this during this phase, but with be not present in the future.

Good night,

[vit]

@vjrj

But 300K? Newbie question probably … I was expecting some amount similar in size to my current balance (few thousands).

gdev has very particular properties, which gives you some insane amount on accounts and some very short delays. Dont be afraid of it, it is just to allow developers to observe a long running blockchain in a short time.

[HugoTrentesaux]

@vjrj

maintain my membership after the migration, without extra steps

query MshipHistory {
  identity(where: {name: {_eq: "vjrj"}}) {
    name
    createdOn
    membershipHistory {
      blockNumber
      eventType
    }
  }
}

{
  "data": {
    "identity": [
      {
        "name": "vjrj",
        "createdOn": 0,
        "membershipHistory": [
          {
            "blockNumber": 0,
            "eventType": "CREATION"
          },
          {
            "blockNumber": 1173454,
            "eventType": "REMOVAL"
          }
        ]
      }
    ]
  }
}

Your identity was indeed imported as member in the genesis but expired at block 1173454 due to expired membership :

You can see that the UDs were automatically claimed, whereas when member, you have to claim the UDs manually to receive them. Vit answered about the amount of UD. You can see them in duniter panel using a squid 0.2.7 endpoint.

[kapis]

Incredible job @HugoTrentesaux and other devs in the Duniter panel, i just tried with the duniter-connect extension…

and there i saw the option to request the dinstance evaluation, although i was already a member… (heheh i’m not sure when the block expiry is exactly in date approximation)

[HugoTrentesaux]

Ok, thanks for the feedback, I added #10 and #11 to track this. I knew that I had to improve this, but this is so easy to forget with the workload that a rekindle is welcome ^^

[vjrj]

Thanks indeed for all the clarifications. I was just trying to say what I was expecting something “similar” in my account than in v1 (in terms of look and feel, membership, amount, address, etc) and it wasn’t the case.

Just to show my point of view about to do the migration smoothly.

[vjrj]

Tese are the things I think we shall avoid in the migration IMHO. I was using cesium2 these months but some days ago I installed gecko and I imported my account. So now I have a differenf address with my balance and no history and my balance at cesium2 is zero, of course.

From the point of view of a normal user is quite confusing.

[poka]

Ğecko talks / user support

Je rappel …

Cesium² : top départ!

Nouvelle M…

Fix in latest cesium2 MR.

[vjrj]

To be more clear: I think we should avoid this type of migration in our current wallets and public keys (and addresses).

My ideal is to migrate the network to v2 and that the users do not see more than improvements. The use of bip39 is not necessary for existing wallets IMHO. In other words: We should continue asking for pass/passphrases to old wallets (or nothing for ginkgo/superbot basic wallets) and only use bip39 in new accounts (if we don’t find nothing more usable). Derivations? Not now for them.

[poka]

Depends of usecases. Scan the derivative range and you avoid any problems and offers asked feature (multiple wallet unify under same auth). This is simple for users.

About Salt/passwords, they proved to be a real problem for users.
As we’re moving from pubkey to ss58 addresses, the migration is the best opportunity to offer a better form of key generation.
But not all Wallets have to follow the same strategy, as long as we make the minimum effort to ensure compatibility between the main tools.

Ğecko allow users to migrate salt/password to secure wallets.

For instance, please inform us if you change your export wallets format to allow us to maintain Duniter connect compatibility.

Please do not hesitate to ask us how we design our walletsw since we took time to understand what you do with g1nkgo to ensure to offer smooth usage between tools

[vjrj]

I mean, Iwas using cesium2 without any transfer between address maintaining my pubkey visible, etc.

Anyway, I think I explained a lot my point of view in this thread.

@poka

Please do not hesitate to ask us how we design our walletsw since we took time to understand what you do with g1nkgo to ensure to offer smooth usage between tools

Thanks. And yes, all takes time: Ğ1nkgo v1.3.1 published ,