Skip to content
This repository has been archived by the owner on Feb 13, 2024. It is now read-only.

Notifications - persistence and use for more than just tasks #547

Open
usingtechnology opened this issue Jul 14, 2021 · 1 comment
Open

Comments

@usingtechnology
Copy link
Contributor

For the activity log and tasks, we should create it's own persistence layer. Right now, we are simply querying proof and connection tables for certain states. If a partner is removed, then we would remove all the history of connecting (which may be a valid thing to store). Also, persistence would allow the end user to hide/remove items from the Activity Log.

Also, we should revamp the notification system to include automated cases. For instance, when a partner is auto-added, or presentation is auto accepted/handled. Notifications can be classified to indicate task versus activity (so the user knows understands to open the Activity log to see what has happened.)

@swcurran
Copy link

Agreed on the persistence -- IMHO -- the secure storage in the Agent should only be used for current agent activities (ledger objects/private keys, connections, held credentials, in-flight protocol state objects). Persistence beyond that should be in a controller (e.g. BPA) database -- linkages between connections and contacts/partners, presentations requested/provided, credentials issued, etc.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants