nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk 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/
Hey, do you remember Nstart? Now it can be used by any Nostr application, web or mobile, to offer an easy onboarding flow!
You can integrate it effortlessly via a simple redirect, modal or popup: in the end, the user is automagically logged into the app, without needing to touch their keys/bunker.
Jumble.social, nostr-login (and so every npub.pro website), nostr.band, flotilla.social, nosotros.app, whynostr.org are already using it, beg your favorite app to join the group!
https://chronicle.dtonon.com/5a55f1db7efdc2b19a09284c360909e7397316e67ea671e3e6eea35cc1c2dc3b.mp4
Check the integration manual:
https://github.com/dtonon/nstart/blob/master/APPS-INTEGRATION.md
A npm package is also available for the modal (suggested) version:
Looks perfect. I'll add it to my Nostr client (WIP/POC) as well, at https://pumpstr.localmachin.es/ . Thanks!
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.
Another BIG release day!
First Nostr client (proof of concept) with native BCH Pump! support getting close to release.
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s 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?
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.
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 nostr:npub1t6wuea28pq8wnv8wsg72w8wper0welt5xcx797j20av5xdk8lmss28tgk9 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.
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.
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 nostr:npub1t6wuea28pq8wnv8wsg72w8wper0welt5xcx797j20av5xdk8lmss28tgk9 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.
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s 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?
I've now added a button to set or clear the receive address independently of actually doing a transfer. Thank you for the feedback.
Kraken massively updated their multi chart views yesterday, good job!
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.
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.
!Thank you for giving it a try. Looks like you managed to withdraw as well. Thanks.
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.
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.