Dikaios1517

Alright... Here's what I changed:
OWNER_NPUB - This should obviously be changed to the npub you will be using Haven with.
RELAY_URL - This should be the domain where the relay will be accessible.
Leave the rest of the settings in this top section of the .env as they are unless you have a specific reason to change them and pop down to the Private Relay Settings.
PRIVATE_RELAY_NAME - You can name it whatever you like, but probably don't want to leave it as "utxo's private relay." Each of the other sections allow you to change their name, too.
PRIVATE_RELAY_NPUB - This should be the npub you plan to use the relay with. The private relay will only accept notes authored by that npub. Same applies for all the other sections below that allow you to set the relay npub.
PRIVATE_RELAY_DESCRIPTION - You can leave this as is or change it as you see fit. It just gives those who check the relay description document an idea of what the relay is for.
PRIVATE_RELAY_ICON - Slap in a URL for an icon for your relay. Think of it like your relay's profile picture. Keep it small. You can even have a separate icon for each of Haven's relays, if you want.
I haven't changed anything in the Private Relay Rate Limiters section.
Your "Chat" relay is used for receiving DMs. Apart from the fields similar to the Private relay setup, you may want to adjust the WoT depth, how often the WoT is refreshed, or the minimum number of followers. These settings dictate who can post messages to your DM inbox, so you don't get a bunch of spam DMs. But, if you want to see DMs from people outside of your WoT, you may want to make these less strict by reducing the CHAT_RELAY_MINIMUM_FOLLOWERS to 0, but know that you will start getting spam DMs, too.
Make similar updates as you did in the Private Relay section to the Outbox and Inbox sections, too.
Your Import Settings may also need to have the date updated, depending on when you joined Nostr. Haven will import your notes from other relays from that date to present, based on the relays you instruct it to pull from in the relays_import.json document.
Finally, you may need to add some values in the AWS Backup Settings, if you are having Haven backed up to AWS.
The next document you will want to make sure has all the relays listed that you want to pull from is the relays_import.json. Make sure it is pulling from any and all relays you can remember writing to in the past. It's already including relay.nostr.band, which is an aggregator, so it should be able to find most of your notes, regardless.
And to round it all out, you'll want to edit the relays_blastr.json to include any relays you want your public notes mirrored to. This will only be notes that you are writing to your Haven outbox relay. The default relays are pretty decent, but you may want to make some adjustments. Note, you should not choose any relays that require AUTH for write access, as Haven will be unable to sign their AUTH requests.
Maybe @npub1utx…50e8 and/or @npub1a6w…0tyc can review the above to ensure I haven't given any bad advice. 😂

2025-06-13 20:31:54 GMT

- reply

In this transitional world we live in where some clients support the outbox model and some don't, I have come to the following setup:
Kind 10002
- Write to your own Haven outbox relay, and set it up to blast to the 10 most popular public relays.
- Write to and read from a paid relay of your choice. I'll let @npub18kz…x5sz, @npub1226…grkj, and @npub1h49…9kay duke it out for which one you should choose.
- Read from your own WoT relay (set up to aggregate notes from your WoT) and your Haven inbox relay.
Kind 3 - For those clients that support using it to supplement your inbox/outbox setup.
- Read from a couple other WoT relays and aggregators that might fill in some gaps missing in your inbox relays.
- Write to... nothing additional should be needed. Your outbox relays should suffice.
If you don't have your own Haven relay, then some adjustments need to be made. But Haven really is helpful to have. THANK YOU @npub1utx…50e8 and @npub1a6w…0tyc!

2025-06-07 05:58:46 GMT

- reply

What Bitcoiner could resist time traveling back to the day Satoshi was born?

2025-06-07 05:42:22 GMT

- reply

Muting words is supported by some clients, but not all. It's also a temporary band-aid. It works on this particular spam attack, but is not likely to work on the next one.
We'll have to determine what word will work for the next one when it happens.
Or we could just use better relays...

2025-06-07 05:35:15 GMT

- reply

Poor sod was so sure that Bitcoin was going to go up that he borrowed enough fiat to buy 99.2 Bitcoin. However, lenders aren't about to risk losing their principal, so when the price went down far enough, he was forced to sell everything just to pay the lenders back, losing all of his own money that he'd put into the deal, as well.

2025-06-07 04:13:51 GMT

- reply

Self-custody Lightning, yes. But custodial Lightning is no different from any other kind of custodial Bitcoin.

2025-06-06 23:37:53 GMT

- reply

@nprofile…278z I broke it. Sorry.

2025-06-06 22:16:26 GMT

- reply

Genesis

2025-06-06 21:41:05 GMT

“In all churches a distinction is made between the terms upon which private members are admitted to membership, and the terms upon which office-bearers are admitted to their sacred trusts of teaching and ruling. A Church has no right to make anything a condition of membership which Christ has not made a condition of salvation. The Church is Christ’s fold. The sacraments are seals of his covenant. All have a right to claim admittance who make a credible profession of the true religion--that is, who are presumptively the people of Christ. This credible profession of course involves a competent knowledge of the fundamental doctrine of Christianity--a declaration of personal faith in Christ and consecration to his service, and a temper of mind and habit consistent therewith. On the other hand, no man can be inducted into any office in any Church who does not profess to believe in the truth and wisdom of the constitution and laws which it will be his duty to conserve and administer. Otherwise all harmony of sentiment and all efficient co-operation in action would be impossible.” - A.A. Hodge
This coming week will mark 4 years that I have served as an elder for my home church and I can tell you that a large portion of the job is understanding how to make this distinction. Another large portion is understanding that you will always be criticized by those who don't know how to do so.
#Reformed #catholic #Presbyterian

2025-06-06 21:09:25 GMT

- reply

Ah... Yes. I think Damus is treating all of them as both read and write. There is no way to change which is read vs write within their interface at this time.
You can specify which is read vs write in Nostur. Just make sure to also use the "announce" option, so other clients will see which relays you want to use for each. Not sure whether Damus will respect the read/write flags or just treat them all as both anyway, though.

