diff --git a/src/runtime2/inbox2.rs b/src/runtime2/inbox2.rs
index a38bdd08b1ace47a29d4c6fcd2cddfa67261444c..238188d73d34d89f3c378e7262557fdaf37dfab5 100644
--- a/src/runtime2/inbox2.rs
+++ b/src/runtime2/inbox2.rs
@@ -32,13 +32,34 @@ pub(crate) struct DataHeader {
     pub new_mapping: BranchId,
 }
 
+// TODO: Very much on the fence about this. On one hand I thought making it a
+//  data message was neat because "silent port notification" should be rerouted
+//  like any other data message to determine the component ID of the receiver
+//  and to make it part of the leader election algorithm for the sync leader.
+//  However: it complicates logic quite a bit. Really it might be easier to
+//  create `Message::SyncAtComponent` and `Message::SyncAtPort` messages...
+#[derive(Debug, Clone)]
+pub(crate) enum DataContent {
+    SilentPortNotification,
+    Message(ValueGroup),
+}
+
+impl DataContent {
+    pub(crate) fn as_message(&self) -> Option<&ValueGroup> {
+        match self {
+            DataContent::SilentPortNotification => None,
+            DataContent::Message(message) => Some(message),
+        }
+    }
+}
+
 /// A data message is a message that is intended for the receiver's PDL code,
 /// but will also be handled by the consensus algorithm
 #[derive(Debug, Clone)]
 pub(crate) struct DataMessageFancy {
     pub sync_header: SyncHeader,
     pub data_header: DataHeader,
-    pub content: ValueGroup,
+    pub content: DataContent,
 }
 
 #[derive(Debug)]