<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

  <!-- Root protocol surfaces -->
  <url>
    <loc>http://audccufcfz5y6qg4c3kpxm5cfwo4yonurevrcl2xcf74fxwhfsgrclad.onion</loc>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>

  <!-- Apex identity surfaces. These are the addresses the node advertises as
       its own: host-meta.json names them, so they are the canonical entry
       points even though three of the four are nginx redirects into the
       service that actually answers (see nginx.conf, the /.well-known/
       rewrites on the bawnet.io server block). Priority 1.0, higher than
       the per-service copies below, which are the implementation.
       No host-meta (XRD/XML): deliberately never wired up. WebFinger
       superseded it and nothing here consumes it. -->
  <url>
    <loc>https://bawnet.io/.well-known/host-meta.json</loc>
    <changefreq>monthly</changefreq>
    <priority>1.0</priority>
  </url>

  <url>
    <loc>https://bawnet.io/.well-known/webfinger</loc>
    <changefreq>monthly</changefreq>
    <priority>1.0</priority>
  </url>

  <url>
    <loc>https://bawnet.io/.well-known/nodeinfo</loc>
    <changefreq>monthly</changefreq>
    <priority>1.0</priority>
  </url>

  <url>
    <loc>https://bawnet.io/.well-known/openid-configuration</loc>
    <changefreq>monthly</changefreq>
    <priority>1.0</priority>
  </url>

  <!-- Nextcloud protocol surfaces -->
  <url>
    <loc>https://cloud.bawnet.io/.well-known/webfinger</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

  <!-- No cloud.bawnet.io/.well-known/nodeinfo. Nextcloud answers that route
       (it sets x-nextcloud-well-known: 1, so the handler really does run) with
       a structured body, {"message":"nodeinfo not supported"} as
       application/json, but pairs it with a 404 status instead of a 501 or a
       200. That is Nextcloud's bug, not ours: Brock's call, 2026-07-26. We
       delist it anyway because a 404 in a sitemap is a soft-404 signal to
       crawlers no matter who caused it. Nothing is lost by dropping it, since
       the apex /.well-known/nodeinfo redirect points at social.bawnet.io,
       which answers 200. Put it back if upstream ever fixes the status code. -->

  <url>
    <loc>https://cloud.bawnet.io/.well-known/carddav</loc>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>

  <url>
    <loc>https://cloud.bawnet.io/.well-known/caldav</loc>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>

  <!-- GTS protocol surfaces -->
  <url>
    <loc>https://social.bawnet.io/.well-known/webfinger</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

  <url>
    <loc>https://social.bawnet.io/.well-known/nodeinfo</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

  <!-- Gitea protocol surfaces (ActivityPub enabled) -->
  <url>
    <loc>https://code.bawnet.io/.well-known/webfinger</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

  <url>
    <loc>https://code.bawnet.io/.well-known/nodeinfo</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

  <!-- Owncast (The Arena) protocol surfaces. Federation enabled 2026-08-05
       (instanceUrl was blank, which broke webfinger/actor resolution until
       fixed). Single-actor federation, not a full AP server: one account
       (r00t@arena.bawnet.io), not per-user. -->
  <url>
    <loc>https://arena.bawnet.io/.well-known/webfinger</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

  <url>
    <loc>https://arena.bawnet.io/.well-known/nodeinfo</loc>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>

</urlset>
