You need to host exactly the following JSON file at https://lynalden.com/.well-known/nostr.json
Then you can update your profile with the NIP-05 address "_@lynalden.com". The underscore is a reserved name to indicate that you are the domain owner, so it will simply show as "lynalden.com" in clients (as opposed to something redundant like "lyn@lynalden.com").
Looks like a new maintainer with the necessary C++ experience needs to fork it. Probably a case for nostr:npub10pensatlcfwktnvjjw2dtem38n6rvw8g6fv73h84cuacxn4c28eqyfn34f to support?
Also, a bus factor of 1 is not great for the software that powers most nostr relays. A fork should probably go to a community namespace/repo to begin with.
For the UK, there is also https://bitcoineventsuk.substack.com
But those cops can keep their tax-financed job and even earn more overtime pay. The system works!
Of course there are. Every single paid or members-only relay has one for you.
Owning your keys doesn't mean you can't also use hosted services who may have to authenticate you, or store other info about you, like if you paid and for how long. Keeping track of the payments is literally where the word account comes from:
That's what I personally do, yes. But "just use someone else's service" is not what I'm building nostr integrations for.
Hahaha, wow, that's next-level browsering! 😅
"The mint private key is stored in your local browser storage. You should not delete your browser history or else any eCash created from your mint will lose the ability to be validated, transferred or redeemed."
Be that as it may, it's not necessary to even have a special inbox relay in order to receive zap receipts, and it's obvious from our LNURL server's logs that a lot of people don't request receipts to be published to inbox relays. In fact, it's almost everyone I saw so far.
Also, since inbox relays can easily be spammed or DDoS'ed, I won't set one up until I have proper mitigations for that. Maybe you could point me to learning resources about this?
I don't want just anyone to write anything to our relay. But it's easy to fix for relay operators if they do what I was asking about.
I did it for our relay, and also added an improvement to our LNURL server that makes seeing received zaps even more bulletproof, even if other people's relays don't fix it:
talking about being permission-less. live from italy. starts soon. https://www.youtube.com/watch?v=FyDHScDbyuA
No permission to watch the video from a nostr client tho:
> The Netherlands will have to get rid of the idea that power is available at any time and for everyone
Who could possibly have predicted that switching mostly to intermittent sources of energy could result in intermittent electricity shortages?
Nice! Which implementation are you using for the mint?
Everyone should ask providers of paid relays they use to allow anyone to publish receipts when the zap request came from a pubkey with write permissions. I just did this for our own relay the other day:
When you zap someone, their LNURL server has to be able to publish a receipt to the relays you request. If they're not allowed to publish it there, then nobody will see the zap.
I just improved this for our own Lightning accounts and relay over here, by checking if the zap request came from a relay member, and then allowing receipts to be published by non-members:
Nostr, or rather the optional NIP-05, does not use Webfinger. It uses its own "/.well-known" URL and response format. But a Webfinger response can also contain an arbitrary amount of different links for different services.
Stop running after dumpster fires, so you can invest more time and energy in productive pursuits that actually improve both your own life and that of others?
I just deployed a few things that I was working on over the last week, and some of them should make the zapping experience with the Kosmos relay and Lightning accounts/addresses a bit faster and more consistent:
1. When we zap someone to a non-Kosmos Lightning address, their server is now able to post the receipt back to our members-only relay.
2. When someone who's not using our relay zaps us, our accounts server publishes the receipt to the non-member's requested relays, but it will also publish it to our own relay in addition to theirs.
This means that we now reliably (and quickly) see all incoming and outgoing zaps in all of our clients, especially when other people's relay lists don't overlap with ours.
I think everyone running members-only or paid relays should implement a similar policy for allowing zap receipts to be published for their own users' outgoing zaps. Here's the relevant code in our own policy:
If someone spots a mistake, or this is generally a bad idea for some reason, please let me know! 🙏
#nostr
We need Jungle, I'm afraid.
This policy works: https://gitea.kosmos.org/kosmos/akkounts/src/commit/0daac33915f827494feb4a5d6bb9ba5d49e6b904/extras/strfry/ldap-policy.ts#L18-L40
I think everyone running a members-only relay should do this. Unless I missed something, in which case I'd love to learn why it's a bad idea!