* Parse internal refs to links
* Item mention notifications
* Also parse item mentions as URLs
* Fix subType determined by referrer item instead of referee item
* Ignore subType
Considering if the item that was referred to was a post or comment made the code more complex than initially necessary.
For example, notifications for /notifications are deduplicated based on item id and the same item could refer to posts and comments, so to include "one of your posts" or "one of your comments" in the title would require splitting notifications based on the type of referred item.
I didn't want to do this but also wanted to have consistent notification titles between push and /notifications, so I use "items" in both places now, even though I think using "items" isn't ideal from a user perspective. I think it might be confusing.
* Fix rootText
* Replace full links to #<id> syntax in push notifications
* Refactor mention code into separate functions
* Allow founders to transfer territories
* Log territory transfers in new AuditLog table
* Add territory transfer notifications
* Use polymorphic AuditEvent table
* Add setting for territory transfer notifications
* Add push notification
* Rename label from user to stacker
* More space between cancel and confirm button
* Remove AuditEvent table
The audit table is not necessary for territory transfers and only adds complexity and unrelated discussion to this PR.
Thinking about a future-proof schema for territory transfers and how/what to audit at the same time made my head spin.
Some thoughts I had:
1. Maybe using polymorphism for an audit log / audit events is not a good idea
Using polymorphism as is currently used in the code base (user wallets) means that every generic event must map to exactly one specialized event.
Is this a good requirement/assumption? It already didn't work well for naive auditing of territory transfers since we want events to be indexable by user (no array column) so every event needs to point to a single user but a territory transfer involves multiple users.
This made me wonder: Do we even need a table? Maybe the audit log for a user can be implemented using a view? This would also mean no data denormalization.
2. What to audit and how and why?
Most actions are already tracked in some way by necessity: zaps, items, mutes, payments, ...
In that case: what is the benefit of tracking these things individually in a separate table?
Denormalize simply for convenience or performance? Why no view (see previous point)? Use case needs to be more clearly defined before speccing out a schema.
* Fix territory transfer notification id conflict
* Use include instead of two separate queries
* Drop territory transfer setting
* Remove trigger usage
* Prevent transfers to yourself
* Only close notifications manually on iOS
* Use function instead of hardcoded string
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* refactor: Use log function in service worker
* Add verbose logging on push listener
* Fix TypeError: Cannot read properties of null (reading 'postMessage')
navigator.serviceWorker.controller is null on forced refreshes:
"""
This property returns null if the request is a force refresh (Shift + refresh) or if there is no active worker.
"""
-- https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/controller
This means when we unregister a service worker manually (like I do for debugging purposes) and then reload the page, there is no service worker available when this code is run.
Adding a check with a more helpful error message should improve UX.
This error might also happen in other cases where a page refresh should also help.
---------
Co-authored-by: ekzyis <ek@stacker.news>
* Merge notifications manually without relying on tag
* Use tag as argument
* Fix title and undefined sats in DEPOSIT push notification
* Remove wrong comment
* Fix wrong var used for tag check
* Also immediately display STREAK notifications
* Close all notifications with same tag manually before
* Fix merge of DEPOSIT notifications
* Remove unused tag from reduce argument
* Remove FIXME(iOS) comment
---------
Co-authored-by: ekzyis <ek@stacker.news>
This change makes resubscriptions backwards compatible by only running the new resubscribe code if the old push subscription was saved under service worker version 2.
Co-authored-by: ekzyis <ek@stacker.news>
* First pass of implementing Badging API for notifications
* Only show app badge when driven from push notifications
* Display number of unread push notifications instead of just an empty badge
Clear badge via postMessage when notifications page is loaded
* de-dupe some code, update badge counter on each notification click
* remove ids, track open note count instead
* restore optional chaining
* ensure note count doesn't go below 0, and fix event.waitUntil error when clearing badge
* incorporate PR feedback
* Also delete push subscription in IndexedDB
* Fix pushsubscriptionchange function signature
* Send SYNC_SUBSCRIPTION after successful registration
* Resubscribe if service worker lost subscription
---------
Co-authored-by: ekzyis <ek@stacker.news>
* Refactor service worker event listeners into own file
* Refactor service worker onPush listener
* Only show one MENTION push notification per item
* Update index.js to have newline
---------
Co-authored-by: ekzyis <ek@ekzyis.com>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* Add diagnostics settings & endpoint
Stackers can now help us to identify and fix bugs by enabling diagnostics.
This will send anonymized data to us.
For now, this is only used to send events around push notifications.
* Send diagnostics to slack
* Detect OS
* Diagnostics data is only pseudonymous, not anonymous
It's only pseudonymous since with additional knowledge (which stacker uses which fancy name), we could trace the events back to individual stackers.
Data is only anonymous if this is not possible - it must be irreversible.
* Check if window.navigator is defined
* Use Slack SDK
* Catch errors of slack requests
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Remove the static manifest file and serve it via an API route instead.
Change the background color of the PWA depending on the client hint provided data
Most browsers don't support the pushsubscriptionchange event.
We workaround this by saving the current push subscription in IndexedDB so we can check during every page load if the push subscription changed.
If that is the case, we manually sync the push subscription with the server.
However, this solution is not perfect as mentioned in https://medium.com/@madridserginho/how-to-handle-webpush-api-pushsubscriptionchange-event-in-modern-browsers-6e47840d756f which was used for reference:
> This solution is not perfect, the user could lose some push notifications if he doesn’t open the webapp for a long time.
Co-authored-by: ekzyis <ek@stacker.news>
* npm uninstall next-pwa
next-pwa was last updated in August 2022.
There is also an issue which mentions that next-pwa is abandoned (?): https://github.com/shadowwalker/next-pwa/issues/482
But the main reason for me uninstalling it is that it adds a lot of preconfigured stuff which is not necessary for us.
It even lead to a bug since pages were cached without our knowledge.
So I will go with a different PWA approach. This different approach should do the following:
- make it more transparent what the service worker is doing
- gives us more control to configure the service worker and thus making it easier
* Use workbox-webpack-plugin
Every other plugin (`next-offline`, `next-workbox-webpack-plugin`, `next-with-workbox`, ...) added unnecessary configuration which felt contrary to how PWAs should be built.
(PWAs should progressivly enhance the website in small steps, see https://web.dev/learn/pwa/getting-started/#focus-on-a-feature)
These default configurations even lead to worse UX since they made invalid assumptions about stacker.news:
We _do not_ want to cache our start url and we _do not_ want to cache anything unless explicitly told to.
Almost every page on SN should be fresh for the best UX.
To achieve this, by default, the service worker falls back to the network (as if the service worker wasn't there).
Therefore, this should be the simplest configuration with a valid precache and cache busting support.
In the future, we can try to use prefetching to improve performance of navigation requests.
* Add support for Web Share Target API
See https://developer.chrome.com/articles/web-share-target/
* Use Web Push API for push notifications
I followed this (very good!) guide: https://web.dev/notifications/
* Refactor code related to Web Push
* Send push notification to users on events
* Merge notifications
* Send notification to author of every parent recursively
* Remove unused userId param in savePushSubscription
As it should be, the user id is retrieved from the authenticated user in the backend.
* Resubscribe user if push subscription changed
* Update old subscription if oldEndpoint was given
* Allow users to unsubscribe
* Use LTREE operator instead of recursive query
* Always show checkbox for push notifications
* Justify checkbox to end
* Update title of first push notification
* Fix warning from uncontrolled to controlled
* Add comment about Notification.requestPermission
* Fix timestamp
* Catch error on push subscription toggle
* Wrap function bodies in try/catch
* Use Promise.allSettled
* Filter subscriptions by user notification settings
* Fix user notification filter
* Use skipWaiting
---------
Co-authored-by: ekzyis <ek@stacker.news>
* Use next-pwa
* Use standalone + back button
* Use Notification API
* Use custom service worker
* Use url_handlers
* Add offline page
* Use smaller icon in notification
* Only prompt for notifications if logged in
* small enhancements to standalone pwa
* remove unused back arrow
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
ekzyis
ekzyis
keyan
SatsAllDay
ekzyis