Matrixknoten

Matrixknoten waren Teil der Topologie der WiFi-Matrix nach dem Crash von 2064, bevor diese im Rahmen von Danielle de la Mars neuen Matrixprotokollen von 2075 wieder in eine Gitter-Struktur mit Hosts, Geräten, etc. umgewandelt wurde.

Grundlagen

Wenige Jahre nach der Etablierung der WiFi-Matrix, 2070, besaß so gut wie alles einen eigenen Knotenpunkt, egal ob nun RFIDs in Kleidungsstücken, kleine Prozessoren in Kühlschränken, Kommlinks in Schmuck oder riesiger Server - sie alle waren allgegenwärtig und kommunizierten im Rahmen der Matrixinfrastruktur via Glasfaserkabel, Funkwellen, Satelliten und seltener Laser- oder Mikrowellenverbindungen. Selbst Personal Area Networks waren damals nichts anderes als eigenständige Knoten.

Jedes computerisierte Element, welches in der Lage war, Programme und Befehle auszuführen, bildete einen Knoten - und war als solches ein Baustein der Matrix. Knoten lieferten die Rechenleistung des globalen Netzwerkes und waren auch betretbare Orte. Berechnungen, Programme, Befehle; kurzerhand, alles, was passierte, geschah, gemäß standardisierte Matrixprotokolle in den Knoten. Dazu gehörte auch das Speichern von Daten, das Herstellen von Verbindungen und das Beleben von Personas und Agenten. Ein jeder Knoten wurde von einem Betriebssystem verwaltet.

Zugangs-ID

In der Hardware eines Knotens befand sich auch immer eine Zugangs-ID, die als seine Adresse in der Matrix diente. Wenn man also den Knoten finden wollte, brauchte man nur nach dessen Zugangs-ID suchen.

Personalimit

Es konnten immer nur eine begrenzte Zahl von Personas gleichzeitig in einem Knoten ausgeführt werden - wozu aber nur User zählten, die von diesem Knoten aus online gingen und nicht Personas, die von einem anderen Knoten ausgeführt wurden und nun auf diesen Knoten zugriffen.

Prozessorlimit

Auch die maximale Anzahl an Programmen, die ein Knoten ausführen konnte, war begrenzt. Überschritt man diese Anzahl, wurde die Prozessorleistung beeinträchtigt.

Verbindung

Jene Orte, die nur wenige Zugangspunkte besitzen, etwa wegen schlechter Infrastruktur oder aufgrund vorsätzlichen Vandalismus', konnten von der technischen Entwicklung der Matrixknoten stark profitieren, in dem die vielen Benutzerknoten selbst einen Zugang erzeugten. Die engmaschige WiFi-Matrix erlaubte jeden Knoten im aktiven Modus eine ad-hoc-Lösung, bei der sie als Router für andere Knoten um sie herum dienten. Daten wurden so von einem Knoten zum nächsten geschickt, bis dann der Zugangspunkt zur verkabelten Matrix oder das kabellose Ziel selbst erreicht wurde. Somit konnten selbst Barrens akzeptabel mit WiFi-Zugangspunkten verbunden werden. Siehe auch Datenübertragung.

Arten von Knoten

Man unterschied in drei grundlegende Kategorien: Peripherieknoten, Standardknoten und Nexus.

Peripherieknoten

Peripherieknoten waren Knoten, die auf Geräten existierten, wie etwa AR-Handschuhe, Credsticks, Kühlschränke, RFID-Marker, Smartguns oder Überwachungskameras und waren 2070 praktisch in jedem Gegenstand vorhanden, die nicht die Rechen- und Kommunikationsfähigkeiten von Standardknoten benötigten, aber dennoch irgendwie mit der Matrix interagierten.

