Template:Host

Description

Use this section to give a brief description of the network’s intended purpose and general situations you might see it used in play. This should give the reader a broad idea of whether they want to use this host in their level design.

Scaffolding

The website draw.io is a free resource you can use to create host flowcharts. The colors here don't really mesh with the wiki, but you get the idea. It's really easy to use.

This section outlines the structure of the host’s scaffolding. It should contain a subsection for each node in the host if there’s more than one. Each subsection should include the node’s properties (Type, Rating, Attack, Sleaze, Data Processing, and Firewall), IC Tray (the load order of all IC the node is capable of deploying), sculpt (a description of what a character in the node experiences), files (can be broad, be sure to include any file storage and retrieval protocols), devices (include operating procedures), and notable users (including spiders and their equipment and behavior).

Example Entry Node

insertorganizationhere.mtx

Type	Rating	Attack	Sleaze	Data Processing	Firewall	IC Tray
Destination	4	4	2	7	9	Patrol, Blaster, Probe, Track

This node serves as the public face of Insert Organization Here. It is the first node you enter when you access the host. It looks like a normal office building with a friendly receptionist to give you a tour, and its IC look like staff. Its files contain public contact information and press releases. No devices are slaved to this node. A spider is in charge of the security, but they are normally in the nested security node and so will take a turn or two to respond to an alert.

Example Security Node

intranet.insertorganizationhere.mtx

Type	Rating	Attack	Sleaze	Data Processing	Firewall	IC Tray
Data	4	6	4	5	7	Patrol, Killer, Marker, Binder

This node contains Insert Organization Here's client and employee records. It looks like a series of rooms filled with book cases and filing cabinets. Client and employee files are labeled with anonymous ID numbers known only to the clients and employees themselves, though an offline ID lookup database exists. The files of former employees or clients who have not used Insert Organization Here's services in X months are stored in the host's archive; otherwise, they are accessible to users in the node. Each file is protected by a databomb with a password known only to the client and employees handling the client's case. There are no devices slaved to this node. This node is closed to the general public, primarily used by employees as a data repository. The host's spider normally spends time here, so expect faster responses to alerts.

Physical Integration

Some hosts correspond with physical locations. They may act as a WAN to manage devices in a building, protect the personas of a business’ clientele from prying eyes, or serve as a data repository for staff reference. A few rare, outdated hosts have physical hardware they run on. Use this section to describe how the host is integrated with meatspace, if at all. Remember that because direct connections to slaved devices are a backdoor into a host’s firewall, slaved devices will be physically protected. It is better to have an easily accessible device not be slaved to a host at all than to have it compromise your network security. Whether a given host’s owners subscribe to that philosophy is up to you.

Insert Organization Here has a modest building protected by a cheap private security force. It's in an old building with wired, offline electronics, so security devices are placed in a cavalier fashion. The spider's office on the third floor contains an offline terminal they can use to match employee/client names with ID numbers when needed.

Foundation

Use this section to describe a host’s foundation, if it has one. The only static, unchanging feature of a host foundation is its logic map: a set of seven specific nodes and the data trails connecting them with the requirement each node be connected to the rest. If the host’s foundation paradigm has been locked down for some reason (such as a persistent portal anchor), you may describe it as well. This is a rare occurrence, as keeping the paradigm randomized helps the host’s owners recognize when the portal node has been anchored by an unauthorized user.