Put the notify service where it actually runs, and drop http2

Two corrections from following this section on a real box.

The notify service is a systemd user service on the VM, not something inside the
container, so the paragraph telling operators to add the name to dejima's
allowlist as well sent them to a list that never sees the post. What is worth
saying instead is the consequence: there is no second list, and nothing one
layer in narrows this pinhole the way that allowlist narrows what a session
reaches, so rule 6b's width is the whole answer. A failed post also surfaces in
a user unit's journal rather than in a session, which is a different place to
not be looking.

And the nginx block carried `http2 on;`, which is a startup error before nginx
1.25.1. The directive was spelled `listen ... ssl http2;` until then, so either
spelling breaks half the installs it is copied into and ntfy wants neither.
Dropped, with a line saying why and where to copy a working `listen` from.

docs/building-a-devbox.md

@@ -110,9 +110,11 @@ copy of that contract kept here would go stale without anything noticing.
 ### If you want notifications, they need a rule on the node
 
 dejima's notifications go to an ntfy server, and an ntfy server on your own
-network is one of the things the node firewall drops. Without a rule for it the
-posts go nowhere and say nothing about it: no error in the session, no delivery,
-and a feature that looks like it is switched off.
+network is one of the things the node firewall drops. The notify service runs
+here, on the VM, as a systemd user service rather than inside the container, so
+what a failed post produces is a line in `journalctl --user -u` for that unit
+and nothing anywhere you were looking. No delivery, no error in the session, and
+a feature that reads as switched off rather than as firewalled.
 
 The rule is [one more, if you want dejima's
 notifications](../proxmox/README.md#one-more-if-you-want-dejimas-notifications),
@@ -122,8 +124,9 @@ proxy**, because the firewall matches an address and a port and cannot see which
 name the request was for. That widening is invisible from here: the audit keeps
 reporting `PASS`, because the gateway it probes is still dropped.
 
-If the notify service runs inside the container, dejima's own allowlist needs
-the server's name as well. The two lists are separate and both apply.
+Because that service runs on the VM and not in the container, dejima's own
+allowlist has nothing to do with it. There is no second list to update, and
+equally nothing one layer in that narrows the rule if it is too wide.
 
 ## 6. Verify
 

proxmox/README.md

@@ -342,7 +342,6 @@ that no other client uses.
 # server block here becomes reachable from the devbox.
 server {
     listen <proxy-ip>:8443 ssl;
-    http2 on;
     server_name ntfy.example.com;
 
     ssl_certificate     /etc/ssl/ntfy/fullchain.pem;
@@ -374,6 +373,11 @@ server {
 }
 ```
 
+No `http2` here, in either form. It is spelled `listen ... ssl http2;` before
+nginx 1.25.1 and `http2 on;` from 1.25.1, so whichever you write is a startup
+error on the other side of that line, and ntfy needs neither. Copy the `listen`
+line from a vhost that already works on this server if you want it.
+
 **A dedicated address**, if you would rather every client kept the same URL. Add
 a second IP to the proxy, bind ntfy to it, point the DNS record at it, and open
 443 on that address only.
@@ -418,12 +422,15 @@ and no read access to anything, so a compromised devbox can post noise and
 cannot read the notifications your other clients are getting. That is the half
 of this the firewall has no way to express.
 
-##### The container's allowlist is a separate list
+##### Where the notify service runs, and why that matters here
 
-dejima's own egress allowlist lives inside the container and knows nothing about
-this page. If the notify service runs there rather than on the VM, the server's
-name has to be allowed in dejima as well, and both are needed: the node rule
-lets the VM reach it, the allowlist lets the session ask.
+On the VM, as a systemd user service, rather than inside the container. So there
+is no second list to update: dejima's own egress allowlist is a container
+control and never sees the post at all.
+
+Which cuts the other way too. Nothing narrows this pinhole one layer in, the way
+that allowlist narrows what a session reaches, so the width of rule `6b` is the
+entire answer to what this box can reach on that proxy.
 
 ##### And it goes in the group