Notification Lifecycle Commands

[amydevs]

Description

This PR implements inbox and outbox subcommands for the notifications command. We have never used two layers of subcommands in other domains, so my usage of such needs to be reviewed.

Issues Fixed

• Fixes Asynchronous Notification Architecture and Notification Lifecycle Commands #168

Tasks

• 1. inbox read
• 2. inbox clear
• 3. outbox read
• 4. outbox clear

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[CMCDragonkai]

How come the issue was closed if this is fixing it?

[CMCDragonkai]

@aryanjassal might have some commentary here in terms of inspecting the notifications.

Maybe if the polykey agent status could provide some information to the end user.

[CMCDragonkai]

Hey @amydevs do not do version bumps in a feature branch!!! It can only be done in staging!!!!

[tegefaulkes]

Hey @amydevs do not do version bumps in a feature branch!!! It can only be done in staging!!!!

That seems to be updating a dependency's version, is that an issue? I've done this before in branches, usually when the new version has changes specific to some feature I'm working on.

[amydevs]

@tegefaulkes i think roger was mistaken due to the CI job failure

[amydevs]

@CryptoTotalWar do u have any suggestions? if not, i'll merge and and start working on audit

[CryptoTotalWar]

@CryptoTotalWar does everything look good? if so, i'll merge and and start working on audit

What am I reviewing specifically?

Also curious, similar to how we have feature-x.dev branches for polykey.com , is there such thing for Polykey CLI on some sort of testnet? That way we can do some real user interactions on a testnet before deploying to mainnet.

Furthermore, reading the issue ticket for the PR, it helps me understand a bit more context about what this PR is aiming to solve for but without having screenshots of it being tested, it's hard to know... anyway it boils down to actually being able to test new functionality and document the user-flow from a UX perspective.

[amydevs]

@CryptoTotalWar i mistyped sorry, i meant more so if u have any feedback from the process that you experienced in polykey regarding the notifications system throughout your usage

[CMCDragonkai]

@CryptoTotalWar does everything look good? if so, i'll merge and and start working on audit

What am I reviewing specifically?

Also curious, similar to how we have feature-x.dev branches for polykey.com , is there such thing for Polykey CLI on some sort of testnet? That way we can do some real user interactions on a testnet before deploying to mainnet.

Furthermore, reading the issue ticket for the PR, it helps me understand a bit more context about what this PR is aiming to solve for but without having screenshots of it being tested, it's hard to know... anyway it boils down to actually being able to test new functionality and document the user-flow from a UX perspective.

Yes there is it's called testnet.polykey.com.

[amydevs]

Asked @CryptoTotalWar about the new commands and he said they seem sensible, merging now.