The Data Model (DM) of a Node isn't relevant if we can't perform operations on them. The **Interaction Model** (**IM**), defines a Node's DM relationship with the DM of other Nodes: a common language for communication between DMs. Nodes interact with each other by: - Reading and Subscribing to Attributes and Events - Writing to Attributes - Invoking Commands Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an **Interaction** relationship. Interactions may be composed of one or more **Transactions** , and Transactions are composed of one or more of **Actions** which can be understood as IM-level messages between Nodes. ![Hierarchy of Interaction Model](https://developers.home.google.com/static/matter/primer/images/primer-im-hierarchy.png) *Figure 1: Hierarchy of Interaction Model* Several Actions are supported on Transactions, such as a Read Request Action that requests an Attribute or Event from another Node, or its response, the Report Data Action, which carries the information back from the server to the client. ## Initiators and Targets The Node that initiates a Transaction is the **Initiator** , while the Node that responds is the **Target** . Typically the Initiator is a Client Cluster and the Target is a Server Cluster. However, there are exceptions to this pattern, such as in the **Subscription Interactions** analyzed further down in this section. ## Groups Nodes in Matter may belong to a **Group** . A Group of Devices is a mechanism for addressing and sending messages to several Devices in the same Action simultaneously. All Nodes in a Group share the same **Group ID**, a 16-bit integer. To accomplish group-level communication (**Groupcast** ), Matter leverages IPv6 **Multicast** messages, and all Group members have the same Multicast address. ## Paths Whenever we want to interact with an Attribute, Event, or Command, we must specify the **Path** for this interaction: the location of an Attribute, Event or Command in the Data Model hierarchy of a Node. The caveat is that paths may also use **Groups** or **Wildcard Operators** to address several Nodes or Clusters simultaneously, aggregating these Interactions and thus decreasing the number of actions. This mechanism is important to enhance the responsiveness of communications. For example, when a user wants to shut down all lights, a voice assistant can establish a single interaction with several lights within a Group instead of a sequence of individual Interactions. If the Initiator creates individual Interactions with each light, it can generate human-perceptible latency in Device responsiveness. This effect causes the multiple Devices to react to a command with visible delays between them. This is often referred to as "popcorn effect". A Path in Matter can be assembled using one of the options below: ```text = = ``` And within these Path building blocks, `endpoint` and `cluster` may also include Wildcards Operators for selecting more than one Node instance. ## Timed and Untimed There are two ways of performing a Write or Invoke Transaction: **Timed** and **Untimed** . Timed Transactions establish a **maximum timeout** for the Write/Invoke Action to be sent. The purpose of this timeout is to prevent an **Intercept Attack** on the Transaction. It is especially valid for Devices that gate access to assets, such as garage openers and locks. To understand Timed Transactions it's useful to understand how Intercept Attacks can happen and why Timed Transactions are important. ### The Intercept Attack An Intercept Attack has the following pattern: 1. Alice sends Bob an initial message, such as a Write Request Action. 2. Eve, a man-in-the-middle, intercepts the message and prevents Bob from receiving it, for example through some type of radio jamming. 3. Alice, not receiving a response from Bob, sends a second message. 4. Eve intercepts again and prevents Bob from receiving it. 5. Eve sends the first intercepted message to Bob, as if it were coming from Alice. 6. Bob sends the response to Alice (and Eve). 7. Eve holds the second intercepted message for a later replay. Since Bob never received the original second intercepted message from Alice, it will accept it. This message represent a security breach when the message encodes a command such as "open lock". To prevent these types of attacks, Timed Actions set a maximum Transaction timeout at the start of the Transaction. Even if Eve manages to execute the first six steps of the attack vector, it will not be able to replay the message on step 7 due to an expired timeout on the Transaction. Timed Transactions increase the complexity and number of Actions. Thus they are not recommended for every Transaction, but only the critical operations on Devices that have control over physical or virtual security and privacy assets. ## SDK abstractions The sections [Read Transactions](https://developers.home.google.com/matter/primer/interaction-model-reading.md.txt), [Write Transactions](https://developers.home.google.com/matter/primer/interaction-model-writing.md.txt), and [Invoke Transactions](https://developers.home.google.com/matter/primer/interaction-model-invoking.md.txt) provide a high-level overview of the Interaction Model Actions performed by the SDK. The developer creating a product that uses the Matter SDK typically does not perform calls to execute Actions directly; the Actions are abstracted by SDK functions that will encapsulate them into an Interaction. However, understanding IM Actions is important to provide the engineer a good proficiency on the capabilities of Matter, as well as fine control over the SDK implementation.