marius
Marius Kjeldahl

https://www.coinmachin.es/

Software developer. Currently building on Bitcoin Cash (BCH) & Nostr.

Public Key

npub19cdsv34mvqaccnltcey29qqawy6drz66we4d9wu8hafak0k2p3hsa0ukwr

NIP-05 Address

Profile Code

nprofile1qqszuxcxg6akqwuvfl4uvj9zsqwhzdx33dd8v6kjhwrm757m8m9qcmcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsp78jkt

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub19cdsv34mvqaccnltcey29qqawy6drz66we4d9wu8hafak0k2p3hsa0ukwr

Show more details

Last Notes

2026-03-08 12:13:03 UTC

- reply

Ny original ambition was to support tipping/payments similar to zapping, based on BCH. To try to get network effects going I first went with something that works with all Nostr clients. But that was necessarily custodial. Even a few vocal BCH community members did not like that. And maxis mislike most things that wants to challenge BTC or Lightning. Since my original work, a skilled BCH dev figured out the necessary details to allow payment to addresses generated based on raw Nostr hashes and keys, which makes it possible to support payments to all Nostr users, regardless of clients. That mostly leaves the issue of payments never getting picked up from non BCH users. Which can be solved with signalling from the Nostr profile or similar. So things are looking better. I tried looking up Nostr usage recently, but nostr.band or whatever had been down. Any new sites tracking Nostr pickup?

2026-03-08 11:57:58 UTC

- reply

I am not directly involved by I know about it from BCH dev communities. There is also other related work that makes Nostr based BCH payments even more viable. Now if only Nostr could grow faster then everyone - including me - would invest more into it. And of course the existing Nostr community with BTC maxis should stop treating Nostr like their own private thing. If they want it widely used.

2025-06-12 18:25:14 UTC

After getting praise from the scifi community, I tried watching "Invasion" AGAIN. Still sucks IMHO.
https://pumpstr.s3.eu-north-1.amazonaws.com/img/8704d06edb72e918464dc4fca7a15d09.png

2025-05-30 21:25:24 UTC

- reply

Pumps seem to work fine, feel free to use them again, with the normal caveats. But Nostr spam seems to have become more of an issue from last time. Seconds from me posting I got one recruitment spam and one regugitating bot posting senseless phrases from my own post. Oh well.

2025-05-30 21:20:25 UTC

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.

2025-05-21 20:47:19 UTC

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

2025-03-07 08:21:28 UTC

- reply

It's going great. I've recently added a "Relay Stats" view, which proves the new relay connection manager is doing it's job. Scrolling and navigation has received nice improvements. I'm slowly adding remaining features to make it a fully fledged Nostr client, like image/video uploads and likes. Once I have those in place I will start adding more real time features to highlight posts that are receiving pumps and likes (to help promote the ease of use). Suggestions are also welcome.

2025-02-20 10:19:05 UTC

