Commit Graph

31 Commits

Author SHA1 Message Date
SatsAllDay 852d2cf304
@remindme bot support (#1159)
* @remindme bot support

support reminders via @remindme bot, just like @delete bot

* minor cleanup

* minor query cleanup

* add db migration

* various fixes and updates:

* hasNewNotes implementation
* actually return notification component in ui
* delete reminder and job on item delete
* other goodies

* refactor to use prisma for deleting existing reminder

* * switch to deleteMany to delete existing Reminders upon edit/delete of post to satisfy prisma

* update wording in form toast for remindme bot usage

* update wording in the push notification sent

* transactional reminder inserts and expirein

* set expirein on @delete too

---------

Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
2024-05-19 15:52:02 -05:00
ekzyis 796bd4dc4b
Add autowithdrawal badge in notifications (#1078) 2024-04-16 10:53:05 -05:00
ekzyis 922d2394fd Remove unnecessary withdrawl field 2024-03-26 02:10:46 +01:00
ekzyis 3388f818cf Add withdrawal notifications 2024-03-26 00:50:48 +01:00
ekzyis b379e7467f
Territory transfers (#878)
* 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
2024-03-05 13:56:02 -06:00
ekzyis bdf9b1f0fd
Territory post notifications (#745)
* Notify founders of new posts

* Only merge notifications of same territory

* Show territory posts in /notifications

* Don't notify on own posts
2024-01-11 11:27:54 -06:00
keyan 717f8d1ef6 territory billing notifications 2024-01-03 15:20:10 -06:00
keyan 10203f565c territories 2023-12-04 21:34:06 -06:00
SatsAllDay 94fbabcdf9
Notifications for when you are forwarded sats from a post (#467)
* Notifications for when you are forwarded sats from a post

Support notifications when a post for which you are forwarded gets zapped

This is controlled by a new boolean flag in user settings

* Send push notifications to forwarded users when they get forwarded sats

* Add `Promise.allSettled` per PR feedback

* Remove `FEE` act type when building forwarded zaps notifications

Don't include `FEE` actions, only `TIP` actions to avoid "0 sats forwarded" notifications

---------

Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
2023-09-12 10:31:46 -05:00
keyan b6c822f40e allow viewing reward ranges 2023-08-29 19:13:21 -05:00
SatsAllDay 0d4a225442
Subscribe to a user (#443)
* First pass of user subscriptions

* add new db model to track subscriptions
* update user typedef and api resolver for subscription state
* add subscribe action to user profile page
* add mutation to subscribe to a user

* Update notifications queries, hasNewNotes queries for FollowActivity note type

* Only show items that have been created since subscribing to the user

* Send push notifications to user subscribers for posts and comments

* Rename item dropdown to action dropdown and re-use for item info and user actions

* Don't allow self-follows

* Add index on followee for faster lookups

* Don't show subscribe action if not logged in

* small style enhance

---------

Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
2023-08-28 20:27:56 -05:00
keyan 7542dd6cc4 upgrade to prisma 4 2023-07-26 19:18:42 -05:00
keyan 59f7b6ff26 Revert "Revert "shield your eyes; massive, squashed refactor; nextjs/react/react-dom/apollo upgrades""
This reverts commit 18910fa2ed.
2023-07-23 10:08:43 -05:00
keyan 18910fa2ed Revert "shield your eyes; massive, squashed refactor; nextjs/react/react-dom/apollo upgrades"
This reverts commit d0314ab73c.
2023-07-23 09:16:12 -05:00
keyan d0314ab73c shield your eyes; massive, squashed refactor; nextjs/react/react-dom/apollo upgrades 2023-07-21 17:33:11 -05:00
keyan 4e9138dfdc show more info on where zap rewards came from 2023-07-09 12:21:11 -05:00
ekzyis 388e00dd04
Service worker rework, Web Target Share API & Web Push API (#324)
* 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>
2023-07-04 14:36:07 -05:00
keyan 072e60c954 streaks 2023-02-01 17:40:49 -06:00
keyan 41226245c5 referrals 2022-12-19 16:27:52 -06:00
keyan 08893d020c improved earning: more detail, longer top tail 2022-09-14 17:01:30 -05:00
keyan 9581160944 better reward notifications 2022-07-05 15:18:59 -05:00
keyan cef122141f only one earn notification at a time 2022-04-24 11:16:51 -05:00
keyan 74b191837e refine reply-only notifications 2022-04-21 12:48:27 -05:00
keyan e1ffef8308 allow just showing replies in notifications 2022-04-20 16:35:30 -05:00
keyan 987a5ed3a3 notify user when invoice is paid 2022-03-23 13:54:39 -05:00
keyan 5ff856d061 earning 2022-03-17 15:13:19 -05:00
keyan 022c72b95b remove extra migrations, refine jobs 2022-02-28 14:09:21 -06:00
keyan 6b19b10bb2 invite notifications 2022-01-19 15:02:38 -06:00
keyan 09b358397a highlight new notifications 2021-08-19 19:13:32 -05:00
keyan 4b64912333 mention notifications are functional 2021-08-18 18:00:54 -05:00
keyan 96a18e6c9d query is working 2021-08-17 13:15:24 -05:00