The current administrator of is James ([email protected]).

Relay Policies

This sections details the policies IRC operators participating in OVERdrive-IRC's PyLink Relay network are expected to follow.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1) Content

  1. Network administrators (i.e. those participating in the linking process) are responsible for maintaining conducive discussion within their linked channels, and to make sure they are their Operators abide by these policies.
  2. Network operators SHOULD NOT attempt to police channels originating from other networks.
  3. Network operators should stay vigilant against attempts to evade channel/network bans via a relay network.
  4. DDoS, extortion, and other threats should be dealt with seriously, with perpetrators to be removed on a best effort basis.
  5. Harassment and illegal activity are forbidden across the PyLink network. Networks may be delinked immediately, if found to contravene this policy or harbour users doing so.

2) Network Operations

  1. Operators SHOULD not attempt to use oper override on other networks' channels (MODE, KICK, KILL), unless given prior permission or with a reasonable justification. Modes, kicks, and kills from unopped clients are blocked by PyLink by default (see the CLAIM section of the PyLink Oper Guide for details).
  2. Operators MUST NOT ever use DEFCON or any other mode-locking feature in services, as these are inherently incompatible with Relay's CLAIM feature (they will cause MODE floods).
  3. Operators MUST NOT register channels belonging to other networks on theirs (via ChanServ, etc.) without prior permission from the target network. In any case, doing so is not recommended due to potentially causing MODE conflicts.
  4. Operators MUST either disable or set any session limit (anti-clones) enforcement in their IRC services to use K/G/Z:Line instead of KILL - should a large amount of kills be directed at a PyLink client, PyLink will automatically disconnect.
  5. Network administrators should remain active on their network and be responsive to any concerns or network votes in #pylink-staff. Should a network's administration fail to respond to any concerns for a period of 30 days, they may be delinked by the Links Administrator's discretion.

3) Privacy and Channels

  1. #pylink-staff SHOULD be linked on every participating network, with active network operators present - this is where staff discussion for new links, software updates, downtime notices, etc. are announced.
  2. Private information of relay users (IP addresses, etc.) along with discussions in #pylink-staff MUST remain private. Policies against data leaks (in channels or outside the network) will be enforced on a 3-strikes basis.

Submitting link applications

Links applications can currently be made by approaching the PyLink Links Administrator via email or IRC, from any participating network. The process for submitting link applications will likely be automated in the future.