I would like to start a discussion around collaboration in our ecosystem and how we should collectively be making decisions in how we design common good repos - thus ensuring that they can be used effectively by multiple parties to produce the best possible products for our end users. We should not ringfence things so that it is very specific to our own products, and even in this case below, remove data which is utilized by other parties.
The particular case that I am referring to is that of the OpenGov delegate registries. This is something that myself and the Nova Wallet team are super passionate about, and it was something that we were very proud to implement and provide for the community.
Our solution has been live for months at this point, and is very well liked by the community. Delegate candidates can post the following information:
- address: Your on-chain address
- name: Your display name, such as Leemo
- image: Your profile picture
- shortDescription: A 180 character preview description
- longDescription: A fully customizable markdown format description of you or your organization
- isOrganization: Boolean indicating whether or not the candidate is an organization
I would like to once again emphasize that our product has been live for months at this point, and the parameters in our repo offer all of the data which would be required by the Parity dashboard.
| novasamatech repo | paritytech repo |
|---|---|
| name | name |
| address | address |
| longDescription | manifesto |
| shortDescription | No option |
| image | No option |
| isOrganization | No option |
Please refer to this PR which clearly shows that those working on the paritytech repo must’ve been aware of the information which Nova Wallet utilizes.
I would also like to mention that I had spoken to someone from Parity who was working on the Delegation Dashboard and raised these concerns. I raised the point that when Parity creates their own delegate registry, it will become the defacto registry used by the community. That appears to have somewhat fallen on deaf ears unfortunately.
Disadvantages of Parity Solution
There are a few areas which I would personally consider as disadvantages with the current Parity solution. As stated above, it is very clear that this delegate registry will become the defacto registry going forward where the vast majority of the community will submit their delegation candidacy:
- No image parameter for candidates to leverage their existing social capital
- This very clearly was being used by Nova Wallet and other solutions such as OpenGov Insights
- Builders can choose to not utilize this image parameter in their products
- Not including this parameter worsens existing products, as users cannot leverage their social capital which they will be proud of and will have worked hard towards fostering their own reputation, a lot of which may be tied to their profile picture.
- No individual / organization tag – which removes some context for those looking to delegate their voting power
- No verification for Pull Requests
- I would like to know a bit more about this from the paritytech perspective. At Nova we required accounts signing up to the registry to issue a system.remark with their github username:PR number. This ensures that the person submitting the PR and the on-chain account are controlled by the same person.
- What checks are in place to ensure that the “name” field submitted by the user matches their on-chain ID? In the delegation dashboard, it does not use the on-chain ID, it uses the “name” field from the repo – this is why it is important to ensure that the submitter has a verified on-chain ID and the ID somewhat matches the info in the “name” field.
What happens if we fail to cooperate
If we fail to cooperate it will further fragment the community. I believe that it is far too much to ask users to fill out their candidacy information in multiple repos in different formats. This could lead to 2 possible scenarios:
- Every wallet, every delegation dApp, etc. would require it’s own register if they tailored it to be very specific to their own product – it is why the paritytech repo must be very general and include more parameters, such as the image field. IMO it is very obvious that the paritytech repo would become the default repo. I believe we should have an open discussion about what information the registry should include, which can allow people to make amazing products using that information.
- Projects that wish to make a competitor to the paritytech dashboard will be limited only to the information which the paritytech delegate registry requires (since there is 0 point in making a competing registry if the paritytech one will be the only one referenced in all official media)
I really do believe that in order to have a healthy ecosystem, users should have many competing products and should be able to make a choice about which product they want to use to complete a certain task, be that the Parity Delegation Dashboard, Nova Wallet’s Delegation Interface, or any other project’s solution.
However, we need to be realistic and understand that when a certain information repo is pushed through the official channels, etc. it will become the standard, and as such that standards needs to be general enough to be used by other solutions without sacrificing features.
The path forward
I strongly believe that it is not too late to change the paritytech delegate registry so that it can be more generic and be used by other applications with Governance functionalities without sacrificing upon their existing functionality, and allowing projects to build competing products (a healthy thing).
I understand that this was probably decided by a group of engineers who were focused on making a product with the leanest code possible, however I think we as an eco need to become more product orientated and think about what projects which may use our repos would want, and ultimately what the end users would like to see.
The ethos of our ecosystem should be interoperability and collaboration – let’s please try to show this as a good example of how we can work together.