2025-06-06 21:05:04 GMT

- reply

So, the aggregator relay requires payment to read from it? Using AUTH, I expect?

2025-06-06 21:04:15 GMT

- reply

Yup, that's exactly what happened. lol

2025-06-06 20:48:45 GMT

- reply

Are you just trying to find something to help them understand how it works under the hood, or are you looking for something to help them learn how to run a Lightning node for themselves? Educational or tutorial?
This video is a pretty good one for explaining how Lightning works from an educational perspective: https://www.youtube.com/watch?v=yKdK-7AtAMQ

2025-06-06 20:15:09 GMT

- reply

Damus is a relay that allows anyone to post for free. It WILL have spam.
You can always write to it if you want, but I would not read from it.

2025-06-06 20:01:49 GMT

- reply

If you use a client that allows you to mute certain words, you can mute spam replies from THIS particular spam attack by adding "randomuser.me" to your muted words. However, that will not be effective at stopping future spam.
Here's my canned response for dealing with spam on a more long-term basis:
If you are seeing a lot of spam in your replies, it is because you are reading from relays that spammers can write to for free. Spam can only happen if two things are true: 1. It's free and easy to create new identities. 2. New identities can write notes to relays without a cost.
We're not able to, nor do we want to, make it difficult to create a new identity on Nostr, so reducing spam by making new users jump through hoops that can only be enforced by a centralized entity is not an option.
That means we need to prevent it via option 2, by restricting new identities from writing notes to relays without a cost. If you are reading from relays that don't impose some cost to write to them, either social, computational, or monetary, then you are bound to see spam on a regular basis.
Instead of reading from free and public relays, you should consider trading them out for the following types of relays:
- Web-of-Trust (WoT): This relay type imposes a social cost in order to write to it. Namely, you have to be followed by the relay owner or one of the npubs the relay owner follows before you can write notes to the relay. These types of relays may also automatically aggregate notes from those within the web-of-trust, even if they were written to other relays.
- Proof-of-Work (PoW): This relay type is less common, and it imposes a computational cost to write to it. Only those who have dedicated computational energy to generating the required PoW can write to the relay. This cost is trivial for the honest user, who only posts up to a couple times a minute, but imposes heavy costs on spammers, who are trying to post hundreds or thousands of times per minute. Unfortunately, most Nostr clients don't support adding PoW to notes, so most relays don't use it as a spam mitigation measure.
- Paid Relays: As the name implies, this relay type imposes a monetary cost to write to it. It may also impose a cost to read from it, but that is less common. Since this cost is per npub, and spammers don't ever use just one npub since that's too trivial to mute and move on, this makes paid relays affordable for honest users, but too expensive for spammers.
Since the only two relay types above that are currently in wide use are web-of-trust and paid relays, here are a few suggestions for each.
Web-of-Trust:
- wot.utxo.one
- nostrelites.org
- wot.nostr.net
Paid:
- nostr.wine
- nostr.land
- jellyfish.land

2025-06-06 19:56:52 GMT

- reply

Web browser extensions in the context of Nostr are used for signing notes, not for loading feeds or not loading feeds in Nostr clients.
What you may be experiencing is that some Nostr clients try to load and decrypt your DMs immediately upon login, and these get sent to your signer extension as separate requests. If the extension doesn't handle those requests gracefully, it tries to load all of the requests at the same time, crashing your computer.
Nostrudel does not do this. Instead, it waits to decrypt messages until you instruct it to do so manually. Likewise, Coracle has direct messages disabled by default, so it should not send you a bunch of decryption requests unless and until you enable direct messages.
Now, if you want a client that allows you to post to Nostr without the distraction of a feed, you should check out https://shipyard.pub/

2025-06-06 19:25:59 GMT

- reply

No. Just me trying, (and failing) to be cheeky.
The timestamp was supposed to be for July 4th of 1776, and YakiHonne ignored the "-" in front of the timestamp, interpreting it as a future date of September 17th, 2048.

2025-06-06 19:23:47 GMT

- reply

Successfully unsuccessful. The timestamp was supposed to be for July 4th, 1776, not for September of 2048. 😂

2025-06-06 19:12:57 GMT

- reply

Quite hilarious... YakiHonne must be ignoring the "-" in front of the timestamp and treating it as a future date, or "now" until that date (September 17, 2048) arrives.
It's meant to be July 4th, 1776, but timestamps apparently don't work when they are negative numbers...
On a side-note, I have just found a way to post notes that are guaranteed to be at the top of the timeline... At least until YakiHonne fixes it.
Suggestion for YakiHonne devs: Ignore notes with timestamps in the future by more than a certain margin. Say 30 minutes tops.

2025-06-06 19:07:31 GMT

- reply

WAT! LOL!
I thought that note didn't even get published to the relays, because every client I have tried won't even show it at all.
I hadn't tried YakiHonne...
So, the note has a timestamp that is a negative number. relay.damus.io gave me an error when I tried to publish it there with NAK.
I am on Coracle right now, and though I can see notifications for a few responses to the note, I cannot load the note at all. 😂
I'll leave it for a bit then pop over to YakiHonne and request deletion.

2025-06-06 18:10:19 GMT

- reply

For sure, it would be possible. They would just need to be encrypted. Not sure what client would be ideal for it at this time, though.
The vast majority of note kinds are designed to be public, and therefore are not encrypted. The main exception are DMs, so that might be the route to go. DMs can't be edited, though, so each revision would be a separate DM, and it would get out of hand pretty quickly.

2025-06-06 06:09:16 GMT

- reply

Unfortunately, you can't do anything prior to January 1, 1970, because timestamps would be negative numbers and relays reject the note if the timestamp isn't an integer. 😂
Anything after that is fair game, though.

2025-06-06 05:48:15 GMT

- reply