As soon as remaining bugs from massive improvements to the Nostr client "Pumpstr" stabilizes (http://pumpstr.coinmachin.es/), 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!
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/45618b7d2fa523bad50c427aac56eed0d6206aac5f737e34fb55e410f7199b03.webp

2025-02-20 10:11:47 UTC

- reply

Thankfully, the payment address generation scheme is solid, so no sats get lost. Although it can feel like that when the confirmation modal fails to confirm the pump.

2025-02-20 10:08:08 UTC

- reply

I've done tons of work to make Pumpstr behave better towards relays and smarter connection pooling. When doing that I have turned off most/all "event caching", to make sure things behave like they should. I will re-enable event caching again soon, but then so that it only happens client side (not server side as before). Relay connection management in Nostr is not easy, so things are breaking while doing these changes. Additionally I'm doing work on the "feel" of the client (scrolling, persistant header etc) to make everything better. Progress is good, but some bugs will show up. Fixing everything asap though, usually within minutes from I notice anything. Thank you for your patience.

2025-02-20 10:00:15 UTC

- reply

Thanks, it registered (visible in my wallet), but feedback (and top list handling) is a bit buggy. I'm updating right now.

2025-02-19 19:34:50 UTC

- reply

Ha ha, true dat.

2025-02-19 19:02:42 UTC

https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/13436fc0103323be3f534de4f24023a5319906a3876e312488dea7bbd41c7c7f.webp

2025-02-18 17:25:23 UTC

- reply

Be the idealist, I'll be the realist. Apple is handicapping both PWAs and native apps on iOS (but to a lesser degree, since they are the gatekeeper for the native apps anyway). I suspect we both want full freedom on our own devices and the ability to deliver our software to anyone we want. So whatever disagreement we have is about current best choices considering what we have. I'll leave it at that.

2025-02-18 15:09:52 UTC

- reply

Unless you want to build a very niche mobile app, you typically need a presence on the web, on ios and on android. If possible, build a PWA to validate your concept (and distribution/network effects). Then iterate and build your native apps when you are sure you have a product market fit. There are many reasons to love native stuff, sure. But being a platform "purist" seldom makes sense business wise.

2025-02-18 14:42:14 UTC

https://i.postimg.cc/52RpSGn7/image.png

2025-02-18 13:05:43 UTC

- reply

Typical pattern is PWA first, then add native as your userbase and commercials allow the added overhead. Historical examples include Tinder, Uber, Pinterest, Flipcard, Amazon, Starbucks and many more. You can find more examples here:
https://laffaz.com/progressive-web-app-history-examples/
Now it's gotta be said as well that Mobile Safari has become what Internet Explorer used to be; the lowest common denominator that makes it VERY hard to make PWAs almost as polished as native apps.

2025-02-18 08:19:09 UTC

- reply

Btw, latest update went live yesterday. Pumps and wallet works fine, but the "top list" feature needs some more love to display user identities properly.

2025-02-17 22:54:28 UTC

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.

2025-02-17 20:27:28 UTC

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!

2025-02-10 21:30:16 UTC

- reply

One of the reply tags for this post is set to wss://echo.websocket.org/ . Any idea why (it's tagged as being created by Coracle..)?

2025-02-10 21:17:25 UTC

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

2025-02-08 01:03:58 UTC

Another test post.

2025-02-08 00:35:46 UTC

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. @npub1s02…s66n
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/7cf029abc36cfae8ef7d5c80f9e0f232746e4be095968f6368f9704e703dd722.webp

2025-02-07 21:10:41 UTC

- reply

Thanks for the pump @npub1s02…s66n . Cost me nearly an hour to figure out how my measly test pump of 1527 became 78753 sats bigger! Still much appreciated though.
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/10e3eb1066c9f6179867db69840bc6ec98a65b7c7a0c2f82c5093bbea33d6652.webp

2025-02-07 19:51:40 UTC

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.

2025-02-07 12:26:36 UTC

- reply

Posting and "quotes" works fine. The misquoted quotes is because I had to rescue the original post from a browser log after it failed the first time. And that quoted them which I forgot to clean up before trying to post again.

2025-02-07 12:25:13 UTC

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!

2025-02-07 12:23:19 UTC

Test posting from my own Nostr connection pool library.

2025-02-06 14:14:16 UTC

- reply

Fwiw, the I just pushed the new connection manager so things should be A LOT faster now and Pumpstr is a lot nicer to relays (avoiding unecessary reconnects).

2025-02-06 07:59:31 UTC

- reply

Hey thanks a bunch for giving it a spin again. I'm currently rewriting the relay connection manager to make everything even more solid before making another push for more usage. While there are a few open source tools for handling relays and connection pools (nostr-tools...), most of them behave poorly under pressure, and end the client end up fighting with the relays for stable connections. Stay tuned.

2025-02-05 14:28:57 UTC

- reply

Yes, I was doing something wrong. I had to write my own connection pool handler for relays, and while trying to mix and match that one with other nostr libraries some connections were not re-used correctly.

2025-02-05 13:21:10 UTC

- reply

Looks great (testing replies, nothing more to contribute). :)

