XYZnet Network Charter

Preface

These guidelines govern participation on the IRC medium known as the XYZnet IRC Network. They apply to users, operators, and server administrators linked under the XYZnet name. The network is engineered around XYZircd and Rustic IRC Services; configuration conventions (including shared XYZnet.conf) exist to keep leaf servers consistent.

Section 1: Server Administrators

Server administrators are active members of the network, not passive hosts. They keep their server’s local ircd.conf accurate (name, SID, listeners, SSL, links) while retaining the network-wide XYZnet.conf unchanged unless coordinated with other admins.

• Maintain working links to agreed hubs and to services (services.XYZnet.org).
• Train and take responsibility for operators with O:lines on their server.
• Give reasonable prior notice before adding global operators or major routing changes.
• Announce planned downtime to other admins/opers (and users when impact is broad).
• Client ports should include at least 6667 (plain) and 6697 (TLS) where possible; routing ports follow current link policy.
• New permanent servers are accepted only through the link application process (Section 5A), not by informal handshake alone.

Section 2: Global Operators & Local Operators

Global operators handle network-wide abuse and coordinate with admins. Local operators are typically in training under their server admin. Operators are expected to:

• Know basic IRC, XYZircd tools, and Rustic commands relevant to their role (X/Y/Z).
• Handle spam, clones, open proxies, and policy abuse proportionally (warn → kill → kline).
• Use /SQUIT and major routing changes only with coordination and notice (WALLOPS / global notice as appropriate).
• Prefer helping users in #XYZ (and other official help channels) when online.
• Never harass users or abuse oper privileges for personal disputes.
• Participate in good faith when a link application vote is open (Section 5A), via the opers portal.

Section 3: Users

• Be respectful. Harassment, hate speech, and illegal content are not welcome.
• No flooding, clones used for disruption, malware distribution, or open proxy abuse.
• Register nicks with /msg X REGISTER; do not attempt to impersonate staff or services.
• Channel owners set channel policy within network rules; network staff may intervene for severe abuse.
• Privacy: host cloaking (+x) is default; do not attempt to de-anonymize users for harassment.

Section 4: Services

Official services are X, Y, Z, and any additional bots announced by staff (e.g. Weather, LastFM, IdleRPG, Monitor). Names such as NickServ, ChanServ, OperServ, etc. may appear as reserved stubs on the network jupe and will direct users to #XYZ. Do not trust unofficial “services” bots.

Section 5: Servers & Routing

• Only authorized servers may link. Unauthorized hubs will be juped or denied.
• TS6 linking and modern CAPABs are required for new servers (XYZircd / Solanum lineage preferred).
• Leaf servers keep network-wide XYZnet.conf in sync; only ircd.conf (name, SID, listeners, SSL, opers, links) is local.
• Statistics collection (thales-XYZ-v1 / stats.XYZnet.org) and the scanner (scanner.XYZnet.org) are official network services.
• Test or temporary links remain temporary and limited until a permanent application is approved under Section 5A.

Section 5A: Linking a New IRCd (Applications & Voting)

Anyone who wishes to run a leaf IRCd on XYZnet must apply publicly and pass staff review. Informal or private “just send me a connect block” links are not permanent policy.

1. Application

• Submit a Link Application at www.xyznet.org/link/ (also reachable from the site navigation).
• Provide at least: proposed server name, contact IRC nick, host/IP or ASN notes, and a short reason (capacity, region, uptime expectations).
• Applicants should be able to run a current XYZircd/Solanum-compatible stack and maintain TLS on client ports where possible.

2. Admin screening

• Network admins review the application in the admin portal.
• Admins may reject incomplete, hostile, or unsafe applications without a full vote.
• If the application is suitable for a vote, an admin opens it for voting.

3. Voting (24 hours)

• Once opened, the application appears in the opers portal.
• IRCops each cast one (1) vote — yes or no.
• Network admins also vote; each admin vote counts as three (+3) votes.
• The voting window is 24 hours from the time the vote is opened (deadline shown in the portal).
• After 24 hours the vote closes automatically; results (weighted yes/no tally) return to admins.

4. Decision & linking

• Admins finalize accept or reject after the vote (or earlier only if the application is withdrawn or presents an emergency safety issue).
• Accepted applications proceed to technical linking: SID assignment, connect blocks, passwords, and a coordinated /CONNECT.
• Rejected applications may re-apply later with improved detail; repeated spam applications may be ignored.
• A permanent link remains subject to this charter: poor uptime, routing abuse, or policy violations can lead to delink.

5. Vote weight summary

Role	Weight	Where to vote
IRCop (oper)	1	/opers/
Network admin	3	/opers/ (and finalize in /admin/)
Decision window	24 hours from vote open

Portal access: log in with a registered IRC nick and password. IRCop portal access requires the ircop flag on the registered nick (set when you successfully /OPER on the network).

Section 6: Amendments

This charter may be revised by network administrators. Material changes should be announced in official channels. Continued use of the network constitutes acceptance of the current charter.

Historical inspiration: classic network charters such as MooNet (1990s), adapted for XYZnet. Link voting procedure aligned with the public application portal (2026).