<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: JulianHart</title><link>https://news.ycombinator.com/user?id=JulianHart</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 09 Sep 2026 12:58:37 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=JulianHart" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by JulianHart in "Agent Skills"]]></title><description><![CDATA[
<p>Interesting format, but skills feel like optimizing the wrong layer. The agents usually don't fail because of bad instructions — they fail because external systems treat them like bots.<p>You can have the perfect scraping skill, but if the target blocks your requests, you're stuck. The hard problems are downstream.</p>
]]></description><pubDate>Tue, 03 Feb 2026 15:20:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=46872064</link><dc:creator>JulianHart</dc:creator><comments>https://news.ycombinator.com/item?id=46872064</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46872064</guid></item><item><title><![CDATA[New comment by JulianHart in "IP Addresses Through 2025"]]></title><description><![CDATA[
<p>The CGNAT point is underrated. Carriers have zero incentive to move away from it - thousands of users per public IP, no transition cost.<p>The interesting downstream effect is on IP reputation systems. Traditional detection assumed 1 IP = 1 user. CGNAT breaks that entirely - platforms can't aggressively filter mobile carrier IPs without blocking legitimate customers by the thousands.<p>Makes sense the IPv4 price dropped once mobile networks proved you can serve massive user bases with relatively few public addresses.</p>
]]></description><pubDate>Tue, 20 Jan 2026 19:41:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=46696783</link><dc:creator>JulianHart</dc:creator><comments>https://news.ycombinator.com/item?id=46696783</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46696783</guid></item><item><title><![CDATA[New comment by JulianHart in "A decentralized peer-to-peer messaging application that operates over Bluetooth"]]></title><description><![CDATA[
<p>This would've been useful during the Iran shutdowns last week. Bluetooth mesh is one of the few things that keeps working when carriers go dark.</p>
]]></description><pubDate>Mon, 19 Jan 2026 14:37:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=46679457</link><dc:creator>JulianHart</dc:creator><comments>https://news.ycombinator.com/item?id=46679457</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46679457</guid></item><item><title><![CDATA[New comment by JulianHart in "Ask HN: One IP, multiple unrealistic locations worldwide hitting my website"]]></title><description><![CDATA[
<p>That's a Cloudflare IP — 173.245.x.x is their range. You're seeing Cloudflare's edge servers, not actual visitor IPs.<p>The multiple locations are just showing which Cloudflare POP handled each request (ORD, SJC, LAX = their data centers). That's expected behavior when you're proxied through CF.<p>Check the CF-Connecting-IP header to get the real visitor IP. What you're logging right now is basically "which Cloudflare server talked to your origin," not "where the bot actually is."</p>
]]></description><pubDate>Mon, 19 Jan 2026 14:32:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=46679384</link><dc:creator>JulianHart</dc:creator><comments>https://news.ycombinator.com/item?id=46679384</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46679384</guid></item></channel></rss>