I’m curious about the cold water immersion technique that is used for physical and mental health. In particular I see all these videos of people getting in lakes with ice on the surface or in bathtubs full of ice and liquid water. Nearly freezing water, so around 1c to 2c. That’s really cold. I have gone swimming in water that cold, I’m not a fan.
So how long should we be in cold water and how cold should it be? Turns out it’s longer and warmer than i thought.
According to this research review the water should be 10c to 15c and immersion should last 11 to 15 minutes.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4802003/
Even wirh that knowledge it doesn’t make me want to go swimming right now.
Here in the Netherlands we have a cold water celebrity. Dives and rests in ice cold water, there’s a whole cult around him.
He happens to have an identical twin brother. (from same egg).
That brother lives an average life with just warm showers. Both are examined and the doctors could not discern a single shroud of difference between the healths of both brothers …
Yess! #Bitcoin Focus, the first Bitcoin magazine in the Netherlands, just sent out Issue 00, the first of their beautiful glossy. (in Dutch).
Good work, frens!🫶🏽 
The Zap option via the noscript at suhailsaqan.com is of course a welcome workaround to be able to keep zapping with #Damus on Apple's iOS.
BUT it still involves a complete context switch. Color me spoiled, but that fact alone (the context switch ) decimates the number of zaps I will zap per day. That 3 second context switch is just a little too annoying, kicks me out of the Nostr flow...
What I really would like, @jb55.com , is that the whole Zap procedure is handled whithin the real estate of a small MODAL DIALOG on top of the Damus screen. NO switch to a Lightning app, but just the small dialog. Maybe only possible when one is running one's own node, but that's no problem. Behind the dialog I'd still see the post I'm zapping to.
Another idea/wish I have is: make the Zap button 'programmable': via Settings the user can paste an URL (so its nothing more than a bookmark, from the viewpoint of Apple censors) and the URL fires the zap*, the result shown in a dialog. (Like the XMLHttpRequest of ol')
(*)The Zap button could be presented as a multi purpose programmable button. For example, another use of it would be to Tweet or save the current note. Just paste another URL.
I tried to use #Alby #getalby on Firefox for Mac in order to login via Coracle. But this is just TOO much hassle. Please add a SIMPLE MODE : where the user does not need more than an email address and pin code and everything the plugin provides is derived from those. Yes, a lot less secure, but the current setup is way too complex for normies.
Yes, the original version by the same author was from 2013. Such clairvoyance
I like the 2013 more
Are there Nostr clients that support ‘OPEN GRAPH’ previews ?
Like show the first image in this page?
“I am a time traveler from the future “ , original post from 2013(!)
The author deleted his original post from Reddit and replaced it with the one @the: Daniel replied with.
I like the original version more, it can be retrieved from the wen archive:
Vivek⚡️:
*One of the best videos about what is Money and #Bitcoin*
*This should be taught in every school.*
Can someone with tech skills setup a feed from the El Salvador news source into a Nostr account? TIA
(Or is this already done?)
I remember HD wallets before Trezor. There was Multibit with unrelated private/pubic keys pairs, that became later Multibit HD, before the arrival of Trezor, iirc
January 3rd is a Holy Date, right?
Foget Nostr! Mastodon will win bigly ! 😜
https://www.theverge.com/23990974/social-media-2023-fediverse-mastodon-threads-activitypub
(Oops Will, of course, my bad. )
Pls, take a peek at Fossil. Developed by the creator of SQLite.
Anyone experience with Bitcoin mining in #Paraguay ? Please DM me, I’d like to exchange experiences.
Its one of the most important things in open source dev that very few devs focus on. I blame github. This is one of my favourite posts on the git mailing list:
Projects which switch to GitHub tend to have overall commit quality go down IMO, because the system
(a) makes it nearly impossible to review commit messages, so people eventually degrade to writing really bad ones
(b) makes it nearly impossible to review a rebased set of changes except redoing the entire review from square one, so people don't rebase
(c) punishes both users and reviewers who want to work with a rebased patch series by displaying the series out of order -- even for a completely linear history (it resorts based on author timestamp, not even committer timestamp), and
(d) punishes reviewers/users when they attempt to review individual commits by making it harder to see and follow these comments (though it has gotten much better on this front).
There are combination effects too. People to write really bad commit messages for all the additional "fixups" they have.
People notice that commits don't bisect nicely, and instead of understanding that the broken code review system they wrote was the problem, they instead offer a new "squash merge" option, thus destroying all the carefully separated commits that help people understand the individual steps toward the new feature and making it impossible for anyone in the future to review it incrementally.
You may say it's a workflow choice for some people to just squash all their stuff together at their option, which would be fine, but the problem is most developers don't take the time to think, and someone in charge of the project notices that they keep getting un-bisectable meaningless commits unless they force *everyone* in the project to use squash merging.
Now they are punishing me for creating clean separate commits and forcing them all to be squashed -- all as an ugly workaround to the basic tool being *broken*.
You can work around this by making a long sequence of PRs, one per what you intend to be a commit, and try to track the hierarchy -- something that GitHub certainly doesn't make easy.
And then each PR becomes a trivial small change, and you are back to merging individual commits, and writing your own tools to manage a hierarchy of PRs...and reviewers hate you if you do that because it's extremely onerous on them.
GitHub PRs aren't just hard to use, they literally degrade the quality of the code for people who have to use it. I've seen it happen with many projects.
https://public-inbox.org/git/CABPp-BG2SkH0GrRYpHLfp2Wey91ThwQoTgf9UmPa9f5Szn+v3Q@mail.gmail.com/
Daniel, take a peek at Fossil. Developed by the creator of SQLite.