Anders als Standardknoten konnten sie nur eine einzige Persona ausführen und auch nur Programme, für die sie gebaut wurden. Auch ihre Betriebssysteme und Peripherieknoten waren bedeutend begrenzter und zielgerichteter. Entsprechend war es nicht möglich, das mehrere User gleichzeitig eine Persona ausführen und es gab auch nur Adminaccounts für ihren Betrieb. Allerdings war es möglich, sie zu einem Cluster zusammenzufassen, um dann gemeinsam als einzelner Super-Knoten zu fungieren. Da sie gegen Hacker aber sehr anfällig waren, wurden sie zum Schutz oft mit einer Master-Slave-Verbindung einem sicheren Knoten untergeordnet.

Standardknoten

Kommlinks, Cyberterminals, häusliche Telekommunikationsanschlüsse und fast jedes andere Objekt, das tragbar und in der Lage war, eine einzelne Persona und mehrere Programme oder Agenten auszuführen, waren allesamt Standardknoten. Sie konnten nur eine Persona zur gleichen Zeit ausführen, erlaubten aber per Interface, diese nach den eigenen Wünschen und Vorstellungen des Benutzers anzupassen.

Nexus

"Nexus" ist ein Sammelbegriff für Hochleistungs-Mainframes, kabellose Multi-User-Arbeitsräume und Knoten mit hohem Datenaufkommen, welche zudem eine größere Anzahl von Programmen ausführen konnten, als es Standardknoten je könnten. Üblicherweise fand man Nexus in Matrixcafés, öffentlichen WiFi-Zugangspunkten, Konzernservern, Firmen mit VR-Arbeitsplätzen und Sicherheitsknoten, Datahavens und überall sonst, wo rechenintensive Aufgaben verrichtet wurden. Jene Server, die Nexus betrieben, gab es in einer großen Bandbreite unterschiedlicher Größen und Prozessorleistungen, was von Größenordnungen wie einfachen Laptops bis hin zu ausgewachsenen Servertürmen reichte. Je mehr Rechenleistung benötigt wurde, desto leistungsstärker und größer fiel auch die Hardware eines Nexus aus.

Ein Nexus besaß ein höheres Prozessorlimit und erlaubte so auch, mehr aktive Programme auszuführen (wobei dies nicht Agenten, Intrusion Countermeasures, Sprites und E-Geister betraf). Ihre Konfiguration und Konstruktion war so aufgebaut, dass es möglich war, mehrere Personas auszuführen.

Betriebssysteme

Innerhalb eines Knotens fand sich auch immer ein Betriebssystem, das für den Betrieb des Knotens zwingend notwendig war, da es verschiedene Daten verarbeitete, Ressourcen verwaltete und alle weiteren Funktionen zur Verfügung stellte, die mittels User-Input dann auch genutzt werden konnten.

Protokolle

Wann immer man mit einem anderen Knoten interagierte, wurden vordefinierte Matrixprotokolle aufgerufen. Darin ging es um grundlegendes, wie etwa die Überprüfung von Accountdaten, Zugriffsrechten und der Status der Verbindung. Anschließend entschied der Knoten dann, ob der Anfrage stattgegeben wurde oder nicht. Mittels spezieller Software versuchten Hacker, solche Protokolle zu umgehen oder für ihre eigenen Zwecke auszunutzen, um Zugriffsrechte zu erhalten, Icons zum Absturz zu bringen oder sonstige Dinge zu tun, die sie aufgrund ihrer Zugriffsrechte eigentlich nicht tun durften.

Accounts

Die Zugriffsrechte auf Knoten wurden mittels Accounts verwaltet. Eine jede Verbindungs- und Datenanfragen wurde mit bestimmten Privilegien ausgestattet, welche von den Account-Informationen abhingen, welche mit der Anfrage geschickt wurden oder vom ursprünglichen Login, sofern es sich um eine Subskription handelte. Dabei unterschied man in verschiedene Arten von Accounts, je nach Status der Verbindung und auch Art der übermittelten Informationen.

Standardaccounts

