[$ xmrhost] _

$ man 7 contact

[$ ] Contact the XMRHost operator

// NAME

contact — operator dispatch surface. Server-handled form, topic-routed. No phone line, no live chat, no third-party captcha. No address surfaced on the public page.

// SYNOPSIS 

$ xmrhost-cli contact --topic=<support|tos|privacy|press|other> \
                          --subject=<line> \
                          --body=<message>

// TOPICS

$ ls -la /etc/xmrhost/dispatch

// topic // scope // response window
support node provisioning, billing, console issues, technical questions on the manual 24h business / 72h weekend
tos questions about the Terms of Service, the AUP, the SLA, the Refund Policy — civil questions only, not informal legal requests 5 business days
privacy GDPR Article 15 access requests, data-subject rights, privacy policy questions 30 days max (GDPR-mandated)
press interview requests, comment on policy filings, technical-quote requests best-effort
other anything that does not fit the above topics — partnership inquiries, vulnerability disclosures, cash-by-mail arrangements 5 business days

// SUBMIT

$ xmrhost-cli contact new

// by submitting you consent to the operator processing the message + identifier per /legal/privacy. No third-party captcha, no Cloudflare, no analytics on this page. Form fires to /api/contact which dispatches a notification to the operator out-of-band.

// ENCRYPTED CORRESPONDENCE — PGP / AGE

$ gpg --recv-keys xmrhost-ops

For sensitive correspondence (legal threats, source-protection, abuse reports involving identifiable parties), the operator's OpenPGP public key is published via WKD discovery + at the path below. Encrypt the message body with the published key, paste the ASCII-armored ciphertext into the form above as the body, and the operator decrypts on receipt. age (filippo.io/age) is also accepted for technical exchanges. 

# operator pgp key (WKD)
$ gpg --auto-key-locate=clear,wkd --locate-keys ops@xmrhost

# direct fetch
https://xmrhost.io/.well-known/openpgpkey/policy
https://xmrhost.io/.well-known/openpgpkey/hu/<wkd-hash>.pub

# fingerprint (out-of-band verifiable)
<fingerprint pending operator publication>

// WHAT WE DO NOT PROCESS — OPERATOR POSTURE

$ grep -v processed /etc/xmrhost/policy

  • No KYC, ever. Signup never asks for a real name, government ID, address, phone number. The operator does not collect, store, or share any identity-verification data. The minimum identifier is an email address (any provider, any pseudonym) — used only for receipts and password-reset.
  • No DMCA-format takedowns. Iceland Höfundalög nr. 73/1972 and Romania Legea nr. 8/1996 do not provide a private notice-and-takedown mechanism equivalent to the US 17 U.S.C. §512. The operator does not run a DMCA-process desk; takedown notices sent in DMCA format receive no action and no acknowledgement.
  • No informal data-disclosure requests. Law enforcement, civil litigants, private investigators, brand monitoring services, "trust & safety" outfits — none of their informal inquiries get answered. The operator processes court-issued orders from a tribunal of competent jurisdiction ONLY, and only after counsel review. There is no voluntary- disclosure shortcut.
  • No abuse-report intake. The operator does not accept third-party reports of tenant content, tenant network traffic, or alleged tenant misbehaviour. The AUP (/legal/aup) defines what tenants may run; enforcement against a tenant is operator-discretion based on the operator's own observations, not on third-party notices.
  • No live chat widget. Third-party chat embeds fingerprint visitors and route conversations through a vendor whose subpoena posture is unknown.
  • No phone line. Voice channels create call records on the carrier side that outlive the conversation.
  • No third-party captcha. hCaptcha / reCAPTCHA / Cloudflare Turnstile fingerprint every visitor — that contradicts the brand stance. Bot floods are handled server-side via honeypot + rate limit + (production) fail2ban.
  • No public address listing. The operator's inboxes are deliberately not on the visible page. The form above routes the message to the right channel internally.

// SEE ALSO

$ ls /usr/share/doc/xmrhost