After getting praise from the scifi community, I tried watching "Invasion" AGAIN. Still sucks IMHO.

New version of Pumpstr is out (pumpstr.coinmachin.es), a massive upgrade, please try to hold off pumping until I can verify everything is ok: RELEASE NOTES 2025-05-30 Previously a lot of content was handled server side. This fits poorly with how Nostr was meant to be. So Pumpstr have received massive improvements where it now behaves like a "proper" client app, running inside the browser as a PWA (progressive web app). This means the server is mostly there to allow clients to download the app. All content caching (user profiles and events) is now also done client side only. I added a "Relay Stats" choice in the sidebar which will show you stats and connection status for your relays. This can be useful to find and remove non-functional relays from your relay list. I added a "Storage Stats" choice in the sidebar which shows you the number of user profiles and events being cached in the client. The client will auto refresh client profiles every hour. The initial feeds list always get built with live data from relays, but mentioned events (like for replies and reposts) will get persisted to speed up post rendering. Eventually the client will do automatic cleanups to avoid profiles and events piling up endlessly, typically by removing unused profiles and events after a week or two. If you hide this message by clicking the X icon, you can get it back by selecting "Show sys.msg" from the sidebar.

Testing post-refactoring pumps (again), please leave this post alone.

As soon as remaining bugs from massive improvements to the Nostr client "Pumpstr" stabilizes (

Pump! Nostr "zaps" using BCH

I need to re-introduce mechanisms to share pump actions. Promoting these for Pumpstr users is one thing, but to gain traction there needs to be ways for non-Pumpstr users to see that sats are flying as well. Suggestions are welcome! Sharing a screenshot from "threaded view" with new app header on iOS/iPhone, just because!

As a developer, getting started writing a Nostr client can be a bit challenging. Nostr is supposed to be decentralized, connecting to whatever relays the user specifies. Weirdly enough, the user preferred relay lists lives on other relays. Which ones? You don't know. So even as Nostr users are supposed to maintain their own lists of preferred relays, a Nostr client app still needs to have some kind of dynamic/hardcoded list of relays to get that user preferred relay list. In addition, whatever list you start with, lists are dynamic. They come and go. Which means both as a Nostr developer and as a Nostr user, you need to do some upkeep to keep everything working properly over time. This is one area where Nostr could definitively improve. For all parties involved.

So another rewrite of the relay connection manager for Pumpstr and making the client work more independently of the server in preparation for a downloadable app. Not live yet, but soon!

Anybody want to clue me in on why some Nostr posts have a "root" tag for a reply set to wss://echo.websocket.org ? I assume that's just an "echo server", not a valid Nostr relay. Check out this kind 1 event for instance: 6ee27976f9f38c6cac6a2fd3a3889a4cf532ce8471c35d0a2077698ad810314d

Another test post.

What are the odds? I was just debugging some poor state management leading to pumps being accumulated wrongly. And simulatenously users start pumping the very post I used for a small test pump. Debugging a live service can be challenging. Still appreciated though. @Crypto Is Cash - Bitcoin for Small Businesses & Their Customers

From "Flowee" / Tom on X: Today we talked about what our metrics of success are for Bitcoin Cash. The first observation is that most websites graph the price. This, to most is the beginning and end of it. But that is largely irrelevant for a peer to peer cash. Lets look with transaction volume. Can't claim to have a lot of usage if you have no transactions. Using the excellent 3xpl we can see that: Bitcoin Cash has about 2½ times the volume of Monero. Bitcoin Cash has about half the volume of Litecoin. Bitcoin Cash has about a quarter of the volume of BTC. Mind you, we don't really know how much of that BTC volume is Ordinals. And to complete the payment coins comparison: we have about 10x the volume of Dash. Bitcoin Cash does roughly every day 100.000 transactions. With every other day peaking at half a million transactions. With 2 million tx/day peaks too. For a world wide peer to peer cash, I would argue this is pretty good. Frankly, the volumes are amazingly stable year over year. Growth would be nice, but the most important part is that 100k tx/day is clearly showing a lot of interest. People are using this. It has been hard to find graphs on actual transaction volume, everyone is focusing on price. Historical price charts are everywhere. We are really in the time of traders and betting. And that distorts the entire industry. Focusing on our strengths may be something we need to repeat more often.

When writing Nostr clients, working with relays are \"challenging\" to say the least. There is little information stating exactly how it \"should\" be done. A lot of relays are misbehaving, or at least are punishing people messing up their own clients. Relays might accept connections, but not react to anything. Or they might react but with usage limits (connections and/or a limit on the number of simultaneous pending requests). When a traditional (\"X style\") Nostr client starts up, there is a lot of things to be done. You need to fetch user metadata on the currently logged in user, including some profile data, followers list, relay list and similar. Then you need to connect to the relays and ask for historical posts (nobody wants a blank feed). So you connect to each relay in the user relay list and they will throw events at your like there is no tomorrow. At least the ones that bother to reply. So now you have lots of events. Guess what you now need to do? For each one of these, you need to get the user metadata for the poster (people want to see who is posting). If it's a repost, you might want to fetch the original post as well (there's a couple of different ways Nostr handles this). And if it's a reply, you might want to show that it is a reply (and to which user and which post). Yeah, more requests to relays. So with your recently populated list of historical posts, you know have lots of queries to the relays to fill in the missing pieces for each post (at least for reposts and replies). So you start hitting the relays again. So this is where you need a relay connection pool manager. You want to avoid reconnecting to all the relays for each query/subscription, because this takes time, and relays do not appreciate you eating all their sockets. Fine, just send them over the same connection then. Well, the relays don't like too many pending requests/subscriptions either. So if you hit some magical number - typically 10 - the relays will start rate limiting you, and not accepting new queries. And keep in mind relays might have different \"politics\" on how to handle this. For my own client - Pumpstr - I initially tried to use the pool manager that comes with nostr-utils. It's a great resource, but the pool manager does not really work for clients. It works great as a starting point to learn about Nostr, but you can not rely on this when writing a \"full\" Nostr client. It's just too primitive. It really does not have the concept of \"subscriptions\" versus \"relay connections\", and when closing a subscription it will typically also kill your relay connections. Good like trying to writing a well behaved Nostr client with that. So I rabbit holed this deeply (as usual), and rewrote my own Nostr connection pool manager. It now tracks the number of pending queries/subscriptions on a per relay basis, and connections are independent from subscriptions. When a relay disconnects you - they will periodically - it also automatically resubscribes to existing subscriptions. It might not be perfect just yet, but it is getting pretty damned close!

Test posting from my own Nostr connection pool library.

Not sure if I'm doing anything wrong or not when talking to Nostr relays. But when I try to look up "replies" (kind 1&6, combined with an "e tag" search), it consistently takes around 4 seconds or longer. Sure, I can "cache" anything, but hammering relays for caching a "start view" of some 50 Nostr posts and all their replies also doesn't seem very nice.

I now have a Nostr client running, Pumpstr, that supports reading, replying and reposting. Let's see if pumps are still working (I will try to pump this post). If so, another nice set of features would be to display aggregated likes and reposts, in addition to pumps. Looks like many clients do not do this until a post is selected, so it may be a bit heavy on the relays for the "all posts" view. Time will show.

First reply from the very same!

First post from my very own Pumpstr, a Nostr client with integrated BCH pumps!

Anybody knows why picture in picture mode on Chrome on Mac does NOT display in ALL desktop/workspaces? On Safari it does.