So much I want to accomplish here. I've got an API for the data I'm collecting. Once I setup a key system for it any client that wants to bulk load aggregated data such as likes or reply counts is welcome to use it.
Ok this should be fixed now. Let me know if your follower count is correct. It may not be exactly the same as what your client shows you since different relays are involved, but it should be pretty close.
Yw. I'd work on it right now but I'm being interviewed on a podcast and have to prep!
Cool. I have plans for a lot of improvements in the text search such as date range searching and searching only specific accounts. I also want to add in the ability to "login" with your keys and only search notes from people you follow and that kind of thing.
That issue hasn't been resolved yet. The resolved issue was with old profile data being shown on the user search. The follower count issue should hopefully be resolved by tonight (ET).
The discrepancy issue you told me about should be fixed now Derek. Let me know if you still see that issue. I checked your profile and it has the correct image now.
I'm aware of the follower discrepancy. I'm pretty sure I know the cause and will be working on that later today, along with an issue #[0]Ā Ā pointed out to me. Both will be fixed.
Goodnight sir. Rest well and arise to another amazing day.
Nostr definitely has a spam problem. When I was gathering events for the Nostrum Search database, out of ~2.5 million events about 1.2 million were pure spam that had to be filtered out (mostly notes that didn't use any of canonical note "kinds"). I'm sure these issues will be tackled over time, but I agree that a pay-to-play LN solution is probably the best one.
No worries.Ā #[3]Ā posted a good solution to the git thread. Have a REST API built into relays that returns all the stats for a given note (# reactions, # replies, # reports) etc. That would solve more than just the reactions issue.
Canāt just magically have an aggregate event. That defeats the whole purpose of the way events are designed. I have a short write up of events that might help clarify here https://armstrys.github.io/nostrfastr/nostr_core.html#nostr-events
I'm not proposing anything "magically" happen. As a 25+ year dev I'm aware of the technical issues involved in aggregate storage. I also understand Nostr being designed for in-time events and not aggregates. If any solution would be unacceptable due to that design philosophy, then there's no purpose in having a reaction event, at least not for large public relays.
Once Nostr popularity has millions (or tens of millions) of daily active users requesting thousands or hundreds of thousands of kind 7 notes for each note being displayed, the load on the relays would be untenable. There's a discussion of possibilities on the issue I posted to the Nostr git if your'e interested in chiming in there.
What I'm proposing is that each relay store all of the reactions in a single event rather than a bunch of separate events so a client can make a single call and iterate through all of the reactions to tally them up. That's not different than what is done now except that it's not in a bunch of separate events that require the relay to scan its db for all of the reactions and the client to wait on receiving all of those separate reaction events rather than a single event with a single indexed key that's extremely efficient to lookup and send to the client.
I'm not talking about all relays sharing data. I mean each relay that receives the update adds it to its own list of reactions. I love the fact that there is no centralized "truth teller" with Nostr. People pick and choose which relays they trust and go with the data it presents them. That's great. I'd just like a less cost-intensive way to aggregate the reactions.
As a dev that's worked in the marketing sector for 20+ years, I know that for every one person that replies there are 50+ people that liked what you had to say but didn't reply. The Like concept makes it easy to know if your audience is vibing with what you have to say (or not), esp for smaller creators. I'm not talking about algos or curation, but for the benefit of the content creators to know what their audience is looking for. Market forces. Supply and demand.
Reminds me of the late 80s early 90s pre-www days. Very raw and rowdy. Love it.
Fair point. A single event that contains all of the reaction tags for a given event id would work. Rather than create a new event each time a reaction comes in, just update the existing one and return that one event when the clients request the reactions.
Nostr needs a better way to handle likes/reactions. Nip 25 is a terribly inefficient way to do it. Burying reactions in the tags requires clients to do a huge amount of data gathering to properly show likes/reactions. Having an event kind/# that represents a tally of all likes for an event would be far more efficient, otherwise the client has to gather potentially thousands of events just to count up the likes for a note. I'll be creating a separate db table that mines and sums the reactions, but that creates a centralized solution rather than a decentralized one. Thoughts?
#[0] #[1] #[2] #[3]
I gather the events from a bunch of the most popular relays. I did the first load of events from Jan '22 'til yesterday, then counted up which relays in those events were the most popular, then re-gathered the events from all the most popular relays.