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

@daniele Happy to announce that Pumpstr

Pump! Nostr "zaps" using BCH

is using Nstart for the signup flow. Works great both on desktop and mobile, thanks! One thing for the wishlist; the ability to select a bit smaller fonts (yeah, it's a preference I guess). Pumpstr is not a fully fledged Nostr client yet though (can only view, and more importantly, pump!), but getting there. More info at

Pump! Nostr "zaps" using BCH

Another BIG release day!

First Nostr client (proof of concept) with native BCH Pump! support getting close to release.

I'm trying to figure out if the Nostr Damus client is simply misbehaving, if I am doing anything wrong or if Damus is actively blocking posts from the Pump service I'm working on. If anyone is using Damus and at least one more Nostr client, could you check out this profile @Pump! Zap with BCH and see if it has posts more recent than January 6th or not? It does not have to be anything malicious, could very well be "poor caching" or myself doing something wrong. But in all other Nostr clients I am testing in I am able to get more recent content from the Pump account than in Damus.

@jb55 Either Damus is acting up and not retrieving notes, or it's not respecting my relays, or something more nefarious is happening (could be mistaken as client side blocking). Primal and web based clients are not having any issues. Any comment?

Kraken massively updated their multi chart views yesterday, good job!

One thing Nostr does massively better than X already is clicking on replies, where you're taken to the reply in context (the message being replied to). Instead of the bullshit X currenlty does (taking you to the reply and its replies).

When writing my first Nostr apps I had recurring issues with notes disappearing and user metadata and profiles not being up to date. It took a while, but eventually I figured out how relays work, and how it's tied together with user profiles and other events containing relevant data (preferred relays etc). I'm still not sure what the "ideal" way to retrieve initial user data etc is. Which relays do I query? Do I actually have to implement a "Nostr crawler" that continuously monitor events to detect relays, and asking relays more or less at random for data that I have been unable to retrieve? Besides the relay issue, which can be solved by some more or less hardcoded list of popular relays, most things are working great now. I typically cache events when found. Events that can be "renewed" I periodically try to refresh (pubkey+kind), but client never have to wait. When clients retrieve something that can theoretically be updated, I return the last known value. But if some value haven't been tried to be re-fetched in a while, I put it in a queue to be re-acquired by another "worker" process. So clients will never have to wait for anything to be fetched from relays, unless it's something that has never been seen before of course. There's no manual for how this works AFAIK, so there are many pieces to work out by yourself. You need some ability and lots of curiosity IMHO.

I'm going to pump some semi-random Nostr posts soon. This will use real small amounts of BCH which receiver can withdraw at will. Each pump should generate a reply from the pumper, indicating the amount (expires after 5 minutes). And a reply from the pump service giving total post pump statistics (expires after an hour). The replies are useful to see engagement until there are clients supporting pumps.

Are there any statistics on Nostr client popularity? I'm primarly interested in the open source web based ones for now, as I need to start adding client support for "Pump!" (Zap using BCH). I'm also thinking about maybe doing a plugin first instead. Opinions?

Pump! Nostr "zaps" using BCH

Apologies in advance for all the test reply messages related to me testing "zaps" using BCH. I'm also experimenting with various expiration settings etc to get everything cleaned up by default. Until I get some rudimentary client support for this I need these messages to make everything working correctly.

What do I need to do to get a "BCH payment receipt" "kind type", similar to kind 9735 "zap receipt"? Assuming I need to demonstrate working code and/or write a complete NIP first, any suggestions on what "kind" to use while testing?

So I'm thinking of doing the unspeakable. Adding support for layer 1 zapping to Nostr using BCH. Hate me gently.