Ein Standardaccount besaß Login-Daten bestehend aus Usernamen und Passwort beliebiger Länge, was eine alphanumerische Zeichenfolge sein konnte oder auch ein biometrisches Muster oder gar die Signatur eines Zugangsschlüssels. Dieses Passwort wurde entweder mit der internen User-Datenbank des Knotens oder einer anderen Quelle abgeglichen und dann entweder akzeptiert oder abgelehnt. Ein Großteil der User speicherten ihre Passwörter oder Signaturen in verschlüsselten Daten auf dem Kommlink, weil diese im Regelfall schlicht zu lang und komplex waren, um sie sich zu merken. Biometrische Signaturen hingegen wurden mittels Scannern verschiedener Art direkt von den Usern eingelesen.

Knotenaccounts

Knotenaccounts hingegen vergaben ihre Zugriffsrechte auf Knoten abhängig von den Privilegien, die der User auf einem anderen Knote besaß, mit dem er zum angegebenen Zeitpunkt verbunden war. So konnte etwa der Zugriff auf einen Sicherheitsknoten einen Useraccount und somit auch andere Rechte beinhalten, wie etwa Zugriff auf Kameras und Sensoren, die mit dem Sicherheitsknoten verbunden waren. Eine Sicherheitsspinne, die im Sicherheitsknoten ihre Arbeit verrichtete, hatte so auch die Befähigung, auf alle Sensoren zuzugreifen, ohne sich für jedes einzelne Gerät individuell anmelden zu müssen. Der Sicherheitsknoten verschickte diese Informationen für sie weiter, wodurch die Spinne diese Geräte dann einfach benutzen und kontrollieren konnte.

Zugangs-ID-Accounts

Auch konnte man Zugriffsrechte über eine Zugangs-ID vergeben. In der Praxis bedeutete dies, dass man jedes Mal, wenn ein Knoten oder ein Konstrukt mit einer bestimmten Zugangs-ID auf einen anderen Knoten zugreift, er oder es sofort sämtliche Zugriffsrechte erhielt, die mit dieser Zugangs-ID verknüpft waren. Dies ähnelte dem Standardaccount, da so der Knoten die Zugangs-ID mit seiner internen User-Datenbank abglich und beim Login die entsprechende Rechte verteilte. Ein Hacker konnte dies ausnutzen, indem er seine Zugangs-ID fälschte und den Knoten so zwingen konnte, ihm die zugehörigen Rechte zu geben.

Accountprivilegien

Je nachdem, welche Zugriffsrechte ein User hatte, erhielt der User entsprechend Rechte und Privilegien, die bestimmten, was er tun durfte und was nicht. Der Administrator bestimmte die Privilegien der einzelnen Accounts, aber in der Regel tendierten die meisten Knoten dazu, immerzu die gleichen Kategorien von Zugriffsrechten zu verwenden. So unterschied man in vier Stufen von Zugriffsrechten: Persönlich, Sicherheit, Admin und Öffentlich.

Öffentliche Zugriffsrechte

Bei einer Verbindung, bei der keinerlei Informationen bis auf die Zugangs-ID übermittel wurde, wurde die Verbindung automatisch auf "öffentlich" gestellt. Ein solcher Zugang erhielt ein User, wenn der den öffentlich zugänglichen Teil des Knotens betrat. Der öffentliche Account ermöglichte den Zugriff auf öffentliche Daten, wie etwa Website-Informationen, Blogs, Datenbanken, persönliche Profile, etc. Je nach Daten, auf die man zugriff, konnten mit dem öffentlichen Account unterschiedliche Rechte einhergehen, wie etwa die Möglichkeit, ohne Usernamen im öffentlichen Forum zu schreiben.

Persönliche Zugriffsrechte

