Thanks for continuing to share high quality links. It’s like a personal hackernews or slashdot on Nostr.
Yep. I was confused what happened to it.
Single one of payments are great - but they are not businesses. Business have recurring costs and need recurring income.
If we want lightning (and perhaps Nostr) to drive Bitcoin adoption and business to thrive, we need subscriptions. And Nostr is the perfect place to start adopting them in the wild.
Side note, without subscriptions you typically get huge drop off rates - basically business churn. I don’t want the business to control your finances or decisions (stop paying whenever) - but literally people forgetting to pay something monthly (if the only option) kills businesses.
If I was better across lightning, I would be focusing on subscriptions as number one priority - especially simple client app/wallet UX.
I use inbox and outbox terminology in my code. There can be additional logic that wraps before or after. Publish and query could also work perhaps.
Basically it’s a middleware pattern - which I think makes the most sense long term.
Still have a dumb pool of relays you keep connected to, however you can still connect to a relay on demand (e.g a DM in outbox could run a function to pick which relays to attempt publishing to).
You then need to consider failures to send, or outages, or some M/N OK result threshold to keep trying until that’s happy.
And if your eager in a client app, you could self-throttle push listing events - however you shouldn’t really hit limits as a human.
Maybe we can start with Nostr Client App anti-patterns.
Nostr client app Anti-patterns
* Updating a subscription too often (triggers new SQL queries)
* Connecting to a relay multiple times (use a single websocket)
* How can we best manage this with multiple open web app tabs?
* Opening a websocket and not creating at least one subscription
* If you disconnect from a relay, don't instantly reconnect (add random wait)
* Gracefully disconnect (helps servers free descriptors faster for new connections)
* Overlapping subscription queries (you'll get dupe data - from each relay)
* Using Until and updating the subscription's until every x seconds/minutes (if you didn't use until and just used client logic to show events, you wouldn't trigger a server query and just stream the data instead)
* Using the same relay list for home feeds, global, general queries, DMs, notifications, etc
#[0] has been trying to communicate this for some time now 🙂
Client apps need smarter “which relay” algos for inbound and outbound.
#[1]
I think of Zaps like a small transactional account. It doesn’t need to be tied to any private financial infrastructure.
It’s just a petty cash account that sometimes goes up and sometimes goes down. May need a top up or withdrawal from time to time.
Maybe if we see more serious transfers with significant amounts, we may need better self-managed approaches to minimise risk/trust.
And even things like past 7 days is free to access for stats. I agree, definitely room to create product tiers.
Yep. Download archives and relay recommendations are a couple of things I’m hoping to keep open. My archive bot is likely broken until I have time. https://nostrgraph.net/archive
I’m doing my best to support the network and it’s growth - but it needs sustainable businesses, or Nostr will have long term issues.
I think lightning is a key to its success - lightning enables what wasn’t possible before - it’s the killer partnership.
NostrGraph. Mix of relay and relay aggregation. 13MM events deduped and spam removed - but has stale contact/meta records too.
Some stats I’m reprocessing and making sure it’s all accurate - like followers, etc.
It’s a grafana dashboard for the prototype, backed by a relay and relay aggregation service which are custom. Mostly validating my data and getting a sense of what it can do.
The issue is I can’t see it being valuable unless you are a big relay or an aggregator - you will be missing so much data. And both of those are hard - my dev work has become gaps while loading large batch DB queries for processing and dropping spam, investigation, etc 😐.
If there’s enough value in it, I’d like to commercialise it, bundled with other services too. Once I get the scale of data more under control, I’ll look to build a front end.
It’s a product I’m building slowly. Basically a personal (or account based) Nostr Dashboard.
Yours below.
Yep. I understand the technique.
I was wondering when and how you’ve been using it specifically? For payment page pending payment confirmation -> confirmed?
Nope. It’s a little hard to read the selected filter: it’s the most white text - it’s nostr.fediverse.jp.
Nos.lol just has the most unique inbound events at present 🎁
And we can also see reposts are higher too.. but to a lesser degree.
Detecting is easier than blocking for these Nostr kinds today.. unfortunately.
Anatomy of a real-time Nostr (flood) spam attack.
Reactions count seems high.. ok, which relay(s) also has a spike? Found it.
Here we can clearly see the spike in volume and identify it’s coming from a specific relay - and the volume matches too.
Ignore my dupe relay record ;)
