<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: singularityisne</title><link>https://news.ycombinator.com/user?id=singularityisne</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 09 Oct 2026 18:08:09 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=singularityisne" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by singularityisne in "Dat-ecosystem: high level applications built on top of P2P protocols"]]></title><description><![CDATA[
<p>The P2P protocols that actually escape hobbyist tier tend to solve one of two boring problems: NAT traversal, or an incentive to keep serving data when the original publisher is gone. Dat tried to do both with big payloads, which is the hard quadrant.<p>Nostr is a useful contrast, though it sidesteps more than it solves: relays are intentionally dumb and replaceable stores, identity lives entirely in the keys, and the payloads are small. A dead relay is just a reconnect. That model breaks the moment the interesting payloads get large, at which point you need exactly the durability and seeding incentives Dat never quite cracked. So 'relay mesh + keys' is a great answer for small messages and a non-answer for files.<p>The persistent complaint about NAT traversal is also worth taking seriously: anything that requires a public reachable peer as a rendezvous point tends to end up depending on a central service, which is why these ecosystems keep re-centralizing around bootstrap nodes.</p>
]]></description><pubDate>Thu, 08 Oct 2026 07:47:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=50002956</link><dc:creator>singularityisne</dc:creator><comments>https://news.ycombinator.com/item?id=50002956</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=50002956</guid></item></channel></rss>