What are the top 10 highest priority vLEI related KERI issues? - Updated 20240909

[2byrds]

UPDATED Priority list:

1. High: Integration Tests are failing on 0.4.0 of KERIA: Integration tests fail against dockerhub's KERIA 0.4.0/latest image signify-ts#392
2. High, Production: Proposal: run integration tests on PR  keria#233
3. High, Production: How to do graceful shutdown of KERIA keria#175
4. High, Partially implemented: Implement backup and restore keria#37
5. High: High CPU usage while idling after running for a while  keria#232
6. High: Add debug level logging for failed processing of events in parsing.py keripy#763
7. Medium: Support AID instead of or in addition to name in URLs that require it keria#217

This is now tracked as a project here KERIA + Signify Prioritized backlog (view)

Please respond here with any issue (no matter how old) from a KERI-related repo that you would like highlighted at the KERI dev meeting on Thursdays. To gamify it we will highlight the issue at the meeting and then discuss if it belongs in the top 10 vLEI related issues.

IN REVIEW:

1. Blocker, Production, Intermittent: Internal Server Error when trying to query oobi for delegated multisig AID keria#231
2. Blocker, Production: Provide support for passcode rotation keria#222

Needs Consideration:

1. Rollback of partially signed events: Members of multisig group can become out of sync without a way to recover keria#213 - to be able to correct user mistakes, this is crucial. Otherwise we cannot recover a multisig AID when two of their members have diverging KELs for the the group.
2. Filter operation by status: Feature request: filter operations by status keria#192 - to be able to inform the users that there are unresolved operations. This can be done by filtering on the client side, but it will not work forever as long as the list of operations grows.
3. Feature request: hot standby and failover keria#240
4. Feature request: a way for a multisig member to catch up updates keria#283

Previously Considered:

1. Medium, Production, Partially addressed: Handling of special characters and white space in alias names signify-ts#204
2. Medium, Workaround available: Clarification regarding multisig OOBI keria#171
3. Medium: Long running operation set to done before dependencies are done keria#200

Thank you for previous feedback from @lenkan @kentbull @nkongsuwan @pfeairheller @daviddm

FIXED:

• multisig-rotation-in-third.sh error "ERR: invalid rotation, new key set unable to satisfy prior next signing threshold" unless participant keys rotated and queried keripy#773
• Blocker, Production, Intermittent: witness: Internal Server Error when trying to query oobi for delegated multisig AID keripy#762
• Internal Server Error when issuing credential containing ÅÄÖ keria#201
• Fix tracking of smids and rmids keripy#694
• New database tables for tracking Habs and multisig participants. keripy#734
• Document the extension protocol signify-browser-extension#155
• Blocker, Depends on 694 which is fixed: Agent of delegator cannot resolve oobi of a delegate keria#230
• Blocker, Production: Multisig join never resolves signify-ts#227
• Blocker, Production: Internal Server Error on connect after upgrade from 0.1.2 to 0.2.0-dev2 when agent contains group hab keria#257
• Medium: client.keyStates().query() does not work without sn keria#184
• Blocker, Production: Provide a way to re-submit AID KEL to witnesses keria#235

[kentbull]

Nice work lance! This list is really shaping up.

[2byrds]

Possibly add labels to issues to add them for consideration. For instance we use effort-eval-needed now.
An if you have an idea on the LOE, etc.

[lenkan]

Also added this WebOfTrust/keria#235 as a follow up from WebOfTrust/keripy#762

[edeykholt]

Should we list strategic priorities as a separate list? Maybe not stack ranked, and what would help the ecosystem more generally.

• KERIA hot standby / Feature request: hot standby and failover keria#240
• Watcher Network
• ...

[lenkan]

During testing, we have found two issues that we think needs priority:

Rollback of partially signed events: WebOfTrust/keria#213 - to be able to correct user mistakes, this is crucial. Otherwise we cannot recover a multisig AID when two of their members have diverging KELs for the the group.

Filter operation by status: WebOfTrust/keria#192 - to be able to inform the users that there are unresolved operations. This can be done by filtering on the client side, but it will not work forever as long as the list of operations grows.

[2byrds]

During testing, we have found two issues that we think needs priority:

Rollback of partially signed events: WebOfTrust/keria#213 - to be able to correct user mistakes, this is crucial. Otherwise we cannot recover a multisig AID when two of their members have diverging KELs for the the group.

Filter operation by status: WebOfTrust/keria#192 - to be able to inform the users that there are unresolved operations. This can be done by filtering on the client side, but it will not work forever as long as the list of operations grows.

Thank you @lenkan I have added those two to the 'Needs Consideration' list

[lenkan]

@2byrds and others. What do you think about converting this into a github project? I would like to track issues beyond their closures, and also be able to have a better overview of what is planned for the future and how that work is being prioritized.

At the moment, when an issue is closed because a PR is merged, it does not always mean that the work is completed. Often, it needs further reviewing, patching of old release branch, update of downstream repositories, and last but not least a lot of testing. In a github project, you can represent these stages as different columns.

As for the priority and backlog - at the moment there are a lot of older issues across the repos that make up the vLEI ecosystem. Most of these do not receive any attention. Some of them can be closed, some of them might be easy fixes.

[2byrds]

@2byrds and others. What do you think about converting this into a github project? I would like to track issues beyond their closures, and also be able to have a better overview of what is planned for the future and how that work is being prioritized.

At the moment, when an issue is closed because a PR is merged, it does not always mean that the work is completed. Often, it needs further reviewing, patching of old release branch, update of downstream repositories, and last but not least a lot of testing. In a github project, you can represent these stages as different columns.

As for the priority and backlog - at the moment there are a lot of older issues across the repos that make up the vLEI ecosystem. Most of these do not receive any attention. Some of them can be closed, some of them might be easy fixes.

@lenkan I support that idea. I have tracked the priority, etc. of several of these issues in a github project related to our joint work but doing it as a vLEI community project makes sense to me.

[2byrds]

Okay the project is here @lenkan KERIA + Signify Prioritized backlog (view)