* Also log autowithdrawal routing errors
* Only log autowithdrawal success in worker
* Use WalletType for WalletLog.wallet
* Fix autowithdrawal success message
* Infer walletName from walletType in upsertWallet
* Merge serializeInvoiceable with serialize
* Rename to verifyPayment
We already have a function named checkInvoice in the worker which can be confusing.
Also, we don't need to export this function.
* Use crypto.timingSafeEqual
* Fix missing unwrap for item creation and update
* Merge serializeInvoiceable with serialize
* Rename to verifyPayment
We already have a function named checkInvoice in the worker which can be confusing.
Also, we don't need to export this function.
* Use crypto.timingSafeEqual
* nwc wallet logs
* persist logs in IndexedDB
* Potential fix for empty error message
* load logs limited to 5m ago from IDB
* load logs from past via query param
* Add 5m, 1h, 6h links for earlier logs
* Show end of log
* Clamp to logStart
* Add log.module.css
* Remove TODO about persistence
* Use table for logs
* <table> fixes bad format with fixed width and message overflow into start of next row
* also using ---start of log--- instead of ---end of log--- now
* removed time string in header nav
* Rename .header to .logNav
* Simply load all logs and remove navigation
I realized the code for navigation was most likely premature optimization which even resulted in worse UX:
Using the buttons to load logs from 5m, 1h, 6h ago sometimes meant that nothing happened at all since there were no logs from 5m, 1h, 6h ago.
That's why I added a time string as "start of logs" so it's at least visible that it changed but that looked bad so I removed it.
But all of this was not necessary: I can simply load all logs at once and then the user can scroll around however they like.
I was worried that it would be bad for performance to load all logs at once since we might store a lot of logs but as mentioned, that's probably premature optimization.
WHEN a lot of logs are stored AND this becomes a problem (What problem even? Slow page load?), THEN we can think about this.
If page load ever becomes slow because of loading logs, we could probably simply not load the logs at page load but only when /wallet/logs is visited.
But for now, this works fine.
* Add follow checkbox
* Create WalletLogs component
* Embed wallet logs
* Remove test error
* Fix level padding
* Add LNbits logs
* Add logs for attaching LND and lnAddr
* Use err.message || err.toString?.() consistently
* Autowithdrawal logs
* Use details from LND error
* Don't log test invoice individually
* Also refetch logs on error
* Remove obsolete and annoying toasts
* Replace scrollIntoView with scroll
* Use constant embedded max-height
* Fix missing width: 100% for embedded logs
* Show full payment hash and preimage in logs
* Also parse details from LND errors on autowithdrawal failures
* Remove TODO
* Fix accidental removal of wss:// check
* Fix alignment of start marker and show empty if empty
* Fix sendPayment loop
* Split context in two
* first pass of disallowing certain APIs with API keys
Disallow the following APIs:
* item.act (zap)
* create withdrawal
* unlink auth method
* link unverified email
* disallow creating lnauths via API key to stop the flow of linking via lnauth
* undo the limitation on donating to rewards
* revert the assertion on createAuth
* assert no api key on createWithdrawal and sendToLNAddr
* incorporate PR feedback by adding API Key negative assertion to more mutations:
* `createInvite`
* `createAuth`
* `upsertWalletLND` by way of `upsertWallet`
* `upsertWalletLNAddr` by way of `upsertWallet`
* auto canceling bolt11s from lnd when auto dropped from DB
* auto canceling bolt11s from lnd when auto dropped from DB
* removed semicolon for lint
* changed cancleHodlInvoic to deletePayment function
* updated code to account for failed LND deletes
* linter fixes
* updated to only remove hashes and bolt11's from model when successfully deleted from LND
* updated to revert unsuccessful deletes from LND and add those values back into the db
* linter fix and renaming for clarity
* updated WITH query
* added if statement to account for invoices not returning from db
* fixed linter
* reverted docker-compose.yml
* made it dry
* made it dry
* added a comment because the query might be confusing
* made query moar dry
* Query formatting
* Fix query returns number of rows instead of rows
* updated to
* fixed linter
* removed lnbits dir
* removed gitignore and docker-compose.yml from pr
* added deleting from LND in wallet resolver
* linter + added missing import
* fixed merge conflict
* refine invoice deletion
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* Use parallel invoice subscriptions
* Fix missing idempotency
* Log error
* Use cursor for invoice subscription
* Subscribe to outgoing payments for withdrawals
* Add TODO comments regarding migration to LND subscriptions
* Also use isPoll variable in checkInvoice
* Queue status check of pending withdrawals
* Use for loop to check pending withdrawals
* Reconnect to LND gRPC API on error
* Fix hash modified of applied migrations
* Separate wallet code from worker index
* refactor subscription code some more
* remove unnecessary subWrapper abstraction
* move all wallet related code into worker/wallet.js such that only a single import is needed in worker/index.js
* Migrate from polling to LND subscriptions
* Remove unnecessary reconnect code
* Add FIXME
* Add listener for HODL invoice updates
* Remove obsolete comment
* Update README
* Add job to cancel hodl invoice if expired
* Fix missing else
* small bug fixes and readability enhancements
* refine and add periodic redundant deposit/withdrawal checks
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* display bolt11 info and preimage for invoices
* Remove preimage attempt for wdrwl, since it doesn't make sense
Other various code cleanup
* Only include preimage for confirmed paid and settled invoices
* Debounce the `onAddrChange` event handler when sending to a LN Address,
so we more accurately display the input form for LUD-12 and LUD-18 options
* Remove explicit URI encoding of Payer Data when sending to a LN Addr, since we're getting encoding for free via URLSearchParams
* Append `@stacker.news` to identifier values sent in payer data
* Don't do extra decoding when receiving LUD-18 data
* LUD-18 Wallet implementation
Query the lightning address provider client-side to learn of capabilities
Conditionally render LUD-12 and LUD-18 fields based on what the remote
server says is supported
Allow identifier, name, and email to be sent from the SN side during the withdrawal flow. Auth seems too complicated for our use case, and idk about pubkey?
* Clear inputs if the new ln addr provier doesn't support those fields
* various ux improvements
* dynamic client-side validation for required payer data
* don't re-init form state on error
* correct min and max amount values
* only send applicable data to graphql api based on payerdata schema
* input type for numeric values (amount, max fee)
* update step for amount and max fee
* Fix identifier optional and field blur
* reuse more code
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.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>
* Use HODL invoices
* Fix expiry check comparing string with Date
* Fix unconfirmed user balance for HODL invoices
This is done by syncing the data from LND to the Invoice table.
If the columns is_held and msatsReceived are set, the frontend is told that we're ready to execute the action.
We then update the user balance in the same tx as the action.
We need to still keep checking the invoice for expiration though.
* Fix worker acting upon deleted invoices
* Prevent usage of invoice after expiration
* Use onComplete from <Countdown> to show expired status
* Remove unused lnd argument
* Fix item destructuring from query
* Fix balance added to every stacker
* Fix hmac required
* Fix invoices not used when logged in
* refactor: move invoiceable code into form
* renamed invoiceHash, invoiceHmac to hash, hmac since it's less verbose all over the place
* form now supports `invoiceable` in its props
* form then wraps `onSubmit` with `useInvoiceable` and passes optional invoice options
* Show expired if expired and canceled
* Also use useCallback for zapping
* Always expire modal invoices after 3m
* little styling thing
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.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>
* Add anon zaps
* Add anon comments and posts (link, discussion, poll)
* Use payment hash instead of invoice id as proof of payment
Our invoice IDs can be enumerated.
So there is a - even though very rare - chance that an attacker could find a paid invoice which is not used yet and use it for himself.
Random payment hashes prevent this.
Also, since we delete invoices after use, using database IDs as proof of payments are not suitable.
If a user tells us an invoice ID after we deleted it, we can no longer tell if the invoice was paid or not since the LN node only knows about payment hashes but nothing about the database IDs.
* Allow pay per invoice for stackers
The modal which pops up if the stacker does not have enough sats now has two options: "fund wallet" and "pay invoice"
* Fix onSuccess called twice
For some reason, when calling `showModal`, `useMemo` in modal.js and the code for the modal component (here: <Invoice>) is called twice.
This leads to the `onSuccess` callback being called twice and one failing since the first one deletes the invoice.
* Keep invoice modal open if focus is lost
* Skip anon user during trust calculation
* Add error handling
* Skip 'invoice not found' errors
* Remove duplicate insufficient funds handling
* Fix insufficient funds error detection
* Fix invoice amount for comments
* Allow pay per invoice for bounty and job posts
* Also strike on payment after short press
* Fix unexpected token 'export'
* Fix eslint
* Remove unused id param
* Fix comment copy-paste error
* Rename to useInvoiceable
* Fix unexpected token 'export'
* Fix onConfirmation called at every render
* Add invoice HMAC
This prevents entities which know the invoice hash (like all LN nodes on the payment path) from using the invoice hash on SN.
Only the user which created the invoice knows the HMAC and thus can use the invoice hash.
* make anon posting less hidden, add anon info button explainer
* Fix anon users can't zap other anon users
* Always show repeat and contacts on action error
* Keep track of modal stack
* give anon an icon
* add generic date pivot helper
* make anon user's invoices expire in 5 minutes
* fix forgotten find and replace
* use datePivot more places
* add sat amounts to invoices
* reduce anon invoice expiration to 3 minutes
* don't abbreviate
* Fix [object Object] as error message
Any errors thrown here are already objects of shape { message: string }
* Fix empty invoice creation attempts
I stumbled across this while checking if anons can edit their items.
I monkey patched the code to make it possible (so they can see the 'edit' button) and tried to edit an item but I got this error:
Variable "$amount" of required type "Int!" was not provided.
I fixed this even though this function should never be called without an amount anyway. It will return a sane error in that case now.
* anon func mods, e.g. inv limits
* anon tips should be denormalized
* remove redundant meTotalSats
* correct overlay zap text for anon
* exclude anon from trust graph before algo runs
* remove balance limit on anon
* give anon a bio and remove cowboy hat/top stackers;
* make anon hat appear on profile
* concat hash and hmac and call it a token
* Fix localStorage cleared because error were swallowed
* fix qr layout shift
* restyle fund error modal
* Catch invoice errors in fund error modal
* invoice check backoff
* anon info typo
* make invoice expiration times have saner defaults
* add comma to anon info
* use builtin copy input label
---------
Co-authored-by: ekzyis <ek@stacker.news>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
Keyan
ekzyis
keyan
SatsAllDay
Dillon
benthecarman
ekzyis
rleed
Satoshi Nakamoto
benthecarman