Der überwiegende Teil der Accounts innerhalb eines normalen Matrixknoten bestand aus persönlichen Accounts. Der wohl größte Vorteil, der damit einherging, war der Platz auf der Subskriptionsliste und ermöglichte es dem User oder seinen Agenten, den Knoten im VR- oder AR-Modus zu betreten. Alle weiteren Rechte variierten aber je nach Knoten und Account. Dies kann je nach Sinn und Zweck des Accounts Zugriff auf Dateiindizes und Dateien ermöglichen, sowie das Editieren von Dateien, die Kontrolle von Geräten, das Hochladen von Daten, sowie die Verwendung bestimmter Programme und vieles mehr.

Sicherheits-Zugriffsrechte

Sicherheitsaccounts erhielten üblicherweise die Leute, die eine größere Kontrolle über ein System ausüben mussten, ohne gleich das ganze System selbst zu verwalten, wie etwa Sicherheitsspinnen, privilegierte User und Intrusion Countermeasures. Diese User konnten auf Protokolldaten und Knotenstatistiken zugreifen und allgemeine Knotenattribute wie Metaphern und Gestaltung manipulieren. Solche User konnten meisten auch Standardaccounts einrichten und löschen, Daten anderer User bearbeiten, einen aktiven Alarm auslösen und beenden, das Zugriffsprotokoll einsehen, etc. Ihre Privilegien gestatteten es ihnen auch, alle vom Knoten ausgeführten Agenten und ICs zu kontrollieren und zu lenken und sogar Hacker-Utilities auszuführen.

Admin-Zugriffsrechte

Adminaccounts waren für den Besitzer oder Hauptverantwortlichen eines Knotens reserviert und erlaubten diesem alles zu tun, was auch immer er wollte. So konnte er etwa den Knoten neu starten, die Gestaltung verändern, jeden beliebigen Account einrichten oder löschen, Zugriffsrechte zuweisen oder verschiedenen Accountstufen Privilegien verleihen. Weiterhin konnten Admins auch alle Protokolldaten und Statistiken des Knotens einsehen und manipulieren, wie auch das Zugriffsprotokoll. Was der Admin aber nicht konnte, war auf Programme oder Dateien einzuwirken, von denen er nichts wusste. Um einen unwillkommenen Eindringling aus dem Knoten zu werfen, war es also möglich, zunächst das Schleicherprogramm von diesem zu überwinden.

Datenaustausch

Für jeden Datenaustausch benötigten Matrixknoten die Zugangs-IDs, um so Daten vom Sender zum Empfänger leiten zu können. Der Empfänger wusste so auch automatisch, wohin er die Antwort schicken musste. Beide Knoten mussten sich somit kennen, um einen erfolgreichen Datenaustausch gewährleisten zu können. Die zwischen Sender und Empfänger liegenden Knoten versuchten derweil, den Datenverkehr weiter in Richtung Empfänger zu leiten. Im verkabelten Teil der Matrix übernahmen Router und Matrix-Backbones als lokale Knoten diese Aufgaben.

Der kabellose Teil als dezentralisiertes maschenartiges Netzwerk machte kurzerhand jeden darin befindlichen Knoten auch gleich zu einem Router für alle anderen Knoten um ihn herum. Wollte ein Knoten online gehen, dann verband er sich mit dem nächsten verfügbaren Knoten, der wiederum eine Verbindung zu anderen Knoten aufbaute und so weiter, bis der Zielpunkt erreicht war. Diese Verbindungsprozesse blieben den Matrixusern natürlich verborgen - eine Persona "sah" niemals die Knoten, über die die Verbindung aufgebaut wurden und es bestand auch keinerlei Möglichkeit, sich in einen der Knoten einzuloggen, über den eine Verbindung geroutet wurde.

Routing

Routing fand immer dann statt, wenn Daten von einem Knoten auf einen anderen zugreifen wollen und dazwischen Knoten lagen, die dann als Router fungierten. Die maschenartige Netzwerkstruktur erlaubte es, dass jeder kabellose Knoten als Router diente, sofern er nicht in passivem oder versteckten Modus lief. Selbst Peripherieknoten konnten beim Netzwerk-Routing beteiligt sein, auch wenn Standard- oder Nexusknoten bevorzugt waren. Konstrukte bekamen nichts von den Routing-Knoten mit und konnten auch nicht auf sie zugreifen. Allerdings war es möglich, den Verkehr zu analysieren, der durch einen Knoten geroutet wurde.