I have been using Joplin, encrypted and synced to my Nextcloud. This could work for collaboration, as well, but as with anything encrypted, you would need to give the collaborators the decryption key, so you will likely want to have a separate profile for notes you need to collaborate on, and share the decryption key only for that profile.
If you don't need encryption, I believe Joplin allows you to go that route, too.
As for a Nostr-based note app that allows for collaborative editing, well... we don't really have a Nostr-based note app yet. Best option is using a long-form client and only publishing to a private relay you control. However, most long-form clients just publish to your outbox relays by default, and don't offer a way to override that. The best option I can think of for this would be Comet.md. This is a local-first note app for desktop, so it's not cross-platform. However, it does let you publish your note to a specific relay, and only that relay, even if it is not one of your outbox relays.
Note collaboration is still a problem that needs to be solved. The way Nostr currently handles all notes is that a note can only have one possible author, identified in the "pubkey" field of the note. The signature attached to the note must be valid for that pubkey. There's a couple approaches to collaboration that I can think of possibly working.
First would be the way that has already been implemented for wiki notes. These notes have one author, but anyone else can come along and fork the note, which creates a separate note that only they can sign. However, if the original author likes their changes, they can merge them into their own version of the note. Amethyst also has something like this for "suggesting edits" to regular text notes. But no one ever uses it because Amethyst is the only client that supports these types of edits to regular text notes, so those on any other client will just see the original note.
Another approach would be to have a new standard for assigning collaborators. In this case, the original author would sign the note, and then they would sign a separate, special kind of note that references the original note ID and lists the pubkeys of approved contributors. If any of those npubs submit a new version of the note signed by their private key, the relay will accept it, but keep the copy of the original owner's version, in case they want to revert the change. Clients would display the most recent version of the note signed by the owner or any of the approved contributors, but also display to the owner the option to either commit the changes made by their contributors, or revert their changes. If the owner commits the changes, a new version of the note is created with the owner's signature, and all previous versions can be discarded by the relay. The relay only keeps the revisions of the contributors if they are newer than the most recent version signed by the owner.
Obviously, this second option is more complex and would require new relay logic to implement, so it may be a while before we see anything like it.

2025-06-06 04:39:11 GMT

Did anyone else realize Nostr was a thing way back then?
#nevent1q…2t3w

2025-06-06 02:14:45 GMT

- reply

So, for the sake of placement on relay lists, those using Amethyst would throw this in their General Relays as read only, rather than puttingbit in either their inbox or outbox relays, correct?

2025-06-06 00:32:47 GMT

- reply

Oak Node looks like it uses NWC as well, from the description on Umbrel. That said, my Start9 is my node, and it isn't available there... It also suffers from the same problem @nprofile…rvcc pointed out, that most users probably don't have access to Oak Node via their wallet provider.

2025-06-06 00:29:56 GMT

- reply

That is absolutely true! Got another option for service-provider initiated subscription payments that is more widely adopted by wallets? I can't think of one.
I think NWC is pretty early in adoption, and yet anyone who runs their own node can use it with either Alby Hub or LNBits, there are viable custodial options in Coinos and Minibits, and self-custody in Electrum wallet, if I remember right. Would love to see Zeus' embedded LND support it, as well.
I hadn't heard of Flash, which someone else had mentioned, but from what I can see, that's just invoicing. So the user still needs to manually approve payment being sent each time, while a subscription implies the funds are automatically deducted each month without user interaction required.

2025-06-05 23:57:53 GMT

- reply

Definitely the latter. They get bored and decide to move on. Especially if most users have found a way to deal with their spam so they no longer see it.

2025-06-05 23:56:05 GMT

- reply

Nostr Wallet Connect using a budget for the exact subscription amount. This also allows the user to maintain the ability to cancel at any time by simply deleting the connection string.

2025-06-05 19:31:59 GMT

- reply

I use Strike for stacking as well, but I don't leave my stack on Strike for the same reason I wouldn't leave my stack with any custodian.
Instead, I "stack" by sending USD from Strike to my own Lightning wallet hosted on my own full-node. Then, when I get enough built up, I swap it out to on-chain cold-storage via Boltz.exchange.
If you don't have your own full-node yet, you can use another self-custody Lightning wallet, such as Phoenix or Zeus for where you are building up enough for a UTXO to send to cold storage.
Either way, you end up only ever having a relatively small amount in Lightning at any given time, and NONE in a custodian. Even one as solid as Strike.

2025-06-05 18:41:45 GMT

- reply

100% agree that NIP-46 is the path forward for signing. It was really tough to get it to work properly not so long ago, but lately it has been really consistent. Especially the "scan QR to connect" variety.

2025-06-05 18:24:54 GMT

- reply

One thing to watch for on those extensions is the issue of multiple decryption requests piling on top of each other. May want to stay away from DMs when using a signer extension. 😂

2025-06-05 16:33:21 GMT

- reply

There's nos2x-fox or Alby. Both have "worked" for me, but the experience of browser extensions on mobile is not good...
Have you checked out using Amber to log into @nprofile…trej and use their built-in browser which then acts as an "extension," but uses Amber to do the actual signing?

2025-06-05 04:56:58 GMT

- reply

