Thanks. It used to work for Actix v1-3, it’s just been broken in v4 as being supported.

I looked at rocket as an alternative.. so at least I get to learn a few more rust libraries.. was just hoping for it to take two hours.. not likely a couple days effort.

I have 12 month activity view work, but it’s got some issues. I can’t adjust the zoom, and it takes up 70% of the screen width at normal browser zoom. Grafana is great, but it’s becoming painful for this project.

Ultimately if there is enough interest in this stuff, and I can fund the effort, I’ll migrate toward a custom build for the dashboard/charts - which is the best long term play anyway.

NostrGraph Dashboard now has a trending view. I try not to filter anything but spam/flooding, but certainly some words/hashtags are boosted by non-human posts (like #torrent).

https://nostrgraph.net/dashboard/trending

.... --- .-- / -.. --- / -.-- --- ..- / .--. .-. --- -. --- ..- -. -.-. . / -. --- ... - .-. ..--..

Would you like the long answer? Basically there are lots of considerations - but it starts with do you intend to relay the events as per NIP-01, and secondarily what processing or data querying are you performing.

Do you need to reply with signed events?

Can a person react twice?

Can a person react twice, but with different reactions?

Can your processing see the same event twice?

Can someone delete a reaction?

If you identify a spammer of fake reactions, if you’ve compressed the data, can you filter them out now - or impossible?

Fair few more cases to consider in addition to those as well. Decentralisation is complex. Blockchains don’t fix almost any decentralised problem.. so some areas are new and unsolved CS (or un-applied.. we have solutions that haven’t been battle tested yet).

I think when we have faster non-custodial wallet zapping that’s easier than today, that doesn’t require time/effort flipping between apps, and has a concept of budgeting or clear expenditure, it will be in a good place to grow the number of zaps.

Otherwise it kind of depends if it’s actually valuable to 90% of people, or too smaller amounts and too few to care about. A zap worth $0.01 or less is effectively no different to a like. And unless you’re getting 10,000+ zaps, it’s not going to significantly impact most people’s lives - or they send zaps out and it’s a zero sum anyway.

If you take out the three big zaps I’ve received, the mean value halves. Not saying I’m a model account either.

Obviously if BTC 10X at least one more time the economics change.

Behind the scenes this is all limited by the amount of attention in the world that can be spread across the Nostr network, and how much engagement most people can expect to get. If people don’t have time to see it (discoverability) and read it, they certainly can’t zap it.

nostr:note10g0w6e07zdepelr402v3avf4ghf8hjfrnzgyurnc7uk5pn2arl0spa33l3

NostrGraph 7 day reactions (less than 4 chars).

For databases, reactions are actually not amazing. For a single character (ignore UTF8), it’s basically 500 characters in event JSON.

You can certainly extract the reaction, and even use something like hyperloglog to compress that way down - and even using the reaction event creator local DB id, and then you can delete the reaction, but avoid double counting too. However, you then can’t broadcast, search or prove that reaction after deletion. Maybe that doesn’t matter.

We’ll either get better at handling data and processing for stuff like this, or it will have to change anyway, as relays won’t be able to host all the data in its current form - even for a 30 day period.

Another approach that could be used: when reacting, drop the p tag referencing the event pubkey, if that pubkey has signalled they don’t want or care for reactions.

Doesn’t break other users experiences or expectations.

I still think if you don’t want to see reactions, literally just don’t query for kind 7. Client side 100%.

The only UX part that’s unclear is how does someone else know that this pubkey prefers to be paid instead of having reactions. Well, everyone would prefer to be paid (or remove lud).. so that kind of kills that issue.

I support the experiment, just not so set on the hard cut enforcement. And I think it’s not likely going to play out long term.. even messenger apps all just added standardised tapback reactions - unless all chat apps remove it, you’re breaking people’s habits and desired way to communicate.

Same. Often writing it down makes me remember anyway. Then I cross stuff off when I trawl through.

I’d like a hash addressable content approach if we can find a solid approach. Swapping out referenced content, without easily being identified as changed/different, isn’t a property we should build toward.

TestFlight users can install older builds.

Using hyperloglogs?

Basically it allows your application to know when a BTCPay invoice was created, expired or settled/paid.

Then you can update your database or whatever, like assign that NIP05.

Will likely co-release the trending words and hashtags too.

Got this working for NostrGraph. Can try different queries too. Unreleased on dashboards, but maybe over the weekend.

I can’t speak personally to being upset that you can’t react to some people. You can react in other apps, that person likely just won’t see it.

I kind of see the new Damus approach as being like “comments are disabled for this video” on YouTube - but for reactions. I get an author may not want to deal with controversial comments below their content. Or even the time to read them - however other people will.

I guess being able to react, vs having it removed from other peoples app, experience is the key frustration.

Should any content be free from being able to respond to in an open web? Should a Nostrpedia page about abortion be able to be locked or reject replies/comments/whatever?

It’s complex, hard, and probably always a gray area.

Well it’s a network limit. Any more than 1,200 and relays start rejecting your contact list and you get weird results.

I would considering staying below 1,000, and ideally using other list features which should be coming soon to apps.

Sure, but that comes at a cost.

Say 10 people now reply with 🤙 instead of a the reaction. You can’t easily summarise that (like reactions do). Did they really ‘reply’ when using a 🤙, or really did they really just gesture?

Does this mean my notifications now need filtering of ‘reactions as replies’? Do I need to look at each reply or 🤙, as an individual response?

I’d wager more toward this being a per client app query/display setting for an account, as opposed to a global ‘don’t send me reactions’ preference. Without wide adoption anyway, you’ll still receive reactions - which you can just skip querying for kind 7 in your favourite apps.

I’m writing a BTCPay webhook in Rust. Let me know if you’d find it useful and I can likely open source it.

I spent 4 hours yesterday trying to get Actix web to accept a middleware that can read the HTTP body content - as it’s required to do a header hmac checksum before processing the request further. Complete failure and going to use another library instead. Bit frustrating.

NB. I know hashish way to make it work, but it’s inefficient and I don’t like the approach.

All setup.