2025-02-05 12:49:33 UTC

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.

2025-02-05 00:11:04 UTC

- reply

Yay, worked!

2025-02-05 00:08:16 UTC

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.

2025-02-04 19:26:01 UTC

- reply

.. now with proper e tag.

2025-02-04 19:24:09 UTC

First reply from the very same!

2025-02-04 19:23:48 UTC

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

2025-02-04 14:48:58 UTC

- reply

Use Javascript, and React (or even Vue, seems popular as well). Code everything server and client side in the same language, and you can even re-use code client- and server side (the infamous "common" folder). Then WHEN or IF you have enough success that scalability or a huge userbase makes it practical, then you can become a language snob and reimplement everything natively on whatever computer you are running on. javascript+node.js is good enough to move really fast and you can focus on building a userbase before becoming bogged down in learning a bunch of "not needed yet" stuff. You'll do better with flexible technology you know really well and can use everywhere rather than having to learn the "optimal choice" for every little sub-decision you need to make on your journey.

2025-02-02 11:50:40 UTC

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

2025-01-30 13:44:45 UTC

- reply

Chrome on Android doesn't like websockets without a full URL (Chrome on desktops, Safari and Mobile Safari accepts it). Fixed now. Thanks again.

2025-01-30 13:23:00 UTC

- reply

Thanks, will look into it asap. I've tested desktop and iOS/iPhone only lately (should have mentioned that). Sorry for the inconvenience.

2025-01-30 12:43:41 UTC

@npub1000…vwqk Happy to announce that Pumpstr https://pumpstr.coinmachin.es/ 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 https://pump.coinmachin.es/
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/9a774e8652439460e745c089c71a018e0f896ace6ae69548cac6b86cb26952ff.webp

2025-01-29 14:12:42 UTC

- reply

Looks perfect. I'll add it to my Nostr client (WIP/POC) as well, at https://pumpstr.localmachin.es/ . Thanks!

2025-01-27 12:29:22 UTC

- reply

Learn javascript first. Figure out which platforms you need to support. Do you need stricly native features and/or be tightly integrated with the phone OS? Then you probably need to look at native options for mobiles. If you need more "generic" support (both desktop and mobiles, and not a lot of tight integration with OS platform), learn javascript. Make websites, and PWAs if you need to deploy to phones and run offline. Then when you have an actual user base, then decide if you want to treat your users to that very optimized native polished look and feel. Native will always be better, but not always better enough to support the huge added investments needed for managing multiple native clients simulatenously.

2025-01-27 09:57:57 UTC

https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/2ad20ccfbaa9ca1ac828584ecfa2917b93e52d59c597eaf73df08377ca21f0c3.webp

2025-01-27 09:15:50 UTC

Another BIG release day!

2025-01-21 09:17:31 UTC

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

2025-01-18 13:26:03 UTC

- reply

I figured it out. It seems Damus doesn't update profile relay lists from kind 10002 events. When I added my relay specifically inside Damus everything works as expected.

2025-01-18 13:24:12 UTC

- reply

Never mind. Just learned that Damus doesn't seem to update/refresh relay lists from kind 10002 events. When I added the relay specifically inside Damus it works as expected. Weird.

2025-01-18 12:15:26 UTC

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 @npub1t6w…tgk9 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.

2025-01-17 23:17:52 UTC

@npub1xts…kk5s 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?

2025-01-16 09:18:44 UTC

- reply

I've now added a button to set or clear the receive address independently of actually doing a transfer. Thank you for the feedback.
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/d9e1cca2b14959ddd41bf4a2ae08108245599c8d6bcd9200d2399949e13d95a6.webp

2025-01-15 18:28:22 UTC

- reply

Agree, will fix. Thanks.

2025-01-15 09:54:21 UTC

