███████╗ ██████╗██████╗        ██████╗ ███████╗ █████╗ 
██╔════╝██╔════╝██╔══██╗      ██╔═████╗╚════██║██╔══██╗
███████╗██║     ██████╔╝█████╗██║██╔██║    ██╔╝╚██████║
╚════██║██║     ██╔═══╝ ╚════╝████╔╝██║   ██╔╝  ╚═══██║
███████║╚██████╗██║           ╚██████╔╝   ██║   █████╔╝
╚══════╝ ╚═════╝╚═╝            ╚═════╝    ╚═╝   ╚════╝ 
                                                       

Design and Management Principles

A brief introduction to the design and management principles of SCP-079 series bots, this list of principles may change in the future.

Evidence Priority Principle

For bots with anti-spam functionality in groups, if a message results in changing user’s member status or increasing the user’s score, all its actual operations (delete, ban, restrict, remove, score) shall be executed only if the evidence can be successfully forwarded. If the target message has been deleted (for whatever reason), the robot should not continue to do anything with the associated user.

Operations under the group’s custom rules which won’t ban or score are not subject to this principle, but evidence forwarding may be performed as appropriate to find any error judgments generated automatically by the bot.

The removal, ban, and scoring operations caused by group CAPTCHA are not subject to this principle.

Messages (contact cards, location, round video, voice) that may cause privacy concerns, as well as messages (games, service messages) that cannot be forwarded to the channel by bots, are not subject to this principle.

It is not subject to this principle when clearing invalid users and deleting stickers periodically.

Hard Core Interaction Principle

Any operation that interacts with a button must have its equivalent text commands. SCP-079-CONFIG robots are not subject to this principle.

Data Minimize Principle

The storage period of normal data should generally be 24-48 hours, and for blacklist it should be within 1 month. For group settings, group administrator list, whitelist, model, regular library, and messages already sent in the channel, their storage period is not limited by this principle.

All Operations Can Be Checked Principle

This principle includes: the bots operations, the group management operations, the project management operations, and the channel operations. All these four aspects can be checked.

Bot operations can be checked: all deletion, ban, and data exchange records of the bot must be archieved and the relevant information can be fully displayed. However, in order to prevent evidence from being updated quietly, it is necessary to avoid repeated forwarding when the user, triggerred category of operations, the bot and the group are all the same. It is recommended that the interval of such evidence forwarding be 10 minutes.

Group management operations can be checked: Group management operations that may affect the user’s score must be archieved, such as the /ban command, and the bot should forward relevant evidences. The cross-robot operations via SCP-079-CONFIG must also be archieved.

Project management operations can be checked: All bots must absolutely ignore any private chat messages (SCP-079-PM, SCP-079-TICKET are specifically used for private chat, so they are not restricted by this rule), including private chat conversations between project administrators and regular users (concerning the abuse of private chat conversations). The project administrators can only manage a certain robot in relevant management group. All responding messages generated by each operation must be attached with certain administrator’s personal ID for query. In each project management group, there is no administrator except the group owner himself.

Channel operations can be checked: all public channels must have signature on all messages so as to trace back the original poster. Once the robot publishes a message on the channel, it can by no means be manually or automatically deleted or edited unless it involves privacy or hazard information, or if it is unblocked, clarified, indexed, or deleted by MANAGE.

Additional notes: Some channels such as SCP-079-EXCHANGE and SCP-079-WATCH are private channels for internal uses. These channels are only opened to internal personnel, supervisors, witnesses, and anti-spam partners. We will review the identity of whom applies to join the channels and make a public list.

Mutual Choice Principle

Groups using the bot should understand and have the willingness to adopt the rules and functions of specific bot; workgroup members should review the group’s application and check if the bot is suitable for them upon approval. Requests must be authorized before joining a normal group, i.e., the bot can only be invited via SCP-079-USER to groups.

Silence Principle

Messages should only be sent on necessary demand by the bot in normal groups. Efforts should be made to reduce the message frequency that bots appear in normal groups during design process. In addition, messages sent by bots in the normal group must not last for more than 5 minutes, except for which sent by SCP-079-TIP and SCP-079-WARN.

Worst Estimation Principle

The scenarios covered by this principle may include: server downtime, data loss, exchange channel failure, internal personnel’s disruption.

Solutions to these scenarios: SCP-079-BACKUP project. The BACKUP bot, located on a different server than others, periodically receives backup files from all bots every day, downloads and stores them to appropriate place. Meanwhile, since other bots transfer backup files through the exchange channel, data naturally gets an extra backup in this channel.

BACKUP will check the online status of each bot hourly. If any bot down is down, the SCP-079-MANAGE group should be provided with a button for administrators to enable a secondary bot on the backup machine.

SCP-079-HIDE channel is a backup for the EXCHANGE, prepared to automatically switch on after the origin channel failed for any reason.

Storage data loss and unauthorized whitelist addition deliberatly caused by internal personnel can be restored by backup; forged messages in EXCHANGE channel sent by internal personnel can be checked by message signature within 48 hours; damages to the server and backup site caused by internal personnel can be recovered by the open source code and stored data in exchange channel.