Well, sir, you currently have 18 relays on your inbox/outbox list, with ALL of them set as inbox relays, and 9 of them set as outbox. That's a bit excessive. At max, you should have maybe 4 outbox and 4 inbox, and there can be overlap for a total of 4-8 relays.
This does not mean those will be the only relays you read from or write to, just the only ones you are announcing to others, "Hey, find my notes here!" and "Hey, send me replies and reactions here!"
You also have a number of paid relays. You don't need that many. Pick two.
So, for your Public Outbox relays, I would go with:
1. Major Public Relay. Something like nos.lol or nostr.mom from your existing list.
2. Paid Relay
3. Any other relay with good response time.
4. (Optional) Major Public Relay
Then comes the Public Inbox. Here's what you want to get it pared down to:
1. Paid Relay (Same as outbox)
2. Paid Relay (Typically don't need to pay just to read from it)
3. Web-of-Trust Relay
4. (Optional) Web-of-Trust Relay
General Relays are where you can add some other relays you want to write to for reaching users who are on clients that don't support the Outbox model yet. This is why Amethyst conveniently offers you suggestions based on what relays those you follow are using. Again, though, if you add any public relays here, make sure you set them to write only by having the upward facing arrow lit up green while the downward facing arrow is grayed out.
If you want to add some specialty relays, such as writing to hist.nostr.land for keeping backups of your follow list, or reading from purplepag.es so Amethyst is likely to find their relay list, you can add them in this section, too. I also have a couple additional WoT relays I read from that are added here as read only.

2025-06-05 02:49:02 GMT

- reply

Right? It's a lot... Thankfully, Amethyst provides some decent direction and sensible defaults, especially for DM inboxes and Search relays.
You don't have to worry about the private relay or local relay lists unless you are running your own private relay or Citrine.
Just focus on Public Outbox, Public Inbox, and General Relays.

2025-06-05 02:34:19 GMT

- reply

It's only going to get harder to detect over time.
Only going to be able to believe what you saw, in-person, with your own eyes.

2025-06-05 02:30:47 GMT

- reply

AI generated for sure, but man that's wild...

2025-06-05 01:31:17 GMT

- reply

Not in the latest version I am running, which looks to be 1.14 (959). It's definitely getting the list from my kind 3.
The kind 3's content field has "read": true, "write": true after each of the relays in the list, so I know that you CAN specify which is read and which is write on the kind 3. It just doesn't look like Damus supports doing so.

2025-06-05 01:00:54 GMT

- reply

Amethyst is the correct answer. It gives you the most control over which relays end up on which relay list.
At the top of Amethyst's relay settings you have Public Outbox and Public Inbox relays. This section controls what relays end up on your kind 10002 relay list, and whether they are flagged as write (outbox) or read (inbox). You should only have a few relays listed for each.
Public Outbox relays are effectively where you announce to the rest of Nostr, "If you want to see my public notes, look on these relays." You can absolutely have a public relay or two here if you want.
Public Inbox relays are where you announce, "If you want me to see your reply, reaction, or zap to my posts, please put it on these relays where I am watching for it." Here is where you want no public relays at all.
The next section for DM Inbox Relays will be saved to your kind 10050 for receiving direct messages. These should be specialized relays that will only allow the recipient of the DM to retrieve it from the relay. Looking at your kind 10050 I think inbox.nostr.com likely fits that bill, but definitely not nos.lol. I don't think theforest.nostr1.com is intended as a DM inbox relay either. You would want something like auth.nostr1.com instead. You're looking for relays that support NIP-42 in particular.
The next section for private relays is saved to a kind 10013 list, and should only include relays only you have access to both for read and write. This list is also stored encrypted in the "content" tag of the note, so I have no idea what you have listed there, because others should not be able to see where you are storing your private notes.
Next up are search relays, stored in your 10007 list. These should only be relays that support NIP-50. Looks like you have mostly relays that don't, with the exception of search.nos.today and nostr.wine. Another good one to throw in here is relay.nostr.band, since it is an aggregator that tries to have all text notes. Even though it is full of spam, that doesn't matter for your search relays, because they aren't used for general reading of notes or providing you with notifications. Only for searching.
Local relay is local. Citrine would be what you put here, assuming you are running it.
Finally we get to General Relays. These will be saved to your kind 3 follow list, believe it or not. Amethyst has a bunch of toggles for each of them, but only whether you have them set as read or write will show up on your kind 3. The rest is internal to Amethyst alone. Here you can set relays you want to write to, but don't want "announced" that others should look there to find your notes. For instance, I would put hist.nostr.land here as write only, if you aren't paying for nostr.land. I would put purplepag.es here as read only. Get rid of any public relays that you are reading from here and add some WoT relays instead; read only, or read and write as you like.
Hope that helps you sort through what should go where.

2025-06-04 23:58:38 GMT

- reply

Sorry, 195 npubs and 1 muted hashtag.
Don't blame you on that particular hashtag, either.

2025-06-04 23:53:40 GMT

- reply

So, it looks like there are 196 npubs on your mute list that are not encrypted at all, visible to anyone who cares to look. Then there is a chunk of encrypted information in the "content" tag that likely includes other npubs none of us can see, but you alone would be able to see if you go to your mute list in your settings on Amethyst or Coracle. Damus will not show these encrypted entries on your mute list. Most clients don't.

2025-06-04 23:04:47 GMT

- reply

NICE! Thanks for the head's up!

2025-06-04 23:04:16 GMT

- reply

So paying for nostr.land eliminates the need to have hist.nostr.land in my write relays?

2025-06-04 23:00:40 GMT

- reply

hist.nostr.land as an inbox relay?
There's definitely some interesting choices in your 10002 as well. 😂
What client do you use primarily?

2025-06-04 22:44:22 GMT

- reply

Really? From the looks of it, the content section of @nprofile…rvcc's mute list is encrypted.

2025-06-04 22:29:08 GMT

- reply

I just popped over to Damus, though. It looks like it isn't using this list at all.
@nprofile…5cp7 what relay list is Damus using? It looks like it has only populated the relays from my "General Relays" list in Amethyst, and isn't using kind 10002 at all. What's more, I have no way to set which ones are read and which ones are write. Does Damus treat them all as both read and write?

2025-06-04 22:07:49 GMT

- reply

That's a start. We need to talk about this though:
https://relay.brightbolt.net/0112c4abdb404e83770eff6b44e3f873f3dff9ab97091c8154d3a2e4812129b8.jpg
That's your list of inbox and outbox relays. It could use a clean up.

2025-06-04 21:59:43 GMT

- reply

What client are you running?

2025-06-04 21:50:50 GMT

- reply

Yeah, that's expected. Mute lists are saved to the author's outbox relays like any other note and most clients don't encrypt their contents, so anyone can readily see who is on them.

2025-06-04 21:46:15 GMT

- reply

lol, what?
So, there is a client notifying people when they have been added as a "p" tag in a mute list?
Not only that, but you are still seeing his note tagging you, even though you have him muted, so your client is ignoring your mute list?
I suppose this is a case in point why having the option to add muted profiles privately (encrypted mutes) is important.

2025-06-04 20:54:32 GMT

- reply

You bet, my friend!
Maybe I should open a relay selection consulting service... 😂

2025-06-04 20:44:39 GMT

- reply

Indeed. A debit card is really the same principle, but attaches to a checking account instead of a credit line. Therefore, it is subject to the same KYC regulations and much of the same charge-back risk.

2025-06-04 20:29:51 GMT

- reply

There anywhere that performs testing of such things that could be pulled in by the marketplace? If not, that will be on the relay owner to market why their paid relay is better than the competition.

2025-06-04 20:26:26 GMT

- reply

Don't even need to do all that.
Just add `randomuser.me` to your muted words, assuming your client supports that. Aside from that, you can also read from better relays. Right now, your kind 10002 shows your are using 11 relays, including 6 public relays, as both inbox and outbox.
You're also using an indexer relay (purplepag.es) as an inbox/outbox relay for some reason... That one is usually just used by clients in the background. You shouldn't need to add it as a read relay manually. It aggregates kind 10002 events from other relays, so you should not need to write to it manually either.
Looks like you have auth.nostr1.com in there as a public inbox/outbox, too. This relay is for DMs, so it should go in your kind 10050, not your kind 10002. In Amethyst, that would be the section for "DM Inbox Relays." Looks like you have it there already, so you can remove it from your inbox/outbox relays.
Nostr.band's relay is much better suited as a search relay than an inbox or outbox. It's an aggregator, so your notes will very likely end up on it whether you intentionally write to it or not, and that's also why it is full of spam. No need to write to it directly. Good news is, you have it listed as a search relay, too. You can go ahead and remove it as an inbox/outbox relay.
You can keep writing notes to the public relays if you want, but cut your read/inbox relays down to nostrelites.org, wot.utxo.one, and I would recommend nostr.wine as an additional read relay, even if you don't pay for write access. You could always add another WoT relay into the mix to read from as well.
That said, a brief review of the public relays you are using shows that most of the reply spam is on nos.lol, nostr-dev.wellorder.net, nostr-pub.wellorder.net, and offchain.pub. Remove them as inbox/read relays and you'll be much better off.

2025-06-04 19:45:07 GMT

- reply

As soon as you added "credit card" you eliminated the possibility that it exists.

2025-06-04 19:43:43 GMT

- reply

That's a very good point.
A marketplace where those offering services have to list them could still integrate WoT based rankings, though.
Say nostr.wine, nostr.land, and jellyfish.land each listed their paid relays in the marketplace and the user could pay for them directly within the app. They might still find it useful to see which of them was used most by those in their WoT.

2025-06-04 19:37:12 GMT

- reply

"I'm going to forge ahead anyhow."
Translation: The push back is not compelling.

2025-06-04 19:32:44 GMT

- reply

Yeah, not sure if the seller was using Shopstr for DMing me. May have been, or may have been using another client with NIP-17 DMs.
Either way, even after providing tools that allow media to be encrypted, users will still need to take advantage of it. I could 100% still see some users uploading directly to a public Blossom server and copy/pasting the URL into the DM, thinking they're all good because DMs are encrypted.
Not really anything that can be done about that.

2025-06-04 17:18:46 GMT

- reply

It's fine. You're working on encrypted media in private communities and DMs right now, right? That's HUGE!
Example: I had purchased something via Shopstr and the seller sent me a screenshot back, confirming my address before shipping to me. Thing is, he was using nostr.build for media hosting and so, even though the image was sent in a DM, it was not encrypted and was there for all the world to see in nostr.build's free image gallery.
Thankfully the guys over there at nostr.build were quick to take it down at my request, but it's a good lesson in why we NEED encrypted media in DMs.
Interop for muted words can wait.

2025-06-04 17:07:36 GMT

- reply

You mean "thorn in the side"? 😂
I only noticed this discrepancy between clients because with all the adding of muted words to banish the reply spam lately, I saw that adding a muted word in Amethyst didn't translate to it being muted in other clients, even if they supported muted words.
Me being me, I had to dig into it and find out why that was the case.

2025-06-04 07:38:12 GMT

- reply

Got it. No other option is currently available for logging into iOS apps. It’s being worked on. There is a dev building something similar to Amber for the iOS side of things, but no ETA.

2025-06-04 07:10:36 GMT

- reply

What other method is there on iOS? There is no Amber equivalent on iOS yet.

2025-06-04 06:53:59 GMT

- reply

How about the encrypted mute items? Is Pokey decrypting and muting those, or ignoring them?

2025-06-04 05:29:10 GMT

- reply

I don't know of anything like that.
Some sort of Nostr services marketplace where devs can promote their latest client, or users can compare the services provided by various paid relays?
It seems like a tool a lot of folks would find useful. I could even see it being worth having dynamic suggestions, based on your WoT.
Say you wanted to see recommendations for a Nostr address provider. If you're logged in, it could look at the domains that are most popular among your WoT, pulling the info from their kind 0, and display a ranked list to the user.
Similarly, if you wanted to see recommendations for Blossom servers, it could look at the kind 10063s of those within your WoT. The same could be done with relays, pulling from their 10002s to determine which ones are most popular.

2025-06-04 00:36:47 GMT

- reply

I can't believe I didn't even check Jumble...
Jumble appears to add encrypted entries to your kind 10000, similar to Amethyst. Which is great for Jumble, but whoever you mute there won't be muted on any client that doesn't support it.

2025-06-04 00:25:23 GMT

Ok, it's time to gripe a little bit, as I discovered an annoying lack of interoperability between various #Nostr clients that really ought not to be the case:
Mute lists.
Beware, this is a bit of a long one...
When a user mutes an npub, or a word, they don't want it to only be muted in Amethyst, and not muted at all in Primal. They want it to be muted across all Nostr clients they use.
The standard mute list, according to NIP-51 is kind 10000. All users should have exactly one of these, and relays should only keep the most recent version.
Mute lists may contain a few different types of muted content:
1. Muted users/npubs, designated by a "p" tag.
2. Muted hashtags, designated by a "t" tag.
3. Muted words, designated by a "word" tag.
4. Muted threads (such as hellthreads), designated by a "e" tag.
Some clients also encrypt the entries added to the mute list. While not required, it is part of the spec that clients should expect to see within a kind 10000, and I think it should be preferred. A given npub should not be aware that another npub has muted them and unencrypted mute lists are readable by anyone, unless we move to only saving mute lists to relays that can require AUTH to read them.
Yet, I see a wide variety of handling of mute lists by clients.
#Amethyst uses kind 10000 as expected, and encrypts all content saved to the mute list (hooray!). It seems to support muting npubs and words, and has no support for muting hashtags or threads. @npub1gcx…nj5z, please chime in to correct me if I have misrepresented anything here.
#Coracle uses kind 10000 for muted npubs and also decrypts the muted npubs that were added by Amethyst, so they are also muted on Coracle. However, users muted on Coracle are not encrypted. I imagine this is because Coracle is trying to use mute information for the sake of building web-of-trust scores (mutes by those within your WoT count as -1 in the scoring), and any encrypted mute information cannot be used to calculate those scores. Also, though Coracle supports muted words, it does not seem to see the words I have muted from Amethyst in my kind 10000, and seems to be keeping a separate list, because words I have added in Coracle don't show up on my kind 10000, and are therefore not seen by other clients. @npub1jlr…ynqn, can you offer some clarity on how Coracle handles mutes, especially regarding muted words?
#Primal web seems to have an old kind 30000 list with only two npubs listed, while Primal Android didn't show any muted users at all, but adding a muted user added the npub to my kind 10000, which suggests Primal simply doesn't support decrypting the other entries that were added from Amethyst. Also, muting an npub on Primal resulted in all the encrypted entries on my mute list from Amethyst being nuked.
#Nostur did not display any of the above. Not my kind 10000, encrypted entries or not, or the kind 30000 Primal had been using at some time in the past. Adding a "blocked" user in Nostur also did not add them to my kind 10000 and did not add any other list type that I could find on listr.lol either. I am guessing it is using a list kind that isn't recognized or is just storing blocked npubs locally. @npub1n0s…lahe, can you provide some insight into how Nostur is handling mutes/blocks, and why it doesn't seem to be using kind 10000?
#Damus appears to be using kind 10000, but only shows entries that have not been encrypted. However, when adding a new blocked user, it does not appear that Damus wipes out the encrypted entries in the list. If not supporting encrypted entries within your client, this is the best way to handle them, rather than erasing them when replacing the kind 10000 as Primal did.
#Nostrudel behaves much the same as Damus, using the kind 10000 and only showing entries that have not been encrypted, but also not wiping encrypted entries when adding a new entry.
#Pokey also seems to have trouble respecting mute lists for the sake of muting notifications. This appears to be because Pokey only looks for your mute list on your inbox(read) relays, while users publish their mute list to their outbox(write) relays, and those may not necessarily be the same. However, I wonder if it is also an issue of Pokey indeed being able to find a user's mute list, but not taking encrypted entries into consideration. @npub1v3t…yvjh, can you confirm whether Pokey is able to mute notifications from npubs that have been encrypted in a users mute list?
Is it possible to get these and other major clients on the same page about how to handle mute lists?
Yesterday, @nprofile…8jsn posted this about what interoperability means on Nostr:
#nevent1q…d6zu
I pointed out that in order for this to be the case, we also need to agree on the format and expected content that will be contained in a specific note kind. From what I can tell, there is little agreement on how mute lists should be handled.
Should they include encrypted entries? If they do, should clients respect the encrypted entries, since the user who created that kind 10000 certainly doesn't want to see notes from the npubs they added to their mute list, encrypted or not? Clients certainly should not nuke encrypted content from the mute list if it is present, right? Or should we drop support for encrypted entries on mute lists altogether, since some clients are relying on mute lists from npubs within a user's WoT to determine what content is likely to be spam?
Users just want to know that when they mute an npub or a word in one client, that it will also be muted in other clients, and that muting in one client won't nuke their mute list in another client.

2025-06-03 06:25:43 GMT

- reply

Alas, remember when @nprofile…w35w hung out here instead of Xitter?

2025-06-02 19:03:17 GMT

- reply

I think it would be the other way around in this case. Why not rename dollars to tips?

2025-06-02 18:50:49 GMT

- reply

Yeah, but we're talking about people here, not just nodes on a network.
"Connect" has a relationship implication in the context of people connecting with one another that isn't implied when talking about nodes on a network.
More importantly, a personal connection is something stronger and more meaningful than what is happening when a user adds an npub to their kind 3. They may have no personal connection to that npub at all. It just means they want that npub's notes to show up in their home feed.

2025-06-02 18:13:36 GMT

- reply

Just another spam attack that is probably intended to show Nostr's susceptibility to such things and encourage devs to build solutions.
Thing is, we already have some pretty good solutions!
Here's my canned suggestion for reducing or eliminating spam:
If you are seeing a lot of spam in your replies, it is because you are reading from relays that spammers can write to for free. Spam can only happen if two things are true: 1. It's free and easy to create new identities. 2. New identities can write notes to relays without a cost.
We're not able to, nor do we want to, make it difficult to create a new identity on Nostr, so reducing spam by making new users jump through hoops that can only be enforced by a centralized entity is not an option.
That means we need to prevent it via option 2, by restricting new identities from writing notes to relays without a cost. If you are reading from relays that don't impose some cost to write to them, either social, computational, or monetary, then you are bound to see spam on a regular basis.
Instead of reading from free and public relays, you should consider trading them out for the following types of relays:
- Web-of-Trust (WoT): This relay type imposes a social cost in order to write to it. Namely, you have to be followed by the relay owner or one of the npubs the relay owner follows before you can write notes to the relay. These types of relays may also automatically aggregate notes from those within the web-of-trust, even if they were written to other relays.
- Proof-of-Work (PoW): This relay type is less common, and it imposes a computational cost to write to it. Only those who have dedicated computational energy to generating the required PoW can write to the relay. This cost is trivial for the honest user, who only posts up to a couple times a minute, but imposes heavy costs on spammers, who are trying to post hundreds or thousands of times per minute. Unfortunately, most Nostr clients don't support adding PoW to notes, so most relays don't use it as a spam mitigation measure.
- Paid Relays: As the name implies, this relay type imposes a monetary cost to write to it. It may also impose a cost to read from it, but that is less common. Since this cost is per npub, and spammers don't ever use just one npub since that's too trivial to mute and move on, this makes paid relays affordable for honest users, but too expensive for spammers.
Since the only two relay types above that are currently in wide use are web-of-trust and paid relays, here are a few suggestions for each.
Web-of-Trust:
- wot.utxo.one
- nostrelites.org
- wot.nostr.net
Paid:
- nostr.wine
- nostr.land
- jellyfish.land

2025-06-02 18:08:53 GMT

- reply

Not sure about anything that would do both on-chain (playing nice with your ColdCard) and Lightning all in one.
I am generally using my own node for Lightning, connected to Alby Go or Zeus via Nostr Wallet Connect.
If you're wanting to use it with Nostr for zaps, you're probably going to want to use something with Nostr Wallet Connect as an option, like @nprofile…sdxk or @nprofile…d4vz .
@nprofile…5j0h , is NWC available as part of the beta you recently released, or is it just eCash that I am thinking of? I know users can connect their existing NWC wallets to Zeus, but can Zeus' embedded LND be connected to Nostr apps via NWC?

2025-06-02 17:58:16 GMT

- reply

OS?
If Android: Amethyst
If iOS: Nostur

2025-06-02 17:55:53 GMT

- reply

Shipyard is 1000% better. lol!

2025-06-02 17:55:04 GMT

- reply

Hivetalk is a video meeting app and they have recently added more features, including scheduling posts.
Highly recommend checking it out!

2025-06-02 17:52:24 GMT

- reply

I have an old one in my notes. Maybe it wasn't you who made it... "Nostr It" sound familiar?

2025-06-02 17:46:26 GMT

- reply

Note, though, that the only reason adding that to your muted words works is because this spam attack happens to use that domain for their profile pictures. If they change what domain they are using, the spam will be back. It's a temporary band-aid at best.
Also note that while this works on Amethyst, your muted words may not carry over to other clients. Amethyst encrypts the muted users and muted words when it adds them to your mute list, and not all clients support decrypting them, or muted words in general.
As far as "pay once" relays go, there's nostr.wine.

2025-06-02 17:41:04 GMT

- reply

When China banned mining last time, over 50% of the global hash rate was located in China, and most of it turned off and moved elsewhere. That massive drop in hash rate resulted in a "fire sale" for Bitcoin, which dropped to $30k. There were also other contributing factors, such as Elon announcing that Tesla would no longer accept Bitcoin that occurred at the same time.
I haven't heard about any new ban on mining from China, but even if they did, it would not have nearly the same effect on hash rate, since most of the miners are no longer located in China. If there's been a ban, it hasn't seemed to affect current hash rate at all, so I also wouldn't expect it to cause much of a dip in price.

2025-06-02 17:30:49 GMT

- reply

If you don't have Alby extension set up, you can go to the Settings page in Nostrudel, then the section for Lightning, and there will be a "Connect Wallet" option that will have NWC as one of the connection options.
https://relay.brightbolt.net/41f2b4f320e09b1646ea0d0da948270b4cc195120857f6d2c6b1bbefa6d88b2a.jpg
If you have Alby extension, Nostrudel will default to using that instead, and you can connect your wallet to your Alby extension via NWC.

2025-06-02 17:21:19 GMT

- reply

It has recently been added to @npub1z0l…8ldk Honey.
There was another one that I think @npub1l2v…ajft made before Shipyard, where you could schedule a post based on a block height, date and time, or other factors. Don't know if it is still up and running, though.

2025-06-02 17:13:42 GMT

- reply

You've got a couple options.
1. Use someone else's existing WoT relay, or a couple different ones. The upside to this is that you just need the relay address to add it to your relay list. The downside is, it's based on the relay owner's web-of-trust, instead of yours. So you may not see notes from people who would be within your WoT that don't happen to be in the relay owner's.
2. Set up your own WoT relay that pulls in notes from those in your WoT. For this I would use @npub1utx…50e8's WoT Relay implementation found here: https://github.com/bitvora/wot-relay and you'll need to have a domain and have a bit of know-how to point that domain to your relay end-point on whatever you are running it on.
3. Use Coracle as your Nostr client and set the WoT filter to a minimum of 1. No more spammers, regardless of which relays you are using.
For options 1 and 2 to work, your relay list must not have ANY public relays that you are READING from. You can write to public relays if you like, but if you are reading from any, you will see spam.

2025-06-02 17:05:19 GMT

- reply

Haven is khatru under the hood, by the way.

2025-06-02 16:56:40 GMT

- reply

That's similar to asking "Which is the best Nostr client?" There isn't really a "best." Each has features that others don't and may be better for some use-cases, and not as good for others.
The same is true for mobile wallets.
Do you just need it for on-chain and need it to play nice with your ColdCard? Probably @npub1cvq…yjt3 is the way to go.
Do you need it to be self-custody Lightning with a Lightning address for receiving? Then I would go with @npub1xnf…lpr5.
Do you need a way to easily receive Lightning payouts from @npub1qtv…7dze without having to run your own CLN node? Then I'd probably suggest using @npub1h2q…w8ch and install it as a PWA.
So, if you can give me some details about how you plan to use the wallet, I can probably give some more specific guidance.

2025-06-02 16:48:27 GMT

- reply

Best approximations are available on https://stats.nostr.band/
Didn't see a breakdown for monthly active users specifically. Just daily and weekly, and at the top of the page you can choose to see numbers for either the last 2 months, or the last 6 months.

2025-06-02 15:37:37 GMT

- reply

Yes, and the format and expected content within a given kind.

2025-06-02 15:36:18 GMT

- reply

How can it be a "connection" if it is only one way?
Adding an npub to my kind 3 just means I'll see that npub's posts in my feed. We've not necessarily made any kind of mutual connection and may have no relationship to one another at all.
All that it means is that I am interested in seeing what that npub has to say.
If it worked by sending some kind of request to connect that had to be approved by the npub I was trying to connect with, then you might be on to something.

2025-05-31 19:13:55 GMT

Interesting... I popped over to #Primal to see how bad the spam reply nonsense is here and I have ZERO reply spam in my notifications.
I am seeing questions from Primal users about how to get rid of it, so I know it must be an issue over here, and I know that I am getting reply spam on my notes, because I am seeing it on Jumble or on Coracle when I have my WoT filter set to 0.
So what gives? Primal users are all reading from the same caching server, rather than directly from their selected relays, so why are other users seeing reply spam on Primal but I'm not?

2025-05-31 18:20:06 GMT

I feel like PoW is an underutilized spam prevention technique, since most clients don't support it, and most relays don't require it.
Now that pagerank is a thing, I think public relays could do a lot to minimize spam by simply requiring PoW for anyone below a pagerank threshold, but only if more clients supported adding PoW to notes.
Maybe it's a chicken and egg thing... Relay operators are reticent to add PoW requirements since so few clients support it, and client devs are reticent to add the option to include PoW since no relays are requiring it.

2025-05-30 18:15:41 GMT

- reply

Sure, but a limited usefulness. From that screenshot I can tell that is likely the legit @npub1jlr…ynqn due to the WoT ring next to his handle. Impostors don't build up WoT scores like that. And I can tell that without having to look up his profile, check his NIP-05 or follower count, or anything. It's just immediately apparent at a glance.
Here's a post on Nostrudel by contrast:
https://relay.brightbolt.net/5d7c317cee97840724568f93d69c0808a6c3598c558adfbce2b5152860dfe116.jpg
Can you tell, without going to his profile, whether this post is the legit @npub1jlr…ynqn or a fake?
This colored border around his profile picture means exactly nothing to me unless I happen to already know what color it SHOULD be.
The above screenshot is from the impostor, by the way. @npub1jlr…ynqn's correct color is lime green on Nostrudel. But the point is, I didn't just happen to know that. I had to look him up by his npub that I already knew (from Coracle) to learn that lime green is the color I should be looking for.

2025-05-30 17:13:24 GMT

- reply

Yes, I have seen that Nostrudel has it. And yes, it can help to quickly identify that you are dealing with a different npub, but only if you already know the correct one and remember what color they should have. Which means, not very useful at all...

2025-05-30 16:47:26 GMT

- reply

Trying to understand how this would help.
So, it converts an npub into a series of colors instead, because npubs are too long. Great. How does that help someone know whether color series A or color series B is the impostor? They would need to already know the correct color series ahead of time.

2025-05-30 16:11:00 GMT

- reply

I think Coracle has the right approach. Just need more clients to have similar indicators, marticularly on their search results.
It's to the point that I won't search for users on any other client but Coracle. It's the only one I know I can trust to have the legit profile as the top result, with a clear indication of why I should trust that they are not an impostor.

2025-05-30 16:05:16 GMT

- reply

I find it quite ironic that it would have been obvious he was an impostor if they had been using Coracle.

2025-05-29 18:01:17 GMT

- reply

My lightning address is [email protected], and nope, that does not work for getting an invoice, either after updating it to "https://getalby.com/lnurlp/dikaios1517/callback?amount=1000"

2025-05-29 17:22:41 GMT

- reply

Thanks for the response!
I was unaware that Shopify was blocking alternative payment apps. How did OpenNode and Ibex Pay get around that, I wonder?
Or did you mean the Apple app store? Because I was not asking about that.

2025-05-29 17:21:39 GMT

- reply

Should have added a sensitive content warning, huh? 🤣

2025-05-29 16:30:54 GMT

At the recommendation of @nprofile…u0w6, I tried out shaving with @nprofile…75w5 soap. Specifically the pine tar scent.
No, not my face. My head.
https://relay.brightbolt.net/97a212e114a5fe542d3a73d436dfcf26e81991915495b25904eaf2da34cba39e.jpg https://relay.brightbolt.net/c8171caa642d49cd7720f9d7bb1822bed528cf233213d5e0f193901684e5f886.jpg
Lathers up really nice and was a great shaving experience! Highly recommend!

2025-05-29 16:05:47 GMT

- reply

Good question. The only part of the notification that may not be easily understood is the "Hash Mismatch" portion. The rest is plain.
I don't think the problem is primarily a lack of understanding the meaning of the warning. I think the issue is that users are assuming the Zapstore is wrong in presenting the warning at all. That the file certainly isn't malicious, and there must be a bug in the Zapstore.
It's a sort of normalcy bias. Apps generally install fine. They've never experienced installing an app that was actually not what the dev released, but was a malicious app put in its place. So they assume it couldn't actually be what has occurred.
What's more, they're probably correct that it isn't a malicious app. It's probably just that the dev made a change after signing and didn't update the signature on the Zapstore. However, the correct course of action is not to assume that's the case and install the app anyway directly from GitHub... The correct thing to do is reach out to the dev and alert them to the fact that there is a hash mismatch, so the dev can diagnose why.
Perhaps the alert should suggest this course of action.

2025-05-28 21:02:29 GMT

@npub1cwn…raju any plans to add Shopify integration? I have a good friend who runs an online store built on Shopify and I know he would love to have a simple way to accept Bitcoin.

2025-05-28 19:26:57 GMT

- reply

You only need to provide that to use Primal's built-in wallet, which is provided by Strike.
If you have a Nostr Wallet Connect compatible wallet already, you can link it to Primal in their Android app or on Primal web. This feature is not available on Primal iOS, yet.