Nostr Web Client

jleger2023

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]

Cameri🐦‍🔥 3y ago

It’s been proposed before… so there might be something open already… there was a talk once about a `COUNT` message. Relays may be able to cache these counts.

Every time the conversation devolves into “relays can make up counts” then everyone their heads. Apparently, we need Blockchain Proof grade likes/reactions/counts.

One issue is, every relay has a different copy of likes/events/etc so how do you show that? average? max? lots of unanswered questions.

The main issue that comes up is that once relays can craft info that users did not create we are in fake land.

It only takes 1 relay to receive payment to bump up those likes ;)

Reply to this note

Please Login to reply.

Discussion

Cameri🐦‍🔥 3y ago

Everyone loses their heads*

ama 3y ago

I was losing mine trying to figure out what you meant. 😂

Bones 3y ago

Byzantine problem?

jleger2023 3y ago

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.

monlovesmango 3y ago

and who is going to be source of truth of that single event? how do you validate the last person handling it updated it accurately?

Cameri🐦‍🔥 3y ago

*loses head*

monlovesmango 3y ago

🤣🤣

jleger2023 3y ago

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.

monlovesmango 3y ago

that model makes a great incentive for relays to game likes though. events you post to a relay can be independently verified. aggregated lists cannot be.

jleger2023 3y ago

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.

monlovesmango 3y ago

so doesn't help client side and makes db exception scenarios on relay side? personally i'd be against any proposal that changes relay db structure for one particular event kind.

Nate Levin 3y ago

Lots of performance issues would be mitigated if relays were smarter, but this is probably one of the easiest to implement I would imagine. Does force clients to trust relays a whole lot more, so it’s probably something that won’t happen for a while

armstrys 3y ago

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

5c11d2dc... 3y ago

lnbc4200n1p3m5cmzpp5wm9ncx5xcld29ja2q05l3nglp6uulvm6zr4ekkhykzfqthvqchpqdq5g9kxy7fqd9h8vmmfvdjscqzpgxqyz5vqsp5ghwp7423j8gwhmz7c0rmwdq2ved3q73vkzwy7nre4n4l0kyhtmhs9qyyssqprt5f4ysl7e2z6tk5s7jfpg20855xktkalcct95nm4th5dud9z4yhy22h3lnttfql84hwkena08h35eqc8up3e6pwalgqjtrvy6ptggpwjkult

jleger2023 3y ago

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.

https://github.com/nostr-protocol/nips/issues/159

armstrys 3y ago

Yes, sorry I naively posted last night without looking deeper into your comments and profile. Thanks for the link - curious to see more about this proposal.

jleger2023 3y ago

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.

⚡️🌱🌙 3y ago

I don’t really see a problem?

Personally I don’t care if relays have different lists for likes? Personally I don’t really see much merit in following the “likes” format of ye olde social media.

Notes should have a reply button, a boost/broadcast button so I can forward it to all my followers, a tip button that auto sends 1 or 2 sats, and a share button to post a link to the note elsewhere on the web.

Do you want an algorithm (created by whom? operated by whom?) to curate viral Tweets? Or do you just want things to spread organically?

I quite like things being organic and emergent, and likes actually being some infinitesimally small nano transaction.

Just consider how much more engaging nostr is, which is currently organic, compared to Twitter, which is algo driven. It’s not even comparable.

⚡️🌱🌙 3y ago

I don’t really see a problem?

Personally I don’t care if relays have different lists for likes? Personally I don’t really see much merit in following the “likes” format of ye olde social media.

Do you want an algorithm (created by whom? operated by whom?) to curate viral Tweets? Or do you just want things to spread organically?

I quite like things being organic and emergent, and likes actually being some infinitesimally small nano transaction.

Just consider how much more engaging nostr is, which is currently organic, compared to Twitter, which is algo driven. It’s not even comparable.

jleger2023 3y ago

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.

⚡️🌱🌙 3y ago

Yeah I get that. But personally I would replace a like count, with a button that auto tipped 1 sat or some other vanishingly inconsequential amount.

Easy for the client to resolve the receipts and give the author a like count if they want one for dopamine etc, but not really visible for others to see how many tips a note received.

I think this is a better way of doing it. Doesn’t mean anyone will implement that though.

monlovesmango 3y ago

but is something that you 'like' but don't have anything to say in response really promoting dialog and conversation? perhaps not having a like button will encourage previous lurkers to join the convo. I say this as someone who is mostly a lurker.