Just saying, 8 out of 10 messages I receive from people who aren’t in my contacts are still NIP-04. Even some folks who run Haven and should know better mostly still default to NIP-04. I’m still trying to educate people about NIP-17, and even after they understand it, they usually only DM me using NIP-17 it if their client happens to support it. Which also means most NIP-17 messages I send back end up in limbo. Support for NIP-04 was removed from the official Haven build about a year ago. My personal fork still has a flag to re-enable it, which I keep telling myself I’ll disable someday. I don’t have a strong opinion either way. I do want the ecosystem to move towards NIP-17... Disabling NIP-04 on Amethyst might be what finally pushes other client developers to support NIP-17, and that could be a good thing for Nostr. On the other hand… yes, people are still using NIP-04... Like, a lot...

It is a good note... And you asked for #startrekstr after all... Maybe post more startrekstr and Amethyst wishes shall be done :)

100% agreed. Statistically, AI is trained on social media posts and the garbage throw away exercise / practice code in personal GitHub repos. Meanwhile, good specs and code (i.e. most things of proper size, with, for example, a complex domain and a rich DDD model, Hexagonal Architecture from well-crafted specs, a proper test pyramid, good CI/CD practices, observability, etc.) are the exception. Examples that are often locked away in private repos or scattered across books and rare content that make up, what, than 0.00001% of the datasets these models are trained on. Good specs and code are basically irrelevant compared to all of the social media posts and horrible code the models ingest. I don’t get why people are even surprised by specs full of emojis, agents publishing PII to public S3 buckets and deleting tests when asked to fix something. This is exactly how I’d expect models to behave given the training data they’ve been fed.

GM Zed, great sketch today :)

This one is already pretty "mainstream", or as close to it as a CLI transfer tool generally gets (almost 32k stars on GitHub; I’m not sure the whole Nostr ecosystem combined gets that much attention). But fair point regardless, especially for folks using public relays. Just like in Nostr, sending some money to public relay runners (like , , , , etc.) is a good way to keep their respective public relays alive. Likewise, sending some $$ to FOSS developers is the best way to guarantee they actually get some development time. This is something that folks (even those who say they’re all about "value for value" like here on Nostr) are really bad at. If only users knew how expensive it is to develop and run this sort of thing, they’d probably pool together an annual budget to split among the FOSS devs building the tools they rely on.

GM Nostr! Here’s my FOSS tool recommendation of the day: https://github.com/schollz/croc Croc is my CLI file transfer tool of choice for many reasons: 1. Simple and intuitive enough to pass the "Anthony didn’t use it in 3 months and can still get it working first time" test. 2. Fully end-to-end encrypted, with configurable curves and sane defaults. 3. Works on all OSes and CPU architectures I run (it’s written in Go with CGO disabled 😉). 4. Works flawlessly on IPv6-only networks (kudos for not needing any workarounds). 5. Works over Tor. 6. Lets me run my own relay for those times when IPv4 and NAT are unavoidable. 7. Passes the "people I trust and most likely know what they’re doing looked at the code + network traffic and think it’s safe" test. I was introduced to this tool by a security researcher friend after he saw me struggling with my pre-croc WireGuard VPN + SCP dance to upload a file. #GM #FOSS #CLItools #FileTransfer #SelfHosting #Privacy #Encryption #Networking #GoLang

GM Zed!

As much as I’d like to say this is a conspiracy, Google gives zero F’s about GitHub. And I don't think Prime moderators would manually exclude this comment either. YouTube is allergic to all links (and most content) nowadays. Their UI even pretends it accepted your comment when you post it, so you never know. I don’t comment on YouTube anymore unless I really have no choice.

https://youtu.be/1mC1OyVoETY Not to be a corporate shill (I'm a paying customer and have zero affiliation with – or, as Trump would put it, I have an extreme trade deficit with Kagi 😂), but this is sooo, sooo good. Some of my clients work in very restricted environments, so I can’t just install qutebrowser or even Vim-like browser extensions. The Kagi website just works how I expect (well, until I forget that I'm not on vim and try some more esoteric commands). I wish all websites had vim-like keyboard shortcuts built in. IMO, Kagi is worth the price tag for the small things… shortcuts, domain boosting and blocking, agents that actually call Kagi’s search tools (even with models that aren’t exactly known for being tool-friendly), Lenses, the best (and I mean it) translation tool out there, etc, etc, etc. Don’t get me wrong, their search results are also pretty good (and this is coming from someone who runs their own SearXNG instances with all sorts of customisations), but search functionality is just the Trojan horse that gets you to try it. You end up staying for everything else. #kagi #search #vim #shortcuts #yesItIsWorthIt #BuildOrBuyIt #OtherwiseYouAreTheProduct

Aye. I think it is worth to investigate these slops in performanfe though, it happens a bit frequently. (I'm on a 2.5 Gbps fiber optic link). I'll ping you again if it slows down once more.

Thanks for your service Dan. Out of curiosity, how's the relay / Blossom side of things going. Have you migrated to nostrlib already?

No, it had been relatively fast since the last update. And today it is back to the usual 5 to 10 seconds. At the moment the longest wait time is in the "blinking" screen with 0 sats, until the transactions load. Yesterday I think it was the "Connecting to Spark" screen but all 3 of them were taking a while.

That sends Nancy Pelosi’s record insider trading levels back to the amateur division... Impressive.

Just timed it, almost two minutes for me at the moment.

Interesting; likely a networking (or load) issue within Europe, then. For me, it's taking almost a minute on the initial screen that says "Don't close the app," then "Connecting to Spark," and then a long time on a screen that says I have zero SATs until it finally loads my balance and transactions. Sending zaps is also taking a while after confirming. Ping is over 600ms here as well. WoS is working well so I don't think the problem is the Spark layer.

, is Blitz working well for you at the moment?

, zapping is really slow again. Even loading the app is taking a long time.

Sou mão de vaca sim e não nego. Não pago um sat que seja para mover uma moeda do meu bolso esquerdo para o direito (não faz sentido). Sim, para quem usa clients web NWC facilita. Vamos ver. Concordo que eles eles estão fazendo um bom trabalho e Spark vem me surpreeendendo.

The British Musuem is an interesting experience. I went like 20 times already and I can always have a good time and find something that I've missed before. Enjoy!