The n34 release v0.5 is now available (https://n34.dev). > n34 is an open source command-line interface tool for sending and receiving Git issues, patches, pull requests and comments over the Nostr protocol. It supports creating, replying to, and managing issues, patches and pull requests, making Git collaboration decentralized and censorship-resistant. Added: - New command `repo state` - Support for pull requests - Logs now go to stderr and a file - Accept patches from stdin in `n34 patch send` - Write patches to stdout in `n34 patch fetch` - `n34 repo announce` supports `u` tag for forks - Enable Tor proxy for onion-service relays - Send nip07 request after user opens proxy page Breaking Change: - `issue` command now requires subject, makes content optional Fixes: - Require `applied_commits` in `n34 patch apply` Refactor: - Removed `dbus` C dependency

I don't give a fuck what you think about me writing code without AI. I don't care how many hours it takes me to build something you'd just prompt into existence as generic slop. Enjoy your quick fixes. I'll keep enjoying my craft. I don't chase the final product. I live for the process, the logic, the friction, the grind. The output is just a byproduct. The work is the point. I don't write code for you, for money, or to be "helpful". I write it because I love the act of building it. If you're chasing efficiency or profit, do whatever works for you. I do what I like. Why hand the process over to a model just to chase "productivity"? I don't work for you. I do this because I like it, and it doesn't hurt anyone.

I shared my Tor relay logs with an LLM and got its analysis back, very proud of my #Tor relay. > Over the past 10 days, your relay has safely transferred **611.48 GB** of sensitive user data while handling **1.2 million total connections** from both IPv4 and IPv6 users. You have protected an average of **1,022 unique connections per hour**, consistently maintaining over **1,000 active privacy circuits** at any given time. Traffic shows a healthy balance of **48.5% uploads and 51.5% downloads**. > The real-world impact is substantial: your daily average of **378 GB** in traffic has enabled the equivalent of **1,260 hours** of educational video streaming, **126,000** uncensored article downloads, and **12.6 million** secure message transmissions. > Security remains flawless, with perfect forward secrecy on all v3 handshakes, **zero malicious circuits blocked**, and automatic prevention of **151,608** potential attacks. Technically, your relay demonstrates excellent dual-stack IPv4/IPv6 support, a healthy **18.4% growth** in daily traffic, and clean synchronization with **9,901** network descriptors.

Weirdly, Jumble filters out onion relays by default. Disable it in settings? Nope, it'll still filter them. Why? You haven't enabled 'insecure' connections, which is Jumble's way of saying `wss` and `https` without the secure marker

I like this concept, a hybrid Nostr model where users run onion relays directly on their devices. This approach makes Nostr P2P. User uptime is the challenge. We still need always-online relays. But local relays on user devices can sync their data when they come online. Here's a scenario. A Nostr client first tries to send an event to the user's WRITE relays. If these are all offline, the client then tries to send the event to the READ relays of the user's contacts, specifically those contacts who also have the sender in their contact lists. When the user comes back online, their device can fetch pending events from those contact relays. I think these local relays should be WoT relays, not just personal ones. View article →

I'm now a Tor relay operator, my relay fingerprint is `C61B3104A7871EED8CCDA43D6BDC5BA54EC140F4`. #asknostr any tips?