nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z will this stop the yoda bots?
Discussion
bots? this will the stop yoda nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
No, but they all use the same url for their profile pictures. You can add a hidden word that includes randomuser.me and they will disappear.
The hidden words feature is really a superpower that more clients need to implement. I remember that we used it as a band-aid during the old reply-guy spam back in late summer of last year, too.
However, it is just that: a band-aid. It stopped working when the bots no longer used the words we were blocking, and this one will fail, too, if they stop using that user generation service to host their profile pictures.
Reading from relays that are better at spam mitigation is a more robust and long-term solution. And I say that as someone who does not run a paid relay I am trying to shill.
The beauty of it is that in order for bots to sell their thing, they need some type of anchor. It's either the name, the url, ln address, some keywords in the post or their about me... Etc. There is always something. We just need to figure out what that is and block it.
Until that anchor is something shared with legitimate users.
Say they all start using a free Blossom server to host their profile pics (like Nostr.Build), and MiniBits or npub.cash for their lightning addresses. Then using muted words will block a large chunk of legitimate users along with the bots.
That hasn't happened yet. :)
There was always something else to anchor.
That's fair.
Again, muted words is a great feature, and definitely one to have in the tool-belt for dealing with this kind of nonsense.
I have also been very happy with how well reading from WoT relays and paid relays has worked on most clients. I also wish more clients would support adding PoW to notes so that relay operators could realistically add minimum PoW requirements for anyone outside the WoT to also be able to write to the relay without flinging wide the gates to spammers.
That said, we're in a bit of a goofy situation where operators of paid relays are collectively incentivised to forever-spam unpaid relays.
Shows how important it is to weave financial incentives into the protocol base layer. (I think BitTorrent of all things shows the way there.)
Hadn't thought about it that way, but you're absolutely right. So long as spam isn't an issue, there's no demand for paid relays. No one feels any pain from not having them. Therefore, the best way to drive demand for paid relays is to generate spam.
That said, I wouldn't accuse any particular paid relay operator of being behind the recent spam attack without some pretty damning evidence, and I don't think anyone has accused any particular relay operator. At least not that I have seen.
Chances are that the bulk of what most of us would consider spam is just being perpetrated by people who like to cause trouble simply because they can, or because they think they are making a point.
Spam on public relays is inevitable, no matter who may be behind it. You will find it on any sufficiently large network where the following are true: 1. It's free and easy to create new identities on the network. 2. New identities can write data others will see without a cost.
On Nostr, we're not able to make it difficult to create a new identity. Nor would we want to. That means our only option for mitigating spam is to impose some form of cost for new identities to write data to relays that others will see. Public relays impose no cost at all, so they are guaranteed to have spam.
The three typical means of imposing costs to writing data to a relay are social, computational, or monetary. WoT relays would be an example of social cost to gain write access. PoW relays would be computational cost, but we hardly see any of these in the wild since most clients don't support adding PoW to notes. And, of course, paid relays come in as the monetary cost option.
It's a tough nut to crack, though, when you are trying to encourage the network to grow. We WANT new users to come here, and we want them to have a pleasant experience so they will stay. Adding social, computational, or monetary costs in their way is antithetical to that goal. Yet, new users are also the ones most likely to be spam bots that will make the experience of new and existing users alike unbearable. Costs should therefore be imposed in such a way that they are virtually unnoticeable to legit new users, but are prohibitive to spammers.
I have a couple ideas how that might be achieved.
some combination of invites and WoT is the only way I see short of imposing a direct cost
Yes. Inviting someone to Nostr should come with some way to be notified if they accepted the invite, so you can immediately follow them, bootstrapping them into your web-of-trust. I believe nostr:npub1manlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqvyn9tn is working on something like that with https://nostrmeet.me/
Another thing clients could do is default to adding a certain amount of PoW to new users' notes, defining new users as those with no kind 10002 relay list, or no notes on their outbox relays with a timestamp older than X number of days. The exact number of days someone should be considered new is debatable and each client could use a different length of time. Then, clients could default to showing notes from npubs outside of the user's WoT that meet the minimum PoW. Coracle has the latter option, for instance, but no default PoW added to notes for new users.
The above could even be paired with a feature like Nostur has, where you have a few seconds to cancel a post before it is written to your relays. That way if you see a typo, you can cancel and fix it before it is permanently on display. During that few seconds, the client could be performing the required PoW.
I very much doubt this latest round has to do with a paid relay op. We’re in a pretty early and altruistic phase for Nostr all around these days.
But it does showcase the incentive misalignment. Paid relays are certainly are being offered a short-term incentive to make unpaid relays less viable. So just the fact that the network has created that particular temptation to resist is an issue. (I'd imagine this has been a pretty good week for paid-relay sign ups across the board.)
And even on the passive side, you can argue paid relays are short-term incentivised to sit back, not lend their expertise to help stop the spam, and also use situations like this in their marketing. It's just just how you'd want network incentives to be aligned.
What you'd want is a situation where paid relays are directly financially incentivised to participate in the guardianship of the network overall, including that of unpaid relays. (Of course everyone benefits from good network health in the end, but I mean in a direct way, at the protocol level, so short term counter-incentives don't get in the way.)
You’re bang on about the Catch 22 though, curious what your ideas are.
The ones I have I outlined here:
The first idea probably hinges on DMs working consistently for the notification when someone signs up that you invited, and DMs are quite a mess right now.
The second idea hinges upon more clients supporting PoW. The only one I know I can add PoW with right now is Coracle, but it's off by default.
I am also interested in hearing any ideas you might have about bringing the incentives of paid relays into alignment with participating in the guardianship of the network overall. You had mentioned that the way Bittorrent accomplished this was an example to follow, but I am not terribly familiar with the incentive structure there.
Gotcha, I'm thinking somewhat on those lines.
BitTorrent for the record uses blockchain as part of their wider incentive system, which clearly does oil the gears there, but blockchain wouldn't fly here. Here it would have to be e-cash based (and even then e-cash is still kinda hot-button here.)
I don't actually think unpaid relays work, just temporarily cost-covered relays.
If you implement a 1 sat per event toll, then it's a question of NIP-60 wallets as a default component of a Nostr profile (a lot to work still to be done there to give the user adequate contron) and a way for new users to get initially topped up.
The top-up part could involve an initial stash of cashu tokens P2PK locked to the relay operator, given out following the completion of an onboarding process that also acts as a screening process. For this you need a Nostr "first-top-up marketplace" of sorts, and a lot of specs to govern how the marketplace functions across the protocol.
The incentive for those offering first top-ups through such a marketplace is that users taking advantage can convert in some way (subscribe, etc.) when then run out of their initial Sats. So as a new user you can browse first-top-up options (or at least those that are visible to you based on xyz), see what you'll get, and pick an option, and go through the associated onboarding/screening. You get your first top up, and now you have a relationship with the topper-upper.
The topper-upper is incentivised to help ensure you have a good experience because, again. you can convert. The same as a freemium game being incentivised to ensure the player has enough fun to want to pay for something later.
The key is to make it so such top-ups can't be abused, or at least abused to a degree combatting the abuse negates the benefits. Again you need specs to prevent double-dipping and whatnot. And also time-expired top-up tokens, or perhaps a tiered-stash with upper tiered tokes being unlocked as a result of certain activity. All of this relies entirely on Cashu for the P2PK lock, expiration, condition setting and such.
And then there's the whole regulatory side, which, leave that for now.. But something along the lines of a protocol-defined first-top-up marketplace.
Also, muted words seem to be very client specific.
I have muted words on Amethyst, but they don't show as muted on Coracle. Instead, I guess I had added a different muted word there. Then Primal shows I have no muted words at all. Same with Damus.
Now I understand that there are plenty of folks out there who only ever use one client, so this isn't an issue for them. They can mute a word on their preferred client and it's all gravy until the next spam attack and they have to add a different word.
That's not the case for users like me, though, who use a wide variety of clients. Read relay selection is a solution that should work with most clients, and it should work against current and most future spam attacks without additional configuration needed.