Typically spam will have a url - a call to action to get you to do something.
How depth 4 is less than 3? Run out of people? Maybe filtering on profiles to require a profile or something?
Can you tell me if Biden’s AIM status is online? I think he blocked me.
Shouldn’t it be hosted on itself 😉
Seriously tho, I welcome all decentralised projects that will define this decade warmly.
Here’s what I have. It’s not many. I’m not indexing Damus atm.
Seeing lots more Japanese notes the past month. It’s a little Timezone biased.
It’s less about that single transaction. It’s more about could lightning relay nodes reverse engineer the hops if they shared data or enough of them colluded.
The good news I guess is the sender doesn’t need to send such specific amounts, so they are at their own mercy.
Interestingly is that leaking meta data like the position of the transaction hop? I’m not sure.
Are these numbers validated ZAPs?
I’m finding a lot of ZAPs fail validation checks. Not necessarily spam or fake.. validation just have 4 points of easy failure.
If it’s things like relay event rate limits, maybe asking to be whitelisted by pubkey or IP.
Zaps do generate a significant amount of events from the wallet providers.
Leading zero bits (which is different from leading zeros, for clarity).
Spam will be coming from servers. The reasonable compute for a server to generate POW is where the minimum gets set.. client devices just need to match it.
Dynamic POW requirements based on content or publishers are also possible.
We won’t know a real number until it’s used in the wild. It depends on how much spammers / advertisers are willing to pay extra to get their events accepted.
Can everybody help ZAP twitter so they can upgrade their tweet relays?
Testing if ‘s renders after a mention #[0]‘s testing.
Have you seen #[5] ‘s repo? https://github.com/0xtlt/nostr_rust/tree/main
Or #[6] ‘s relay has signing code too. https://github.com/scsibug/nostr-rs-relay/blob/master/src/event.rs
Ok, so here is a draft NIP for a Proof of Work Service Provider. All Feedback welcome!
Would love to hear from relay operators, open source relay contributors, client apps, Nostr users.
Basically, it allows for you to generate an event POW before signing as part of a relay membership or pre-paid credit system. Ultimately to succeed, Nostr apps would need to offer it.
I have a fully functional rust implementation I’ll likely open source (if enough interest), that just needs the payment integration code - and a bunch of testing.
https://gist.github.com/blakejakopovic/6c0ea718c0f956c461e9e8952d8c6533
This might interest you.
It’s looking like the proof of work minimum required to combat spam is likely around 20. That’s really high for mobiles and even laptops.
Therefore, we need to offload that computation somewhere - like a service provider.
I aim to release initial code this week. It’s missing payments and remote POW generation (if you want to use a different server).
#[2]
GraphQL, or followers/following relationship graphs? Or event propagation graph queries?
DID is so perfect that after 10 years it doesn’t have one successful application. It’s been a case of death by committee - instead of build and iterate.
The problem it attempts to solve is important - and Nostr certainly doesn’t attempt to address a complete matching problem space.
My biggest issue with DIDs are that no one ever seems to say, “hey, you can use this same mechanism or base spec from DIDs to solve that problem - it’s well thought out and will work well”. They just say, please adopt 100% of a 1000 page spec no one seems to care about in entirety.
Bitcoin Magazine’s gone down hill.