Die Funktionsweise dahinter war einfach aufgebaut: Der Anfangsknoten verschickte eine "Routinganfrage" an alle umliegenden Knoten, die dann von diesen weitergeleitet wurde, bis man das Ziel schließlich erreichte. Bei jedem Punkt des Weges wurde ein Rückwärts-Pointer hinterlassen, und das Ziel folgte dann den Spuren der Anfrage zurück, bis die Verbindung aufgebaut wurde. Damit das Routing erleichtert wurde, verfügten Nexusknoten der Backbone-Infrastruktur zudem über Routing-Datenbanken. Sollte aus irgendwelchen Gründen ein Knoten oder eine Gruppe von Knoten aus einem Netzwerk verschwinden, leiteten die verbliebenen Knoten den Datenverkehr einfach um diese Lübeck herum, wodurch sich das Netzwerk quasi selbst "reparierte".

	Relativ ähnlich wie das frühere Routing des alten Internets, auch wenn ein paar Unterschiede existieren. Das Routing der Matrixknoten war deutlich extensiver und erzeugte mehr Traffic, da die unzähligen Routinganfragen viele Knoten berührten. Allerdings erhöhte sich so auch die Ausfallsicherheit. Der Knoten, der zuerst das Ziel erreichte, bildete auch automatisch die schnellste Route.
	Sparcs - Everything we hear is an opinion, not a fact.

Sparcs - Everything we hear is an opinion, not a fact.

?

Datenanfragen

Der größte Teil des Matrixverkehrs bestand zumindest im Jahr 2070 aus Datenanfragen. Sei es das Aufrufen der Lieblings-Webseite, der Morgennachrichten oder aber das Schauen der neuesten Folge von Karl Kombatmage. AR-User suchten nach dem Profil der Person neben ihnen an der Bushaltestelle ansehen oder riefen den Begleittext eines Museumsexponats auf oder fragten den Preis eines Gegenstandes an. Knoten brauchten Daten aus Datenbanken, mussten Zeitpläne mit anderen Knoten synchronisieren und Daten verteilen. Selbst Anrufe und SimSinn-Sendungen wurden in Datenanfragen verpackt. Ein Knoten schickte grundsätzlich Datenanfragen an die Matrix und die anderen Knoten antworteten dann mit den benötigten Datenpaketen. Freigabe für die Übermittlung von Daten bildeten die entsprechenden Zugriffsrechte.

Datenspur

Wann immer man mit der Matrix interagiert, verbleibt auch eine Aufzeichnung davon. Konstrukte, die mit einem Knoten oder einem anderen Konstrukt in einem Knoten interagierten, selbst wenn der Knoten nur eine Verbindung durch die Matrix routete, wurden Zugangs-IDs verwendet, um alle Beteiligten zu identifizieren und um zu verhindern, dass Konflikte und Verwirrung auftritt. Solche Interaktionen wurden für gewöhnlich protokolliert, gemeinsam mit der Zugangs-ID, was Nachforschungen über begangene Handlungen erlaubte oder aber, um ein bestimmtes Konstrukt zu seinem Ausgangsknoten zurückzuverfolgen. Viele Hacker bemühten sich daher, ihre Datenspur zu verwischen, Aktivitäten zu anonymisieren oder belastende Protokolle zu manipulieren.

Subskriptionen

Im Falle voller AR- und VR-Verbindung (was auch interaktives SimSinn beinhaltete, wie es etwa bei einem Rigger der Fall war, der in eine Drohne sprang, sowie auch für die Kontrolle von Agenten oder Drohnen benötigt wurde) waren einfache Datenanfragen nicht ausreichen. Solche Fälle verlangten stattdessen nach Subskriptionen, was die Bezeichnung für fest aufgebaute, gegenseitige Verbindungen war.

