1.0.0 Feature Freeze

[joshuakarp]

After the testnet deployment, the next stage of development with Polykey should be focusing on tying up the loose ends, such that we can perform our initial release!

We shouldn't be focusing on introducing new features (hence, "feature freeze"), and instead be looking at making the current state of Polykey as robust as possible.

Using this epic primarily as a means of categorising issues that should be a part of this enhancement process.

Template and description TBD

[CMCDragonkai]

Should this #268 be before or after this gets done? I reckon we should release for test usage, and use this epic to organise everything that needs to be done for a 1.0 release.

[joshuakarp]

I reckon we should release for test usage, and use this epic to organise everything that needs to be done for a 1.0 release.

This seems reasonable to me. I'd actually forgotten that we had #268. In that case, perhaps these should all be moved to #268? I was moreso treating this epic as just an interim container for all of the issues that I view as being important to finish up before an initial release, so this can be organised in another way if preferred..

[CMCDragonkai]

I think this issue can be made into a release version issue. Like Release 11.0 or something. That makes it a feature freeze, and then work out all the final problems/optmisations/bugfixing/code quality issues.

[CMCDragonkai]

Some KeyManager quick fixes:

1. Don't need to read from the file when you are always just changing the keys, as it is expected nobody else can swap them around, use the in-memory key which should only be this._dbKey
2. Should be using locks to lock the operations on the key renewal, right now race conditions can occur in the side effects there.
3. Proper documentation on where subkeys are supposed to be located and managed by who like vault key, db key and session manager key.

[CMCDragonkai]

The error in:

class ErrorClientInvalidNode extends ErrorClient {
  exitCode: number = 70;
}

requires a proper review. It seems weird. Should this really be in client/errors.ts?

[CMCDragonkai]

I noticed that some exceptions are Missing and some are NotFound. So far no Required.

We should standardise on which suffix we use to mean these things.

[CMCDragonkai]

All uses of fail should be replaced with expectations. Details here: https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/213#note_742208447

[CMCDragonkai]

Should replace all use of poll in our tests/utils.ts with src/utils.ts. Any timeout usage should be done with timerStart and timerStop.

[joshuakarp]

Some very rough time estimates for the current state of this epic. Time estimates include planning, research, development, review and testing times:

• Canonicalise node ID representation #261 + Refactor NodeId as a proxy/singleton instance #254 (would be done concurrently): 3 days
• NAT-Traversal Testing with testnet.polykey.io #159: should be done as part of testnet deployment (have removed from this issue for that reason)
• Fix Concurrent Testing Scalability - Find Blocking Code, Make them Non-Blocking #264: 5 days
• Agent spawning tests require refactoring. #238: will be completed by Implementing BIP39 recovery, Unattended Bootstrap and Agent Start and Status #283
• Optimise the execution time of PK CLI calls by not importing the entire kitchen sink #277: 2 days (should only require some benchmarking, and potential adjustments)
• Investigate and fix random NodeGraph test failures #274: 1 day
• Support read-after-write consistency for NodeGraph bucket operations #244: 2 days
• Transport Agnostic RPC #249: a fair bit more to consider here, so I'd overestimate at 7-10 days

[CMCDragonkai]

Mostly all done. We're going to do a testnet deployment in a couple days. Closing this.