* 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
* Replace useInvoiceable with usePayment hook
* Show WebLnError in QR code fallback
* Fix missing removal of old zap undo code
* Fix payment timeout message
* Fix unused arg in super()
* Also bail if invoice expired
* Fix revert on reply error
* Use JIT_INVOICE_TIMEOUT_MS constant
* Remove unnecessary PaymentContext
* Fix me as a dependency in FeeButtonContext
* Fix anon sats added before act success
* Optimistic updates for zaps
* Fix modal not closed after custom zap
* Optimistic update for custom zaps
* Optimistic update for bounty payments
* Consistent error handling for zaps and bounty payments
* Optimistic update for poll votes
* Use var balance in payment.request
* Rename invoiceable to prepaid
* Log cancelled invoices
* Client notifications
We now show notifications that are stored on the client to inform the user about following errors in the prepaid payment flow:
- if a payment fails
- if an invoice expires before it is paid
- if a payment was interrupted (for example via page refresh)
- if the action fails after payment
* Remove unnecessary passing of act
* Use AbortController for zap undos
* Fix anon zap update not updating bolt color
* Fix zap counted towards anon sats even if logged in
* Fix duplicate onComplete call
* Fix downzap type error
* Fix "missing field 'path' while writing result" error
* Pass full item in downzap props
The previous commit fixed cache updates for downzaps but then the cache update for custom zaps failed because 'path' wasn't included in the server response.
This commit is the proper fix.
* Parse lnc rpc error messages
* Add hash to InvoiceExpiredError
* @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>
* 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
* add custom range option to top items page
* add custom range option to profile page
* add date filter option to chart pages
* cleanup
* fix x-axis date labels
* date picker improvements
* enhancements to custom date selection
* remove unneeded condition
---------
Co-authored-by: rleed <rleed1@pm.me>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* first pass of LUD-18 support
* Various LUD-18 updates
* don't cache the well-known response, since it includes randomly generated single use values
* validate k1 from well-known response to pay URL
* only keep k1's for 10 minutes if they go unused
* fix validation logic to make auth object optional
* Various LUD18 updates
* move k1 cache to database
* store payer data in invoice db table
* show payer data in invoices on satistics page
* show comments and payer data on invoice page
* Show lud18 data in invoice notification
* PayerData component for easier display of info in invoice, notification, wallet history
* `payerData` -> `invoicePayerData` in fact schema
* Merge prisma migrations
* lint fixes
* worker job to clear out unused lnurlp requests after 30 minutes
* More linting
* Move migration to older
* WIP review
* enhance lud-18
* refine notification ui
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* Prototype implementing LUD-12 comments on payRequest in LNURLP Lightning Address flow
* Support sending comment when withdrawing to ln addr (LUD-12)
* Prevent `initialError` from being toasted informs multiple times
* delete the old create_invoice function
* improve lightning addr withdrawal styling
* allow lnaddr comment to show up in notifications
* enhance satistics
---------
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* 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>
* 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>
* multiple forwards on a post
first phase of the multi-forward support
* update the graphql mutation for discussion posts to accept and validate multiple forwards
* update the discussion form to allow multiple forwards in the UI
* start working on db schema changes
* uncomment db schema, add migration to create the new model, and update create_item, update_item
stored procedures
* Propagate updates from discussion to poll, link, and bounty forms
Update the create, update poll sql functions for multi forward support
* Update gql, typedefs, and resolver to return forwarded users in items responses
* UI changes to show multiple forward recipients, and conditional upvote logic changes
* Update notification text to reflect multiple forwards upon vote action
* Disallow duplicate stacker entries
* reduce duplication in populating adv-post-form initial values
* Update item_act sql function to implement multi-way forwarding
* Update referral functions to scale referral bonuses for forwarded users
* Update notification text to reflect non-100% forwarded sats cases
* Update wallet history sql queries to accommodate multi-forward use cases
* Block zaps for posts you are forwarded zaps at the API layer, in addition
to in the UI
* Delete fwdUserId column from Item table as part of migration
* Fix how we calculate stacked sats after partial forwards in wallet history
* Exclude entries from wallet history that are 0 stacked sats from posts with 100% forwarded to other users
* Fix wallet history query for forwarded stacked sats to be scaled by the fwd pct
* Reduce duplication in adv post form, and do some style tweaks for better layout
* Use MAX_FORWARDS constants
* Address various PR feedback
* first enhancement pass
* enhancement pass too
---------
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
ekzyis
SatsAllDay
keyan
Keyan
rleed
ekzyis