Hello,

I've designed a simple matrix network for a small company. Their topology consists of three nodes. Node 1 is a chokepoint...designed for public access (web of trust) - for ordering products direct, company info, yadda yadda. Node 2 is for employee use - current project data, internal documents, etc. Node 3 is building services - security cameras, locks, alarms. Node 2 and 3 is connected to 1 via fiber optic and has no wireless presence. If a hacker wanted to gain access to, let's say, Node 3 to edit the stream from a security camera and unlock a door, would they first have to subscribe to Node 1 using a security account, then they get a free ride into node 3? Or could they subscribe to Node 1 using a public account and then hack into Node 3 using a security account. This gets confusing. Is this even an efficient system?

Both could work, depends on how you set it up.

I've done similar node setups like what you have above. So, using your example, I had Admin accounts on Node 1 have security access on Node 3 and user access on Node 2. But this is all assuming you have a legitimate account and how permissions would be shared between the nodes. As an Admin account on Node 3 would have admin access on Node 1, but security access on Node 2.

Assuming the hacker is using exploits though, you don't really have an account, you just have the permissions of said account, so what I do is require a separate hack for each node. Obviously, they would have to hack Node 1 first in order to even attempt hacks on Nodes 2 and 3.

But then again, you could also say that if the hacker got an Admin account on Node 1, he could act as an Admin in Nodes 2 and 3...but if you did that, it would probably be easier to just design the small company that has a single node that covers all the functions of your 3 nodes.

It really just matters on how much matrix you want to keep your players in and how many hoops you want them to jump through...

The rules leave it entirely open for you (the GM) to decide how the permissions work on the system. If you want to reduce the amount of time the PC spends hacking the system, then just say that 1 hacked account is good for all the nodes. If you want to make it more difficult, then require more hacking attempts. It's entirely up to you.

And this "It's entirely up to you" is one of the reasons matrix topology in SR4 just plain doesn't work. At all. Period.
Because if it actually worked that way, every system security designer worth his money would have designed it so that there's a billion nodes arraged in a complicated web with 999.999.999 of them being empty duds and just gave a script to all employees to automatically navigate them to the right one (which isn't more complex than giving them their passcode), which would be basically unhackable and grind the game to a screeching halt.

Have everything everyone ever wants to hack be a single node. All the time. Ever. And just ignore the part in the rules that tells you it doesn't have to be that way. If you actually want to play a hacker, then it does. Really.

They wouldn't leave them empty. All those idle CPU cycles, when they could be running black ice or trace?

But see, having more IC or programs actually puts more actual strain on the system, while rendering more nodes doesn't. It's just like bandwith or unrated programs, which are assumed to be such miniscule problems that they are basically uncapped.
Which is all fine and dandy as long as you don't actually get any mechanical benefit from them, as an advantage for something you can have a literally unlimited amount of breaks the game. It's Agent Smith all over again, just in reverse.

Node 1 connects to the matrix - a public node. A chokepoint is "a security post". You can put most active IC here, so the term fits.


This is a node that should be defended well for business reasons.


This is a node that should be defended well for security reliance reasons. It is also a "logical" base for IC due to the physical security functions.


This offers advantages if Node1 is set to only route traffic for specific users.


Access to node 2 and 3 can be had by connecting physically or by getting node 1 to route traffic. If node 1 restricts routing to security users, a hacker needs security priviledges for node 1.

But the Matrix stuff is an abstracted system. For the sake of brevity, assume that the system represents (on a broad level) the best security option available in proportion to the difficult as set by the system mechanics. For some reason, however, people assume that the "generic" security measures that the system represents are inferior to some specific security measure or system that they invent. Your "node maze" system might even be the specific implementation of what a Firewall Rating 5 does, but what the Exploit program counters with is a way to evaluate and trace "real" data traffic in the system to the "real" nodes. It's all abstracted by the system.


The Clustering introduced in Unwired allows for a system to be organized along functional lines rather than technical (bandwidth, program load) requirements. This means that entire systems, no matter how large, should only really be represented by 1-5 Nodes, with the majority being 1-3. I definitely agree that if a GM wants to speed up Matrix-related actions, then everything should be represented by 1 Node. Even in systems I have created that have multiple Nodes, there is generally only 1 that is of "real" interest to the PC Hacker. In which case it becomes (essentially) a 1 Node hack.

I'm with you that that would be a working and fun way to do it, alas it's not the way SR4 did it. I'd love it if shenanigans like the (frankly absurd) node maze wouldn't work. A system where tricks like that where abstracted into the exploit test, because neither the player nor the GM really cares how a specific security level is achieved.
My point is that SR4 doesn't abstract that, which is the source of the problem. It abstracts away all the problems of having a million nodes and none of the advantages. Which is bad. Really, the system shouldn't give tangible benefits for having more nodes, because it doesn't make you pay anything for having more. But it does. And that's a problem.
So you're stuck with either houseruling the whole matrix percetion mechanics so that this trick doesn't work (which you should do anyway; nobody, not even the authors actually use them as written) or you houserule away the possibility of there being a million nodes. And designing an allegedly "secure" system with just 1-3 nodes is houseruling away the problem, just without actually admitting it.
It' the Oberoni Fallacy.
It's claiming a hole in the rules doesn't exist, because you can choose not to use it. Which isn't correct, because not exploiting something broken still means that it's broken.

Thanks all for the info and the insights! it's really appreciated!