<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: fluffypony</title><link>https://news.ycombinator.com/user?id=fluffypony</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 24 Sep 2026 04:58:51 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=fluffypony" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by fluffypony in "How Monero’s proof of work works"]]></title><description><![CDATA[
<p>lolwut. There is no specialised verification function.</p>
]]></description><pubDate>Mon, 04 May 2026 20:10:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=48014297</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=48014297</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48014297</guid></item><item><title><![CDATA[New comment by fluffypony in "How Monero’s proof of work works"]]></title><description><![CDATA[
<p>Hmmm. That's not the reason we changed it. We just got tired of tweaking things to prevent ASICs.<p>I'll add that there was such a large influx of miners at the outset, that (statistically) it seems any crippling of the original algorithm was fairly futile - the edge was both short-lived and minimally impactful. We're over a decade later, and nobody mining in the first month (even with that unfair advantage) was able to gain any meaningful percentage of Monero's emission.<p>I'll add that RandomX has proven that it is indeed possible to create a GPU and ASIC-resistant PoW algorithm. I'd encourage you to dig in further - the closest to an "ASIC" is a multi-CPU miner (Bitmain X9) with a bunch of RISC-V CPUs in it.</p>
]]></description><pubDate>Mon, 04 May 2026 20:09:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=48014284</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=48014284</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48014284</guid></item><item><title><![CDATA[New comment by fluffypony in "Show HN: Yojam – Route links to the right browser/profile, strip trackers first"]]></title><description><![CDATA[
<p>Thanks! Bumpr was good in its day; sad to see it drift.<p>Tracker list is fully editable. Preferences > Advanced > Tracker Parameters lets you add, remove, or disable any entry; rules are plain strings or regex, and they apply globally or per-browser. So if some new `xyz_campaign_id` shows up tomorrow, you paste it in and it's stripped from then on.<p>The shipped list of ~30 covers the obvious ones (utm_*, fbclid, gclid, mc_eid, igshid, yclid, etc.) but I deliberately didn't try to be a full ClearURLs clone - that list is huge and mostly rots. If there's a parameter you think belongs in the defaults, open an issue and I'll add it.<p>You can also paste a URL into the URL tester on the Pipeline tab and watch exactly which parameters get stripped before the target browser sees it.</p>
]]></description><pubDate>Sun, 19 Apr 2026 07:33:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=47822466</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=47822466</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47822466</guid></item><item><title><![CDATA[Show HN: Yojam – Route links to the right browser/profile, strip trackers first]]></title><description><![CDATA[
<p>Author here. Yojam sits in place of your default browser on macOS and intercepts every http/https click, mailto, .webloc, Handoff page, AirDrop link, Share menu item, and yojam:// URL. They all go through the same pipeline: global URL rewrites, tracker parameter stripping, rule matching (domain / prefix / regex / source app), per-browser rewrites, then either open or show a picker at the cursor.
Things I cared about that other pickers don't quite get right:<p>- Browser profiles as first-class targets. A rule can send a URL to "Chrome, Profile 3" or "Firefox, Work container" - not just "Chrome". Seems obvious; somehow nobody else does it properly.<p>- Source-app matching. GitHub links from Slack route differently than GitHub links from Messages. Handoff, AirDrop, Share, Services, and each browser extension get synthetic bundle IDs so rules can fire on ingress path.<p>- Tracker stripping happens before the target browser ever sees the URL, so referrer leakage through utm_* / fbclid / gclid / etc. is cut off globally rather than per-site. This is the only sane way to do it.<p>- Custom launch arguments with a $URL placeholder, so you can point a rule at any executable, not just registered URL handlers. Useful for throwaway Chromium instances or weird CLI tools.<p>- Menu bar only. No dock icon, no cmd-tab entry (unless the preferences window is open).<p>Stack: Swift, AppKit, App Group container shared with a Share Extension, Safari Web Extension (WIP but should be out soon), and a native messaging host for Chromium/Firefox extensions (not live yet, just doing final spit and polish). Private windows in Safari & Orion go through AppleScript because there's no CLI flag (thanks, Apple). Everything is local - the only network traffic is optional iCloud KV sync and Sparkle update checks.<p>macOS 14+. BSD-3. Happy to answer implementation questions, especially around default-browser registration, the LSHandlers dance, and how the native messaging manifests get installed across six Chromium variants without them stepping on each other.</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=47822198">https://news.ycombinator.com/item?id=47822198</a></p>
<p>Points: 4</p>
<p># Comments: 2</p>
]]></description><pubDate>Sun, 19 Apr 2026 06:22:04 +0000</pubDate><link>https://github.com/fluffypony/yojam</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=47822198</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47822198</guid></item><item><title><![CDATA[New comment by fluffypony in "Motorola GrapheneOS devices will be bootloader unlockable/relockable"]]></title><description><![CDATA[
<p>I don't want to gush about this too much, but it's SUCH a big deal. Graphene has languished with hardware support for so long - they basically only had Pixel devices as first-class citizens, which are not bad devices per se, but it's hard when you're spending most of your time doing something without the manufacturer's support.<p>There is a very real possibility that we end up with devices that can play modern mobile games at high frame rates on a secure, privacy-focused mobile OS, which is a huge step towards general adoption of something like this as a daily driver.</p>
]]></description><pubDate>Wed, 04 Mar 2026 08:06:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=47244530</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=47244530</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47244530</guid></item><item><title><![CDATA[New comment by fluffypony in "Tell HN: I got Claude Max for my open source project"]]></title><description><![CDATA[
<p>I wonder if they're going to prevent people buying GH stars to get this?</p>
]]></description><pubDate>Wed, 04 Mar 2026 08:03:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=47244506</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=47244506</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47244506</guid></item><item><title><![CDATA[New comment by fluffypony in "Using FreeBSD to make self-hosting fun again"]]></title><description><![CDATA[
<p>I spent a lot of time 25 years ago learning to love BSD in general, but FreeBSD in particular. I tried to make DragonflyBSD my desktop OS for a time. It’s sad how little love BSD gets nowadays…especially given how much of modern iOS / macOS owes BSD (for BSD subsystem that’s on top of the Mach kernel).</p>
]]></description><pubDate>Sun, 02 Nov 2025 19:34:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=45792765</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=45792765</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45792765</guid></item><item><title><![CDATA[New comment by fluffypony in "Why don't you use dependent types?"]]></title><description><![CDATA[
<p>Agree with this. The punchline here is not "dependent types bad", it is "choose your battles". Isabelle/HOL pushed frighteningly far without proof objects or dependent types, from schemes to BSG, and never hit the mythical wall. What moved the needle was automation, libraries, and legible proofs, not a fancier core calculus. Lean is great, but if the toolchain bogs down and equality games leak into your day, your fancy types are like Tesla FSD: impressive demo energy, unpredictable commute (no offense to anyone who uses it regularly). Knowing when not to use them is the real superpower imho.<p>If you need finely indexed invariants, sure, reach for DT. For the other 95%, HOL plus type classes and locales, backed by a small kernel and big libraries, will get you to production faster and with fewer regrets. Milner's LCF insight still pays the bills. And yes, croissants are delicious, but optional axioms are a risky breakfast.</p>
]]></description><pubDate>Sun, 02 Nov 2025 15:59:45 +0000</pubDate><link>https://news.ycombinator.com/item?id=45791243</link><dc:creator>fluffypony</dc:creator><comments>https://news.ycombinator.com/item?id=45791243</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45791243</guid></item></channel></rss>