<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>XMRHost :: notes</title>
    <link>https://xmrhost.io/notes</link>
    <atom:link href="https://xmrhost.io/notes/rss.xml" rel="self" type="application/rss+xml" />
    <description>Long-form essays, post-incident write-ups, and threat-model deep dives from the XMRHost operator. RFC-cited, code-block-heavy, technical-cypherpunk register.</description>
    <language>en-us</language>
    <lastBuildDate>Wed, 06 May 2026 00:00:00 GMT</lastBuildDate>
    <generator>xmrhost-rss/1</generator>
    <item>
      <title>Threat model for a self-hosted Matrix homeserver — federation, registration spam, AS-level attacks</title>
      <link>https://xmrhost.io/notes/matrix-homeserver-threat-model</link>
      <guid isPermaLink="true">https://xmrhost.io/notes/matrix-homeserver-threat-model</guid>
      <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
      <description>A walk-through of the threat model for a self-hosted Synapse / Dendrite / Conduit homeserver: who you are protecting against, what they can actually do at the federation layer, the registration-spam economy that nobody warned you about, the AS-level interception risk for federation traffic, and the operational controls (registration policies, federation allow-lists, room-version pinning, per-room access-token rotation) that meaningfully change the attacker&apos;s surface. Synapse-flavoured but the threat model applies to any homeserver implementation.</description>
      <category>matrix</category>
      <category>synapse</category>
      <category>federation</category>
      <category>threat-model</category>
      <category>hardening</category>
    </item>
    <item>
      <title>Monero subaddresses for hosting subscriptions — wallet workflows that don&apos;t leak the customer base</title>
      <link>https://xmrhost.io/notes/monero-subaddresses-for-hosting</link>
      <guid isPermaLink="true">https://xmrhost.io/notes/monero-subaddresses-for-hosting</guid>
      <pubDate>Sun, 03 May 2026 00:00:00 GMT</pubDate>
      <description>A primer on the subaddress mechanism (BIP44-equivalent wallet hierarchy plus stealth addresses), the practical wallet workflows for receiving recurring payments, the view-key transparency story for refunds, and the operational gotchas — sweep behaviour, output-set sizes, and the kinds of mistakes that turn an unlinkable receiving address into a correlation marker. Aimed at anyone building a Monero-only payment surface for a subscription product.</description>
      <category>monero</category>
      <category>wallets</category>
      <category>payments</category>
      <category>privacy</category>
      <category>subaddresses</category>
    </item>
    <item>
      <title>Lokinet exits and Oxen staking — the operational guide for service-node operators</title>
      <link>https://xmrhost.io/notes/lokinet-exits-and-oxen-staking</link>
      <guid isPermaLink="true">https://xmrhost.io/notes/lokinet-exits-and-oxen-staking</guid>
      <pubDate>Sun, 26 Apr 2026 00:00:00 GMT</pubDate>
      <description>Lokinet differs from Tor and I2P in one structural way: every routing node also stakes Oxen. Operating a Lokinet exit therefore is simultaneously a hosting decision, a staking decision, and a uptime-SLA decision — drop the staking, drop the node. This note covers the wallet workflow for the staking transaction, the `oxenmq` configuration for the service node, the exit-mode pieces specific to Lokinet (vs being a regular routing-only service node), and the operational discipline that keeps the stake intact.</description>
      <category>lokinet</category>
      <category>oxen</category>
      <category>vps</category>
      <category>exit</category>
      <category>staking</category>
    </item>
    <item>
      <title>I2P node hosting — floodfill vs router, why and how, with i2pd configs that survive a reboot</title>
      <link>https://xmrhost.io/notes/i2p-floodfill-vs-router</link>
      <guid isPermaLink="true">https://xmrhost.io/notes/i2p-floodfill-vs-router</guid>
      <pubDate>Sun, 19 Apr 2026 00:00:00 GMT</pubDate>
      <description>The two distinct things you can run on an I2P-capable VPS are a regular *router* (carries other people&apos;s tunnels) and a *floodfill* (additionally participates in the network database). Both are useful contributions; the trade-offs are not the same. This note walks through the i2pd configuration for each role, the bandwidth-share decision, the firewall posture, the reseed-server question, and the systemd / monitoring shape that lets you forget the box is running until something actually goes wrong.</description>
      <category>i2p</category>
      <category>vps</category>
      <category>i2pd</category>
      <category>hardening</category>
      <category>monitoring</category>
    </item>
    <item>
      <title>Setting up a Tor relay on an offshore VPS — hardened tor.conf, exit policy, and the abuse mailbox you actually need</title>
      <link>https://xmrhost.io/notes/tor-relay-on-offshore-vps</link>
      <guid isPermaLink="true">https://xmrhost.io/notes/tor-relay-on-offshore-vps</guid>
      <pubDate>Sun, 12 Apr 2026 00:00:00 GMT</pubDate>
      <description>A walk-through of what it takes to run a non-exit middle relay, then a reduced-exit relay, on a Monero-paid offshore VPS. Covers the hardened `torrc`, the systemd unit, sysctl tuning for the network stack, the ContactInfo / MyFamily fields the directory authorities will look at, and the abuse-handling mailbox that keeps the upstream provider from null-routing you in week three. RFC- and Tor-spec-cited; assumes you already know what `iptables -A` does.</description>
      <category>tor</category>
      <category>vps</category>
      <category>hardening</category>
      <category>iceland</category>
      <category>abuse-handling</category>
    </item>
  </channel>
</rss>