Add support for Lightning Zaps #190
Labels
Clear labels
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
security
ui/ux
wontfix
integration
btcpay
integration
discourse
integration
ejabberd
integration
email
integration
ldap
integration
lndhub
integration
mastodon
integration
nostr
integration
remotestorage
Something is not working
Graphic/visual design
Config, builds, CI, deployment, etc.
Documentation
This issue or pull request already exists
Improving existing functionality
New functionality
Dive in, and start contributing
Something to consider
Not a bug
Small contribution
Medium contribution
Large contribution
Currently not actionable
Manual IT ops activities
Looking for an answer
release
major
release
minor
release
patch
All your base are belong to us
User interface, process design, etc.
This won't be fixed
Milestone
No items
No Milestone
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/akkounts#190
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implements NIP-57, so that Lightning accounts can receive sats from people via zaps on Nostr.
refs #170
@bumi I deployed this branch to production and then fixed a bunch of bugs and problems that made it fail. I think it's finally working now.
Unfortunately, I haven't found a single nostr client that works reliably for me, and actually retrieves all messages from a user's relays. So testing it live is still a bit of a hit-and-miss result, but we do see the logs for publishing status per relay now.
are the CORS changes already deployed?
Yes, the CORS changes are deployed. The latest version of this branch should be the one in production.
I just tried to zap a note, and noticed that Alby is broken for my Kosmos accounts, even though the akkounts Lightning dashboard still works (same API), and there's nothing visibly wrong with any part of the setup on our end. See my question here: https://kosmos.social/@raucao/112529763147036364
Maybe whatever the reason was for your question is also connected to that issue?
I solved the extension issue by restarting the whole browser: https://kosmos.social/@raucao/112529804852769117
So now there's no issue I can see anywhere in regards to our Lightning or LNURL. Also just zapped my account from 2 different clients to make sure it works.
ok, cool. on kosmos.social I still get some CORS issue.
but it looks good to me. got also some nice email notifications.
Ah, now I see! Maybe the kosmos.social Webfinger entry doesn't have CORS headers, but the LNURL endpoints would be on accounts.kosmos.org anyway. I'll have a look at that. We could also make it possible to use the .social address as a NIP-05 address, which currently probably only works for kosmos.org, too.
Yeah, I have a PR coming up with more settings for Lightning notifications. It adds 3 more settings for it, so you can turn them off for zaps specifically (if you get notifications in nostr clients anyway), and also ignore txs under a certain amount threshold as well as ones without a message/comment.
@bumi The lnurl endpoints for .social should also carry
Access-Control-Allow-Origin: *now.