Thereβs a special place in hell for the creator of these word jumble reply bots π€¬π
Login to reply
Replies (33)
place of reply π€¬π for Thereβs jumble bots the a these creator in word special hell
+ friends of friends really reduces the noise.


What client are you running?
Omg thank you! I was real busy this spring and missed the βanti hellthreadβ toggle. Awesome.
Where did you find the βfriends of friendsβ option?
Damus, just limited notifications

Thanks brother, thatβs huge
Glad I was helpful π
Every time I come back to Nostr after a short hiatus, there's a new script kiddie doing this kind of stuff. Locking yourself behind WoT and paid relays has its advantages. None of the new Bot notes have made it to my timeline yet. I know this isnβt really fair to new npubs, but I haven't found a better way to have a reasonable experience on Nostr yet.
Itβs a good point though. Thanks mate
That's a start. We need to talk about this though:
That's your list of inbox and outbox relays. It could use a clean up.
That's your list of inbox and outbox relays. It could use a clean up.I just popped over to Damus, though. It looks like it isn't using this list at all.
nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3g4h5cp7 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?
Tracked it down. Looks like the list of relays Damus uses are found in the user's kind 3 follow list. Specifically under the "content" tag.
Why is Damus using this as the primary source for a user's relay list, instead of kind 10002, and why does the user have no control over which ones are read and which ones are write?
hist.nostr.land as an inbox relay?
There's definitely some interesting choices in your 10002 as well. π
What client do you use primarily?
nostr.land setup guide:
== if you are paying ==
add nostr.land as read/write or inbox/outbox
done
== if you are not ==
add nostr.land as read/inbox
add hist.nostr.land as write/outbox (backups)
nostr.land offers free storage for relay lists for better outbox
So paying for nostr.land eliminates the need to have hist.nostr.land in my write relays?
yes
NICE! Thanks for the head's up!
there is another relay coming as well
there are 3 modes you can choose:
- mono: nostr.land serves all events
- feeds: nostr.land only serves global feed, the other relay serves all
- split: nostr.land serves all paid, the other relay serves all
(cc nostr:npub1qdsjkr46urkg6vqrr3zqhgy8l7dazc5k9hlm5jmwqg0vft7hzgtqamgfw3)
(feature to be released, but basically focusing a lot on single-connection and/or bandwidth efficiency)
thanks for the cc π¬
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.
Damus still uses a legacy unspecified format (as do/did many clients like Amethyst) where the list of relays is set on the content field of kind 3 follow lists. You cannot specify which ones are used for reads and which ones are used for writes. Itβs on my list of things to do to fix for Damus on iOS, as part of my plan to support the outbox model.
I donβt think so, nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8 switched us over to the proper list
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.
This version supports NIP-65 lists, but has a fallback to kind:3 if it cannot find a NIP-65 list.
What makes you say it gets the list from the kind:3? What symptoms are you experiencing? It's possible you are running into some kind of edge case.
nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf this has migrated over to NIP-65, (but without full outbox support). Some relevant new files of this migration would be `UserRelayListManager.swift` and `NIP65.swift`.
We still use the legacy format as a fallback, but give preference to NIP-65 lists.
Oh, thatβs news to me. Great!
Ok. Just published an update to my 10002 and it seems Damus found it. Not sure why it didn't find it before, as I had it blasted all over the place. π
It was just my kind 3 relays before that, so it makes sense that it would fall back to those if it can't find the 10002.
Thank you, gents!
For the love of God, just make sure to NOT add the kind3 list directly into the NIP-65 lists. This has created so many issues for outbox systems because each relay list becomes MASSIVE.
i was thinking of adding a relay limit when adding relays. I've seen users add like 69 relays
I am adding the kind3 stuff into new lists which I called Proxy and Broadcasting as below. Terrible names, but it separates the information that followers need to know (which should be in NIP-65) from the relays the user wants to use for his own feeds/broadcasting. Separating the two is paramount in my mind.
https://github.com/nostr-protocol/nips/pull/1985
Mandatory "nice" activated π€