Title: VoidNet Charter Author: Core Staff Version: 2.3.2 Date: 15 July 2010 = 1 - Introduction = ---------------- This documentation is designed to give the reader a general idea behind the VoidNet network, the reason for its existence and the general guidelines that server administrator's follow. = 2 - Network Purpose = -------------------- VoidNet is a project ultimately designed to allow new or experienced users access to a secure form of IRC communication. Each server is linked via SSL to ensure that the communication of its users is safe from tampering or spying. Despite the focus on secure communication, regular IRC connections can be made to the IRCd's to allow normal IRC users to still access our network. = 3 - Users = ---------- Users that connect to any of the servers linked to VoidNet must agree to follow the local server rules and policies in addition to the following network wide policies. No spam, mass messages should be sent to people who are unknown to the user or to those that do not wish to receive such messages. Multiple clients, clones or drones on separate servers may result in a network wide ban. However local IRCd policies may allow multiple clients. Bots are only acceptable if the local server policy allows it. Any assistance that users need should be provided by the local server staff or members of the network staff. = 4 - Operators = ------------- When you are an operator on VoidNet you agree to follow your local server rules and policies and in addition these network rules: You should only ever need to kill drones, bots or spammers. However K-lines and G-lines are far more effective. You should not kill other operators as this can lead to a run of kills. Global killing a friend to congratulate them or for purposes of a test are acceptable. Vanity kills are tolerated but if you register multiple vanity kills and your local server administrator does not take action, the network staff may intervene. O-lines are a privilege not toy. An operator is appointed to represent the server and the network. If that operator is found to be abusing their powers it is grounds for removal. Operators are expected to idle in the network channel to provide help and assistance with regards not only to the network but IRC in general. The use of server-side ignores (user mode +g) should be limited to ensure that users can contact you. You should also 'oper up' whenever you join the network, this makes sure that the users can identify you as a point of contact. G-lines and K-lines should always carry a reason. Operators should not interfere with channel or nickname management. These are always on a first come first served basis. = 5 - Servers/Administrators = -------------------------- Administrators are expected to create their own server rules and policies that are in keeping with the network wide rules. A MOTD is required to announce the general information to connecting users. Each administrator must ensure that their servers meet the following requirements: - Run a ratbox IRCd with +S and nick length of 12 and support SSL connections. - Port 6667 should be open for standard IRC connections. Port 6697 should be open for SSL IRC connections. Other ports can be open at the administrators discretion. - The preferred naming scheme of your IRCd domain should be in the form: irc.domain.tld (see below) - Minimum of 10 mbit connection. - Needs one active Administrator/Operator to handle requests. - List an administrator contact in the A-line (server location is beneficial as well). - The server should be accessible 24/7 with a minimum amount of downtime for physical or system maintenance. - The server must be running a flavour of Linux or UNIX. - All IRCd's should support the 'shared.conf' as provided by the Core Staff. - The minimum server G-line time should be set to 2 days or greater. Any suitable naming prefix may be selected but the form of 'irc.domain.tld' is the preferred option, with the only exception being 'ircd.'. Other alternatives are 'irc2.' or 'voidnet.' Agreed updates or network wide alterations are expected to be handled within 5 working days, unless the administrator indicates reasons why they cannot perform the action. All new operators must be announced to the administrator mailing list two days before addition. Their nick, real name and location should be provided to allow discussion with other administrators. Every new operator should be given a one week trial as a local operator before being provided global powers. The only exception to this rule is an existing global operator who is gaining another O-line. Any act of packeting or other forms of network abuse against users by operators/administrators will result in the server being unlinked unless proof can be provided. Servers that have not been used for a long period of time and have less that 20 active users may be scheduled for unlinking if no effort is made by the administrator to improve the situation. No spoof may refer to more than one user. Spoofs should only be provided to users that are mature enough to warrant one. If you are spoofing a real domain then the user must prove that he/she owns that domain. No user should be provided an IP spoof, except in the case of operators/administrators who can have a private range IP spoof. = 6 - Administrator Duties = ------------------------ Dealing with upgrades to the IRCd software or other activities requiring shell access. Dealing with providing and improving network policies. Take responsibility of the appointed IRC operators. Inform via the administrator mailing list of any changes made to their IRCd. Administrators do not interfere in channel and nickname management or conflicts. This is on a first come first served basis. Administrators cannot K-line or G-line without a reason. This is to assist other operators/administrators on the network. Keeping their C/N-lines up-to-date. Any changes requested by the hub administrators should be completed within 5 working days. = 7 - Core Staff = -------------- The Core Staff is a group of 5 people who's function is to represent the network and ensure its policies are upheld in accordance with what is best for the network and its users. The number of core staff does not change, so votes to add a new member cannot take place until a free space is available. If a core staff decides to leave or is removed, a new member must be added to take their place. Any administrator can propose a vote to remove a core staffer but only in the first week of each even numbered month. Up to a maximum of 3 removal votes can be started per voting cycle. To allow for emergency situations, core staff can start votes to remove other core staffers at any time. Once a free space is available, any administrator can initiate a vote to propose another server administrator be made a member of the core team, at the next voting cycle. No one can put them self forward for consideration. Any complaints about administrators can be taken up with one of the Core Staff. You should understand that instant action is rare as discussion with the individuals involved and other core members is required. Any complaints registered against a core member can be voiced in the administrator list and will be decided on a case by case basis. Each core member should be accessible via IRC and or e-mail. To be eligible for membership as a core staffer you require to already administrate a client or hub server. The current core members of staff are: easymac, sniker, Moggie and z. If any member of the Core Staff feels that a vote has gone against the benefit of the network as a whole they can request a vote between the Core Staff to have that vote repeated. If the Core Staff agree then a secondary discussion period will be initiated by the Core Staff to the other administrators to indicate why the vote is being repeated. A Core Staff member can only ask for a repeat vote once per vote, however other Core Staff members may request. In some situations it may be agreed by the Core Staff to repeat the vote before a voting period has been completed, these repeat votes are expected only when it is believed that discussion is incomplete or that some policy has not been completed. In certain situations where votes conflict existing network policy a vote maybe closed early by a vote by the Core Staff. = 7.1 - Core Staff Addition / Removal = --------------------------------- The addition / removal process consists of a two tier voting system and works the same in either situation. The first vote is a normal vote that decides whether the proposed official addition / removal vote can take place. It is a standard server administrator vote where all the server and core staff votes are counted and a majority determines whether or not the motion is carried. If the initial 'majority vote' is successful, a weighted vote will then take place. This second round of voting, again, provides both server and core staff the ability to vote in the proposed change; but this time the votes of server and core staff are converted into points and totalled. A server administrator vote counts as 1 point. The value of a core staff vote will change depending on the number of voting server administrators, meaning it must be calculated each time this voting system is used with the following formula: - ((server administrators - core staff) / core staff) + 25% The voting outcome ('yes' or 'no') with the most number of points will decide if the motion is carried or not. As with traditional voting, no points are awarded if an administrator fails to vote or if they vote to abstain. When a vote results in a tie, administrators who previously voted to abstain may choose to adjust their vote to resolve it but only within three days of the vote being completed. As with normal votes, if those who abstained do not wish to change their mind then the vote is nullified. = 8 - Linking Servers = ------------------- Every new server needs to fill out a link application and e-mail it to one of the core members. It will then be voted on and the decision will be returned. Any server that has an administrator or an operator that hasn't spent time within VoidNet will be rejected, it is expected that all applicants will make efforts to investigate the network before applying. If the server application has not be completely filled out, it will be rejected. Once the decision has been made, the applicant will be provided C/N-lines from a trial hub administrator, the contact will most likely be made via IRC or e-mail. The trial period will last a minimum of one month and longer if it is decided by the Core Staff that your server requires more attention. In the rare situations where problems occur within the network during a trial is should be expected that the trial link period will be extended. Ultimately this is to the advantage of both the network and the trial server as it allows more time for the requirements (see below) to be met. Permanent status for the server will then be granted and further backup links and a valid VoidNet SSL certificate will be provided. The server will also then be added into our round robins and the administrator/operators to the mailing lists. Trial servers are expected to: - Have a minimum of 20 unique and active users. - At least one active administrator or operator. - Have no global operators during the trial period. - Have no more than 3 O-lines (no global) during the trial period. - Be fully compliant to the network rules and policies. It should be noted that administrators are restricted to introducing more than three IRCd's. Any link application for a fourth IRCd will be rejected, this is to stop any monopolies occurring. = 9 - De-linking Servers = --------------------- A server that has been off-line for more than 1 day should be automatically removed from the round-robin so users will not be trying to connect to a dead IP. With the consensus of two core staff, a server that has been off-line for more than 2 weeks without contact from the server administrator(s) may be hidden or removed from the website. If a server has been off-line for a period of 1 month without any contact from the server administrator(s), the server is assumed to be dead. Two core staffers in agreement, may therefore automatically initiate de-link proceedings without the need for a server administrator vote. When a server has been off-line for a period of 1 month, but with some form of contact from the administrator(s), a server administrator vote can be called to determine if the IRCD should be de-linked. Voting administrators may consider a de-link necessary for reasons such as, but not limited to: - The administrator not providing adequate justification for the server being off-line for an extended period of time. - The administrator not making sufficient effort to keep in contact and the network informed of the situation. = 10 - Network Mergers = ------------------- Network mergers are always a difficult subject to approach and as such the initial stages should involve two staff members (one from either side) in a discussion about the various differences in their networks; NICKLEN, +S Channels, SSL in general and most importantly differences in policies. This will allow them to work out if the network is viable or indeed wise. If this initial discussion goes well, then the VoidNet staff member should announce the possibility of a merger via IRC and on the mailing list. At this point the discussion should become more open including as many of the staff from VoidNet in an attempt to get their thoughts on the merger. During this time a more formal proposal should be drawn up, indicating the number of servers and other resources that the merge will bring. Equally a list of how many staff and users are joining would be useful. After a minimum of one week the staff of the merging network can be invited into #opers to allow the discussion to expand and for them to see some of how VoidNet operates. By this time a formal proposal will be available to allow both sides to understand what is merging and the changes in network or server policies. Obviously to maintain channel etiquette the merging staffers should not be op'd in the channel. No less than two weeks after the merging staff members have joined #opers, a vote can be started to decide whether the merger proposal should be accepted or rejected. Please note that a vote cannot be started at this time unless the contact/user information of the staff members of the new servers has been posted to the mailing list supporting the proposal. Once the vote is over (which can take up to a week), and if successful, the merger can be completed enabling the new leaf servers to be linked. Subject to circumstances, new primary hubs can be connected at this time with restricted H:lines to other network hubs. Also, subject to circumstances, these primary hubs may be changed to full H:lines after a minimum one week testing period following the official merger. = 11 - Shared Access = ----------------- To assist with the management of our network we provide an additional configuration file that will be included on all servers on the network. This file will provide Core Staff access to the servers, allowing temporary and full X-line's and Resv's. The shared.conf will be provided to the server administrators by one of the Core Staff. Updates on this file will be carried out at various points and it is expected that the servers will be updated within 5 days. = 12 - Abuse = --------- If there is a complaint about an operator it will be handled by their server administrator. For instance excessive global kills, killing without reason and further forms of abuse. If the complaint is about an administrator it should be brought to the Core Staff. Any network wide abuse caused by operators will be dealt with primarily by the Core Staff. = 12 - Voting = ---------- On all votes a majority is reached only when more than 50% of the vote is Yes or No. Each server gains one vote. If an administrator manages multiple servers only one vote will be given on behalf of all their servers. An administrator can define a co-administrator to look after the server, however that co-administrator will not be award voting rights. Any attempt to circumvent the voting system by creating a pseudo-voter will result in both servers being immediately de-linked. If a server abstains then it will not be included in the vote count. If a majority is reached before the voting period is over then the vote can be accounted as complete and no further votes will be counted. Otherwise the voting period is 7 days. In the case of tied votes, the voting may be reopened in a bid to allow abstained votes to change their mind. Otherwise the vote will be considered null and void (as if it never took place). Each vote should be preceded with a general discussion on the administrator mailing list to ensure that the proposal is understood. Please take note of additional rules surrounding voting in the Core Staff section. = 12.1 - Voting Template = ------------------- The following template should be used when creating a vote, replacing the words as required. Description / Background Info: ------------------------------- Proposal: --------- To Vote: --------- Admins, please register your vote using the #admins bot command: !vote [comment] Please remember to think carefully and be sure of your decision before voting, as votes cast cannot be changed. = 13 - Unique Channels = ------------------- There are a few channels on the network that evade some of the common channel policies. - #opers - Should only be accessed by operator clients. Any normal client should be removed via ban. - #admins - This is a channel only for administrators and the Core Staff of the network. Administrator's of servers that are undergoing trial links are not permitted in this channel. - #voidnet / #help - This is the network channel, accessible by all. This channel should be considered as a help and discussion channel. Banning should be kept to a minimum. All operators and administrators should be in this channel to provide assistance to new and experienced users. - #chanfix - This channel is held purely for the chanfix service (see below). = 14 - ChanFix = ----------- The network currently provides a chanfix service. This service operates without need for intervention by users. If there is any issues with this service then contact any of the server staff that are idling within #voidnet (not #chanfix which is for the service administrators only). = 15 - Finally = ----------- Above all, common sense should prevail in all situations. = 16 - ChangeLog = ------------- - (1.0) Initial draft - (1.1) Added: Chanfix; Modified: Core Staff; Altered statement about multiple clients; Additional O-lines are accepted as global; Spelling and grammar fixes. - (1.2) Removed coax from Core Staff added Erlend; Modified: Core Staff. Added: Shared Access - (1.3) Modified: Core Staff, Servers/Administrators, Abuse. Voting. Chanfix; Spelling: kline > K-line etc. Oper/Admin; Thanks to Moggie for input. - (1.4) Naming scheme of IRCd domains; No global operators during links; Mailing lists added after trial completed (if successful!) - (1.5) Stating which ports; Shared configuration is now txline and tresv for Core Staff only. - (1.6) Temporary and FULL xline/resv abilities for shared.conf. - (1.7) Addition of closing a vote, minor amendment to the Voting section. - (1.8) Amending naming scheme. New section De-linking Servers - (1.8.1) Finger trouble 27/4 -> 24/7. Thanks to Nick - (1.9) Addition of network merger section. - (1.9.1) Alteration of network channel - (2.0) Alteration of Core Staff. Addition of how to remove/add Core Staff. - (2.1) Addition of information about co-administrators voting. Core Staff number altered to 5 and restricting core staff to be existing server administrators. - (2.1.1) Alteration to wording about core staff additions. 3 server rule introduced. - (2.1.2) Alteration of the minimum users. - (2.1.3) Core staff, removed Erlend added sniker - (2.2) Spelling mistake, placed limit on alteration of tied votes. - (2.3) Extending trials should be expected in situations of network troubles; Vote template added; Network channel is returned to #voidnet; Some minor spelling fixes - (2.3.1) Modified format to work with new txt2html script. - (2.3.2) Sorted version numbering; Fixed a couple of sentences; Added section numbering.