Kraken massively updated their multi chart views yesterday, good job!
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/5da2f915ca7b4bf2e065dcc7790bd6b20ed64a61d066f8e24bbd3c0eca885612.webp

2025-01-15 09:07:09 UTC

- reply

Thanks. The idea is to be able to easily support coins and tokens besides the work already done with Nostr and Lightning. I'm working on client support as well to demonstrate that this can be just as elegant as existing zaps. And hopefully out of that I/we can write a NIP or two to add such generic support (and simple recipe for Nostr client devs to support anything which follows a similar protocol). The pump stuff already tries to post "pump" reciept events similar to Lightning receipts, but until clients knows about them they will remain hidden. That's why I also am testing with direct replies containing pump details. But to my defence, those replies have auto expiry set to avoid polluting threads forever.

2025-01-14 19:51:08 UTC

- reply

Correct, that's the gross amount. To get net you need to deduct the transaction fee. Jokes aside, point taken, I'll stop pumping your posts. Best of luck with Notedeck etc.

2025-01-14 19:40:10 UTC

- reply

Pumped with 3422 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qraaqeypldwlcuz4eg0p5eh65fkgfcpv4ckur80f2f).

2025-01-14 16:53:45 UTC

- reply

Thank you for giving it a try. Looks like you managed to withdraw as well. Thanks.

2025-01-14 15:15:13 UTC

- reply

Pumped with 1145 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qpxqv9vjyhc9lvhlq2p9np538mygte8aw5k7zsaj6n).

2025-01-14 15:08:24 UTC

- reply

Press the "Wallet" link top right, log in with your Nostr pubkey, enter a BCH receive address, press Transfer, and you will get free money. I'm building "BCH zaps", but client integration is still on the drawing board, so it's a bit chatty right now. But the automated messages notifying you of payment have expiry times so the will self destruct.
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/0e00ddecd1153050dbdef3eb81572cf2abceefcefc3217f6b547425b4076315c.webp

2025-01-14 14:00:38 UTC

- reply

Pumped with 1145 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qprz6la5waz2p530e3qttz6zm0d76p0fmsy5f6qdr2).

2025-01-14 12:58:00 UTC

- reply

California and Norway, BFF.

2025-01-13 19:59:49 UTC

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).

2025-01-13 19:10:44 UTC

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.

2025-01-10 12:10:17 UTC

- reply

Yes definitively. That would be most useful for a whole slew of new kind of services supporting Nostr and related ecosystems.

2025-01-10 10:09:30 UTC

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.
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/8026b97fe80707292bd453eb924d122c1a81dca9483e49b356dea677ed2f5016.webp

2025-01-07 12:24:55 UTC

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? https://pump.coinmachin.es/top

2025-01-04 16:52:33 UTC

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.

2025-01-04 06:25:29 UTC

- reply

Pumped with 1043 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qzvfwm3flyyppvlszk4hydjkw5yq03ud9crkk93fyu)

2025-01-04 06:24:19 UTC

- reply

Pumped with 1043 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qz8z702vh7r69zxfqp8z9ze7hkgz2frc7y6taztndu)

2025-01-04 06:11:09 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qzypz4hrgm9d53xnf6xx8ac9ra72n9kety7c7wncvt)

2025-01-04 06:08:45 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qr6xux8ha3fwc4raczxzh6e9kkrgxkjrhsf9mq5xqc)

2025-01-04 06:07:51 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qpu0edzfhyjv7quy45jmcm74dp4nxtt7my95qunsxe)

2025-01-04 06:06:46 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qzqfawwgajx8enhlv5p7yfkhr28uwjj0rqclzp02n5)

2025-01-04 06:05:33 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qpanp78krgyrl57ln7k3pkhwveck2crc2ye2nxn778)

2025-01-03 22:54:50 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qr9dntx4sgkmjm95qcaz9zu48z0jl4kxeqkl88g2hm)

2025-01-03 22:49:00 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qr9dntx4sgkmjm95qcaz9zu48z0jl4kxeqkl88g2hm)