Eine Persona konnte nicht unbegrenzt viele Subskriptionen aufrecht erhalten, sondern war von dem System, von dem sie aus gestartet wurde, abhängig. Ging man über ein Limit hinaus und baute mehr auf, als das System üblicherweise handhaben konnte, kam es zu einer Beeinträchtigung der Prozessorleistung. Agenten und andere Konstrukte, die auf einer Persona laufen, fielen allerdings nicht unter Subskriptionen. Solche Agenten (und auch Intrusion Countermeasures), die auf einer Persona liefen, konnten aus Sicherheitsgründen nicht von einer anderen Persona befehligt oder subskribiert werden, doch liefen diese auf Knoten, war dies ganz normal möglich.

Netzwerke

Allerdings gab es auch Knoten, die nicht mit der Matrix verbunden waren, sondern zu isolierten Netzwerken zusammengeschlossen wurden, wie etwa konzerneigene, nationale oder ganz private Netzwerke. Auch existierten Netzwerke, die nur während bestimmter Zeitintervalle verfügbar waren und manche von ihnen waren prinzipiell von der Matrix getrennt, geschützt hinter abgeschirmten Wänden und anderen Sicherheitsmaßnahmen. Einige von ihnen besaßen mehrere Zugangsknoten zu anderen Netzwerken und Gitter, während andere wiederum nur einen einzigen Zugangspunkt - einen "Chokepoint" - besaßen, der extrem geschützt wurde. Das Grundprinzip solcher Netzwerke basierte darauf, dass im Prinzip jeder, der wenigstens zwei Knoten besaß, ein Netzwerk errichten konnte. Das wohl treffendste Beispiel eines solchen Netzwerks war 2070 das Personal Area Network.

Gitter

Ein Gitter bestand aus einer Reihe mehrerer miteinander verbundener Netzwerke. Ein jedes wurde von einem oder mehreren Matrix Service Providern betrieben, die die Infrastruktur der Netzwerkkomponenten warteten. Gitter wurden in mehrere Arten organisiert:

Lokales Telekommunikationsgitter (LTG)

Wurden von Städten und Konzernen verwendet

Privates Lokales Telekommunikationsgitter (PLTG)

Wie LTGs, die aber nicht der Öffentlichkeit zur Verfügung standen

Regionales Telekommunikationsgitter (RTG)

Verbinden in einem Staat oder einer Nation die LTG und PLTG. RTGs verbanden sich zu einem großen globalen Netzwerk und bildeten so die Matrix.

Weiterhin hatten auch Raumstationen wie das Zürich-Orbital ebenfalls Verbindungen zur Matrix, unterhielten jedoch eigene, private Netzwerke.

Knotenkonfigurationen

Weiterhin gab es bestimmte Knotenkonfigurationen für Sicherheits- und andere Zwecke, die sich besser eigneten als das Standard-Netzwerkmodell.

Cluster

Ein Cluster war ein Zusammenschluss mehrerer leistungsschwacher Gerät zu einem einzelnen Knoten, der in der Lage war, mehrere Personas aufrechtzuerhalten und / oder viele Programme gleichzeitig auszuführen. Zwei oder mehr Knoten wurden so verbunden, dass sie einen "Superknoten" oder "Cluster" erzeugten, der eine größere Prozessorleistung aufwies. Dazu schaltete man die Knoten in den Clustermodus, wofür eine Adminfreigabe auf jedem Knoten notwendig war. Wurden die Knoten erfolgreich vereinigt, bildeten sie einen einzelnen Knoten, wobei hier das schwächste Glied in der Kette die untere Grenze für Dinge, wie die Firewall, bildete. Alle Accounts, die in den Knoten gültig waren, waren dann auch für den Clusterknoten gültig.

