Much Nostr flex incoming - thanks to relays being the major pillar in the overall design 💪 View quoted note →

I need to look into a better system for this than yelling at this guy. It already runs sandboxed at the user and filesystem level but it’s obviously too trigger-happy to nuke data.

GM. Let’s go!

There’s a good chance the next leg up in Nostr adoption would come through a good old controversy - piracy, something adult-themed that is particularly eyebrow-raising, etc. Or perhaps something a bit more contemporary, like a large scale distributed model distillation that’s autonomously coordinated via Nostr… Imagine the whackamole that would ensue - largely futile and highlighting the inherent strengths / resilience of the network. In any case, we’re probably not far off technically from being able to quickly scale the different layers / components of the stack to accommodate the growth by an order of magnitude or so. The costs would explode for the infra, but it might get easier to raise funding for the operators, and focus the thinking on the sustainability in terms or resources required. Maybe it’ll force things more in the direction of requiring some contribution of compute / storage / bandwidth to participate in the network… I’m less sure we’re ready for the accompanying onslaught of spam and low-value bots vying for attention / engagement, however, but pretty confident this can also be navigated over time. Overall, I can’t shake the feeling this thing is on the verge of breaking out - the more I hack on it and understand / marvel how things hang together and compose, and get the visceral sense for the pace of innovation. Also, what a powerful confluence of open permissionless protocols, cryptographic identity, AI and network-native magic money.

Bad robot 🤖

Are we there yet?! 🚀🌖 50 years is a long wait for something like this, time preference notwithstanding... Especially if we didn't actually go the first time around 😎 Godspeed! 🤞

I love how flexible and composable things are in Nostr. Running @Citrine relay locally on my phone now (thank you @greenart7c3 !). Added it to the list of relays for my npub. Pulled all my events into it locally. Can also now probably do a bunch stuff while completely offline. Much delight

Claude Code has also been very eager to keep adding model co-authirship trailers to commit messages, and periodically forgetting instructions to the contrary. Solved it with a Git commit hook eventually - with a reject message gently reminding the agent not to do that View quoted note →

Eventually you gotta level up though. Hello @GrapheneOS, @Zapstore and all the ungated open-source and Nostr innovation and creativity!

Nostr is fascinating and has been a very rewarding rabbit hole to be falling into. I couldn’t help it but start itching to try to measure the current levels of user activity and the trajectory. 

It looks like we have been hovering at around ~5k daily active users and ~30k monthly active users for the past year - based on the data I have right now and the current methodology.

This is currently based on aggregating most of the major events in the network indicating user activity - posts and replies (kind-1), reactions (kind-7), zap receipts (kind-9735), etc. Some of the more obvious and egregious spikes due to bot swarms, etc. have been removed. The data is from two major relays so far - relay.damus.io and relay.snort.social (both support negentropy, so historical data acquisition with strfry is straightforward). Pure lurker activity (follow-list updates, profile updates, etc.) is not currently measured (requires continuous acquisition of replaceable events) and can lift these numbers meaningfully, but not by an order of magnitude most likely. 

Would love to hear if this aligns with what folks have been seeing through their own methods and observations! 

One of the next aspects I’m curious to explore is what happens if I start moving out on the long tail of relays by progressively acquiring and incorporating data from smaller relays for this analysis - would that simply lift the baseline DAU/MAUs while keeping it roughly flat, or would we see growth?

Much delight - getting pretty happy with where I’ve been able to progress to with my envbox builds over time. Two separate units now: one running next to the solo Bitcoin miners and the other in the living area. Near-realtime environmental metrics produced: temperature, relative humidity, illumination, barometric pressure, CO2, particulate matter. The unit next to the miners has an additional noise level sensor - proper factory-calibrated dBA. All metrics are exposed by the units via a REST API. Data is continuously acquired from the envboxes and the miners by Telegraf into InfluxDB and plotted in Grafana - all running on an Umbrel

Running Hydra Pool :) On an Umbrel, on mainnet. Much delight. Smooth sailing - great instructions on hydrapool.org. This is running :latest via docker compose. Also built locally from Rust source earlier - breezed right through it 👌

GitHub

GitHub - 256foundation/hydrapool: Open Source Bitcoin Mining Pool

Open Source Bitcoin Mining Pool. Contribute to 256foundation/hydrapool development by creating an account on GitHub.

Awesome job guys, amazing! Thank you @256Foundation @jungly @econoalchemist et al

Integrated a particulate matter (PM) sensor - Sensirion SPS30 - into my envbox build. This should hopefully give me some insight into the dust buildup / particulates in the air around where my miners are running. Ran out of available GPIOs on the original ESP32 “CYD” board, so spun this up as a separate “dustbox“ unit for now. Will be getting a different ESP32 board with more available GPIOs next most likely - to bring this all back onto a single MCU board, and reduce the overall footprint.

Thank you @D++ for the work of ❤️ on the @256FOUNDATION’s Telehash dashboard! Loving it - functionally, and in terms of aesthetics! 🤩 Did I catch that right on the live steam - it’s getting contributed as the browser frontend to Hydra Pool next?

Integrated a sound pressure level sensor into my envbox / sensor array build. This now will allow me to cap the max dB(A) / noise level generated by the miners as I auto-tune / overclock them - in the same way you’d normally cap max ASIC and VR temperatures, and max power.

Love the idea of a Telehash fundraiser - what a beautiful and easy and native way to participate! @256foundation - love what you guys are doing supporting open-source mining stack development and education, good luck winning a block this year! ⛏️ @Tyler Stevens ⚡️ @jungly @skot9000 @Rod @econoalchemist @Schnitzel @rjk et al

Show your miner a little love today and de-dust the heatsink / fan 🧹 This guy went from laboring at 100% fan -> ~60%, all else being equal. 

The fan acoustics were starting to sound peculiar, which is what drew my attention. Hopefully no lasting damage to the fan, but I’m not so sure. Wish there was a better way to get alerted earlier.

Choppin' air much?