feat(lite): ⚠️ Proof of Concept: Client-Side Notifications (PWA) #117
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status:
Experimental/Do Not MergeMotivation
This PR explores a feature I believe would be a valuable addition to the Morpho app: automated user notifications. As a user, I want to be alerted about critical changes to my positions - such as a Health Factor dropping below a specific threshold or a significant dip in APY for supplied assets - without constantly monitoring the interface.
While there are existing solutions that solve this via server-side monitoring and messaging layers (Email, Telegram, etc.), they typically require sacrificing privacy by sharing user data with a centralized service.
Proposed Solution
I propose a privacy-first, client-side solution leveraging Progressive Web App (PWA) capabilities and Service Workers.
By converting the Morpho app into a PWA, we can run background processes locally on the user's device. This allows for:
Future UX Vision
While this PR focuses on the underlying architecture, I envision the final implementation featuring a "Notification Center" (e.g., a Bell icon in the header).
This UI component would allow users to:
Implementation Overview
This PR demonstrates the feasibility of this architecture through three main steps:
Technical Notes, Trade-offs & Workarounds
viemdirectly within the Service Worker due to restricted dynamic imports in that environment.eth_call. This required adjustments to thewagmi-config.borrow-subpagehooks had to be duplicated/re-implemented for the worker context. A future refactor would be needed to abstract this shared logic into pure TS functions compatible with both environments.5. This allows testing the notification flow by taking a real, low-risk loan (high HF) and still receiving the alert immediately.eth_callpolling from every client's background worker could strain public RPC endpoints. A production version could allow the user to input their own custom RPC URL to avoid rate limits.