# Central Computer Core
##### Real Blackbox, Unified Station Data storage, Midround Backups, and more.

###### tags: `Ideas Guy` `Design`

## WTF?

At the moment there are two components that share the name "blackbox" in WS13:
* The Blackbox object, which is a traitor objective item within the telecomms room, that _supposedly_ records comms traffic, but is purely decorative.
* The Blackbox subsystem, which handles statistical records for actions performed in the round, used to generate the round-end reports/record relevant stats to the SQL DB.

The goal would be **to reorganize our data-generating systems into a cohesive data-access layer, the Computer Core, and in doing so add a layer of gameplay surrounding maintaining this data in game, making it contextually available for the station's other mechanics, and further decoupling the station from global state variables.** In practice this system:

1) Drastically improves the traitor objective for acquiring the blackbox. The more systems are tied in that will overtly fail when the blackbox is taken the higher risk this objective is, just like a supermatter shard, self-destruct core, or fukken' disk objective.
2) Gives a (mostly) reliable "source of truth" for jobs that is readily accessable.
1) SGR needs to see how much the station owes in taxes? Query the computer core and print out a report for what the station has spent/imported/exported/etc.
2) Forces computer consoles to be physically tied (likely with a multi-tool, but possibly with OTA login a la PDA server) to the computer core to be able to manipulate data.
4) Gives a method for decoupling ephemeral, _globally accessable_, unsecured storage mediums from global state variables like Medical or Security records.
5) Adds a potential midround backup mechanic for Command staff, either triggered via event or on a timer, ensuring that Command has a regular job to perform (or delegate to their lackeys)
6) Arguably the first step on the road to full NTOS/Modular Console replacement of legacy interfaces/systems.

Ultimately this means that while actions performed on the Z-Level of the station are recorded in the station's Computer Core, and opens up the potential for ruin-based Computer Cores, similar to our initiative to make the tech-web not global.

In addition, statistical counting performed by `SSblackbox` would be renamed as a subsystem that performs the same task as the current subsystem. This is mostly to prevent confusion moving forward when referring to the ingame, now mechanically relevant, item/machine.

## Why?

At the moment we have several dissolute systems that record data, Medical/Security Records, the NTNet server, the PDA Messaging Server, and our TComms infrastructure, all recording some amount of data. However most times the only people who can access any information these devices record are those who have physical access to (and take the time to go to) the Telecomms room, or those that can pull a board out of thin air to manipulate data stored... somewhere? And even then, the data is usually not in a form that can be easily pulled out of the device, save for IRL copypasta. Plus, these are application specific, meaning any new data we want to collect (track medical statistics over time for health graphs) we have to reinvent the wheel for it.

Both from a codebase development standpoint, and a ingame roleplay perspective, it makes sense to bring these disparate ingame-computer programs into a common framework.

## How?

The trickiest part of this whole design is creating the generic datastore without it turning into a performance hit on the game server itself, and still delivering some increased value to the player.

There are a couple options:
* Create a simple k/v storage layer for everything
* Upside: Incredibly simple to implement, easy to tune performance in the long term, even possible to offload to C++/Rust with minimal effort.
* Downside: Do you like collding keys? Do you like scoping and namespacing? How about possibly having lookup times in the order of whole seconds for large numbers of k/v pairs?
* Create a NoSQL-alike JSON interface that DM code creates records for, JS code parses through when accessed
* Upside: Puts the work outside of DM right off the bat, giving us far more reliable performance that sequesters lag to the client. DM code becomes exclusively interested in record creation, allows us to potentially enforce append-only log behavior, exactly what's needed for a blackbox recorder.
* Downside: Reduces our ability to interface with DM code drastically. This would harm features like arrest status and mental state logging without coding specific handles for them. To DM code it would just look like a list of strings.
* Create a full SQL system in C++/Rust extools to run queries against a round-ephemeral database
* Upside: Huge control over our data inflow/outflow. Gives AI players/competent Command staff the capability to do raw queries (temporally relevant data? just `INNER JOIN TIMESTAMP`).
* Downside: Huge amount of work to get right. Guarantees that only people who know C++/Rust will be capable of debugging issues. A major lever for exploitation by malicious players.

Once we have our data layer, the next step is the ingame object. There's some outstanding questions that need to be answered first.

* Who will have access to the device by default/what permissions will managing it be tied to?
* Ideally this would be its own ID flag.
* What department is ultimately responsible for managing the computer core?
* Engineering/Science both have significant claims towards this system.
* Engineering has legacy claims due to Telecomms being historically an engineering concern
* Science has a claim because the new features would definitely fall into the realm of a computer scientist, ie the Roboticist/Research Director.
* How does the code for this object tie into existing systems?
* The simplest option would be to link via multi-tool, and have that buffer reference to the Core be the code reference to the Computer Core API.
* Just seems like more of the ore-silo link problems but on a massive scale. Suddenly the "secure Computer Core room" becomes a high traffic area/poor shmuck in charge is a glorified link monkey.
* Alternatively, OTA linking a la Telecomms Network probing/PDA Server passwording for first time setup and access configuration.
* Problem with this is in mapping. How do we link round start devices to the core in a way that's doable from the existing mapping tools?
* In practice, what can you do with it?
* I see two main features that are must-haves:
* NTOS app that links to the computer core in a read-only mode, giving Science/Sec/Command types the ability to look at raw entries.
* Filtered by access to database tables/scopes/namespaces/etc.
* A function of both the physical access console and the NTOS app to print out data from the Core, similar to how voice recorders print transcripts.
* Beyond those core features:
* Data-driven "alerts", similar to Power/Atmos alarms, like when security warrants are updated, or when certain keywords are said over comms
* Charts/Graphs based on collected data, like revenue reports, average health, crime statistics, etc, which are printable.

## Possible Followups

### Netrunning

Hack the Planet! Give players the ability to try to hack into the computer core, or defend hacks from other Players/NPCs/Events.
* Crab-17 is no longer a physical machine to whack for hours, but a virus to eradicate!
* Traitors can proxy their hacks through terminals and devices on the station to use Syndicate hacking software on NT Firewalls and ICE.
* New roundstart Job, Network Sysadmin
* Protect the station from hacks from your networked terminal.
* Upgrade to implant-driven access, giving you proximity access to the station's security systems.
* Update/Maintain station computer hardware, track down pesky hackers, and keep the station secure from digital threats.

### Revamped Banking

Tie the station's internal monetary system into the station's Computer Core, expanding on Boomerconomy updates. Allows for independent currencies outside and within the station. SolGov Dollar, NT Scrip, Colonial chits, etc. with currency conversion/ATMs/etc. Traitors could have objectives to wipe out station credits, or crash conversion rates to a particular currency by flooding the market with station credits.

### Circuits 2.0

Bring back circuits by giving them the ability to trigger updates/create records/key off of data from the station's computer core.