2025-01-03 22:38:48 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qrpww6sf0rk0z3pff80tr56phh8wdzv5jvkl7wrv4t)

2025-01-03 22:38:09 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qrpww6sf0rk0z3pff80tr56phh8wdzv5jvkl7wrv4t)

2025-01-03 22:36:42 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qrpww6sf0rk0z3pff80tr56phh8wdzv5jvkl7wrv4t)

2025-01-03 22:35:27 UTC

- reply

Pumped with 1000 sats BCH, see https://pump.coinmachin.es/ (bitcoincash:qrpww6sf0rk0z3pff80tr56phh8wdzv5jvkl7wrv4t)

2025-01-03 22:33:04 UTC

- reply

Pumped with 1000 sats BCH: bitcoincash:qrpww6sf0rk0z3pff80tr56phh8wdzv5jvkl7wrv4t (https://pump.coinmachin.es/)

2025-01-01 17:58:58 UTC

- reply

Pumped with 112963 sats BCH: bitcoincash:qph086ar4wet5a4jfy9kcwng9q7wqfnz6yqzqulpex

2025-01-01 13:05:10 UTC

- reply

Pumped with 1142 sats BCH: bitcoincash:qrpww6sf0rk0z3pff80tr56phh8wdzv5jvkl7wrv4t

2024-12-18 11:39:52 UTC

Here's a BCH wallet running in my car. Tesla really should do more to encourage in-car software building.
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/ef4b1b21d142e490a0420af2cf9939739fe403aa241389693b71a826ce216be7.webp

2024-12-17 19:28:13 UTC

I've been taking a casual look at Nostr npub keys. I'm finding an unexpected number of public keys leading with zeros (after examining only a few thousand). Assuming these are derived from proper public keys using proper hashing algorithms, I would not expect that. Either I'm missing something, or quite a few people are generating npub keys inproperly.

2024-12-15 21:20:45 UTC

So the browser on Teslas used to have "Tesla" in the user agent string. I just tested on mine. It does not any longer. Anyone know of methods to recognize when running on the screen inside Teslas? I've got a few apps that could use a larger font size for instance, and I don't want to screw around with people using KHTML etc on Linux computers.
https://cdn.nostrcheck.me/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/7f7a67cae266fe0be86ade1708afb9d94fec72b72f4c3db2eec30eadc840eb88.webp

2024-12-09 19:43:59 UTC

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?

2024-11-30 00:55:55 UTC

- reply

Sorry I responded to the wrong message. I believe you are right, the new stuff isn’t available on the web client.

2024-11-30 00:52:22 UTC

- reply

It is a progressive web app, runs both on the web and is installable. Non custodial, stores everything on device only. Needs a bit more work before I can release it publically. Hopefully soon.

2024-11-29 23:00:32 UTC

So I'm thinking of doing the unspeakable. Adding support for layer 1 zapping to Nostr using BCH. Hate me gently.
https://nostrcheck.me/media/2e1b0646bb603b8c4febc648a2801d7134d18b5a766ad2bb87bf53db3eca0c6f/3ca126a98b3435f91ab856b490263c52dcd7fd91e3e491e9f0a5fe7292bcf257.webp

2024-11-23 10:03:12 UTC

- reply

Good job. Out of curiosity, what's your cross platform stack/core tech?

2024-11-21 17:54:19 UTC

- reply

This is native app only, right? Can't see it on the web..

2024-11-13 08:36:25 UTC

- reply

Bitcoin/BTC are typically maximalists and can be a bit of a cult and easily offended. Hopefully Nostr can grow beyond that.

2024-10-19 11:15:15 UTC

- reply

Depending on how much "hardware" you actually need to test, the iOS simulator running on the same machine is probably the easiest.

2024-10-19 00:03:15 UTC

So what's the state of the art for testing PWAs using websockets on iOS devices on a local network these days, preferrably something with automated certificate generation (assuming wss is required)? Or should I still proxy everything from a live public server (with valid certs)?