Der Cluster verband sich grundsätzlich als einzelner Knoten mit der Matrix, um so Konflikte beim Routing von Daten zu vermeiden. Einer der Knoten wurde dann bestimmt, um die Zugangs-ID für alle Personas und Programme zur Verfügung zu stellen, die auf dem Cluster liefen.

Die Subjektivität der Matrix, die auch nach Ende der Knoten-Topologie bestand, hatte auch damals die gleichen Grundprinzipien. Es war nicht möglich, sich hinter einer großen Datei zu verstecken, nur weil diese als hoher Papierstapel dargestellt wurde. Solche VR-Gestaltungen waren auch in der AR sichtbar, aber gewisse Dinge wurden schlicht vermieden und stattdessen lieber auf einfache Icons und Datenfenster gesetzt.

Metaphern

Eine Metapher diente dazu, einen Kontext für jeden Knoten, Netzwerk und Gitter zu liefern und wurde von den jeweiligen Besitzern festgelegt. So konnte dieser nicht nur bestimmen, welches Thema herrschte, sondern auch wie die Unterstruktur des Themas für den Matrixuser aussah. Eine Datenbank könnte so etwa als Bibliothek gestaltet sein.

Dabei wirkt sich so eine Metapher nicht nur auf die visuellen Komponenten der Matrix aus, sondern auch auf alle anderen Sinne, wie etwa Gehör und Geruch. Betritt man also einen Knoten mit einer Metapher, die eine mittelalterliche Burg darstellt, dann hört man auch die Geräusche herumfliegender Vögel und riecht den Geruch von selbstgebackenem Brot. Das ist zwar genau genommen etwas Spielerei, aber erfahrene Matrixuser können aus solchen Informationen dennoch einen Kontext herauslesen. Das Brot könnte etwa für einen gerade beendeten Prozess stehen und soll den Administrator daran erinnern, einen neuen Prozess zu initiieren. Das Vogelgezwitscher hingegen könnte de Alarm von IC sein, welches gerade einen Eindringling bemerkt hat, etc. - solche Merkmale hingen stark von der Metapher ab.

Auch die physikalischen Gesetze einer Matrixumgebung wurden von ihrem Thema geformt, was etwa das Gewicht von einer Sache betrifft, sich brechendes Licht, räumliche Strukturen, etc. - Somit war es auch möglich, in einem Raum zu sein, der in sich selbst zurückkrümmt, sodass man zum Ausgangspunkt zurückkehrte, wenn man immer weiter ging.

Einschränkungen=

Metaphern waren aber, wie auch die moderne Gestaltung der Matrix, nicht grenzenlos. So konnte die Metapher User nicht davon abhalten, Dinge zu tun, die er sonst üblicherweise tun konnte. Wollte man also auf eine Datei zugreifen, für die man Zugriffsrechte hatte und die Metapher sah vor, dass die Datei in einem türlosen Raum lag, dann konnte man trotzdem darauf zugreifen, etwa, in dem man einfach in den Raum hinein teleportiert wurde. Solche Gestaltungen galten aber als schlechter Programmierstil und gute Matrixgestalter und Metapherdesigner versuchten, solche Sachen um jeden Preis zu vermeiden. Etwas weniger krass waren Metaphern, die es Icons nicht gestatteten, zu fliegen, obwohl sie fliegen können müssten, um eine bestimmte Handlung auszuführen, wie etwa eine Datei, die auf einem hohen Regal außer Reichweite steht. Das änderte nichts daran, dass man trotzdem zugriff hatte, sorgte aber für seltsame Erscheinungen, wie etwa, dass der Gegenstand einfach in die Hand des Benutzers "gebeamt" wurde. Auch unsichtbare Icons fielen unter solche Dinge, was man aber einfach löste, indem man ein Interface verwendete, dass der Ansicht war, dass die bestehenden Icons durch etwas sichtbareres ersetzt werden sollte.

Index

Deutsch	Englisch
Vernetzt 46, 52-54, 55, 56-63	Unwired ?