Modeling Platforms, Accounts, Messages, and More with the inet:service:* Forms

by savage | 2026-01-08

We’re constantly strengthening and expanding Synapse’s capabilities, whether through adding new features and workflows or further developing the data model. As part of this effort, we have updated the data model to replace the inet:web:* forms with the inet:service:* model. The inet:service:* forms, like the inet:web:* forms they replace, represent information such as platforms, accounts, and messages. However, the inet:service:* forms are more broadly applicable to a range of current technologies and configurations, with a greater ability to represent specific details and integrate with additional forms in the data model. In this blog, we’ll discuss the reasoning behind making these changes, and walk through several examples of how to use the new forms to capture and display data.

Why Did We Make These Changes?

The benefits of replacing inet:web:* with inet:service:* forms include:

A more broadly inclusive data model. Removing the focus on websites means analysts can use the inet:service:* forms to reflect a greater array of services and better represent related components. For example, analysts can use the inet:service:* forms to represent an account associated with different platforms, such as Drive, Gmail, and Meet, and relate both the account and platforms to Google as the overarching parent platform.
A greater ability to capture detail. With the updated forms, analysts can more accurately capture relevant details, such as how accounts, platforms, and messages are organized. An analyst can now note, for example, whether a message was sent within a specific channel on a platform, and whether it was a repost, part of a thread, or a reply.
Improved integration with other aspects of the data model. The inet:service:* forms include properties analysts can use to link platforms, accounts, and messages with other aspects of the data model. An analyst can model an account posting messages to a thread in a channel on a specific instance of a platform operated by one organization, while also capturing details about the associated client, host, and software version used to send the messages.
A simplified data model. We removed duplicate properties by linking the inet:service:account form to ps:contact through the former’s :profile property. In contrast, inet:web:account did not link to ps:contact, but contained many properties that repeated those found on that form.
Increased flexibility in modeling data and deconflicting nodes. Replacing composite inet:web:* forms with inet:service:* GUID forms removed the need to populate required properties, giving analysts more flexibility in both capturing available, potentially partial, information and deconflicting nodes.

The inet:service:* Forms in Practice

When developing the Synapse data model, we try to create elements that are applicable across a range of data sources and analysis disciplines. There is a balance to strike: analysts should be able to use the existing model to accurately represent novel data, however, we do not want to overfit any of the data model elements to narrow use cases. The inet:service:* forms, for example, represent network-based or Internet-based services. Analysts can use the forms to capture data ranging from social media to message boards or forums, and from e-commerce sites to cloud services.

With this broad use in mind, it can be helpful to describe the intended purpose of each form. We've listed several of the most common forms here for reference, and will further illustrate these concepts with real-world examples below.

Platform (inet:service:platform). A platform is a specific service that is used or accessed. In the revised inet:service:* model, most objects are platforms: everything from X/Twitter, to a particular crimeware forum, to Netflix, to ticketing or tracking systems such as Jira. Platforms can be part of a larger, parent platform; Google, for example, is one such example of a platform that supports other platforms, such as Gmail, Drive, and Calendar, among others.
Account (inet:service:account). A user interacts with a service platform through an account. Accounts have two separate (but closely related) aspects: user information and login or authentication data. User information consists of details about the account that are available to other users of the platform (e.g., a LinkedIn profile) or to platform administrators. The data model captures an account’s :profile details as a ps:contact node. We can infer that the account is associated with a set of credentials used to authenticate to the platform, although we may not have visibility into those details (unless we are the platform administrators).

Sometimes we’ll need to record that an individual has multiple accounts - each with unique profile information - across multiple platforms under a parent platform. We can capture the different profiles by creating an inet:service:account node for each platform that the individual has access to, and then use the :profile property to link to a ps:contact node containing that account’s profile details. If we know that the accounts use the same credentials, then we can use the :parent property to link both accounts to an overarching authentication account (inet:service:account) node.
Agent (inet:service:agent). An agent is a software integration deployed within a platform that operates as part of the service architecture, such as a Github bot running within a Slack instance and providing users with a way to interface with Github. An analyst can use the form’s :software property to document the latest known version of software behind the agent, and can capture the account responsible for creating or deploying the agent using the :creator property.
Channel (inet:service:channel). A channel contains messages distributed between one or more accounts (inet:service:channel:member). An analyst can use the inet:service:channel form to represent a Slack channel, for example, while capturing the members with inet:service:channel:member, and then using the :channel property on the inet:service:message form to link a message to the channel in which it was sent.
Group (inet:service:group). A group consists of member accounts assigned a given role (often associated with related permissions) within a platform. An analyst can use this form to represent all accounts given an "admin", "devops", or "analyst" role, for example. In the upcoming Synapse 3.0, this form will be renamed to inet:service:role to clarify its purpose.

Real-World Examples

The following sections will highlight key aspects of the inet:service:* data model by walking through modeling examples for the categories highlighted in the table below. While we’ll focus on examples from the Use Cases column, we’ve included several additional platforms of the same category in the Other Examples column:

Category	Use Cases	Other Examples
Standalone platforms	Signal, Bluesky	X/Twitter, LinkedIn, Telegram
Platforms with a parent platform	Facebook, Instagram, etc. (Meta), Gmail, Drive, Meet, etc. (Google)	AWS (Amazon)
Multiple instances of a platform with a parent platform	Slack	Discord
Federated platforms	Mastodon

Note

The case studies in this blog are all modeled within the Vertex Intelligence-Sharing Synapse Instance (the "VISI" for short) and can be found in the "inet:service:* model" view. Request access to the VISI here.

Standalone Platforms: Signal and Bluesky

Signal and Bluesky are standalone platforms; there is only one Signal and one Bluesky, and neither have an overarching parent platform. They serve as good examples for how to capture common messaging and social media constructs such as accounts, channels, messages, and threads in the inet:service:* model. Therefore, for this use case we modeled a high-profile conversation that took place on Signal and related commentary that appeared on Bluesky.

On March 13, 2025, then-US National Security Advisor Michael Waltz mistakenly added Jeffrey Goldberg, a journalist at The Atlantic, to a Signal group where members of President Trump’s administration would go on to discuss details of upcoming US military strikes in Yemen. The incident made headlines for - among other things - the officials’ use of an open source program to share sensitive military information, despite the Trump administration’s insistence that the details were not classified. Goldberg later released screenshots of the messages, although he redacted some details out of concern that their publication would pose a risk to US national security.

Here’s what those published messages look like in Synapse when modeled with the inet:service:* forms:

Signal and the "Houthi PC Small Group"

The initial conversation regarding the US military strikes took place on Signal, an encrypted, open source platform operated by Signal Messenger LLC. We modeled Signal using inet:service:platform. The following Storm query will lift the resulting node, which is also shown in the image below:

inet:service:platform:name=signal

According to Goldberg, Waltz accidentally added him to a Signal group chat that Waltz had created and named "Houthi PC Small Group." We modeled this chat in Synapse using the inet:service:channel form and populating the :name, :creator, :period, and :platform properties to capture the name, and the associated timeframe and platform. The following Storm query lifts the inet:service:channel node:

inet:service:channel:name="houthi pc small group"

The Signal Accounts

Based on Goldberg’s reporting, the "Houthi PC Small Group" appeared to contain at least 13 members - including the erroneously added Goldberg. We modeled these as inet:service:account nodes and used the :platform property to link them to the inet:service:platform node for Signal, then used the names shown in the published screenshots to populate the :user property for each account. You can use the following Storm query to lift the inet:service:account nodes, which are also shown in the screenshot below:

inet:service:account:platform::name=signal

We then used the :profile property to link each account to an associated ps:contact node with :name, :title, and :orgname properties that we had populated with information from Goldberg’s reporting. In the image above showing the inet:service:account nodes, an embed column (:profile::name) displays the :name property associated with the linked ps:contact node, while another (:platform::name) displays the :name property value from the linked inet:service:platform node.

Tying the Accounts to the Channel

After modeling the Signal accounts, we created inet:service:channel:member nodes to link the accounts to the "Houthi PC Small Group" channel. The inet:service:channel:member form has a :creator property that we used to show that Waltz created Goldberg’s channel membership by erroneously adding his Signal account to the chat. There is also a :remover property, although we did not populate it in our modeling. While we doubt Goldberg remained in the chat following the first article's publication, we lack visibility into whether he exited himself or if another member noticed and removed his account.

This Storm query lifts the node capturing Jeffrey Goldberg’s membership to the "Houthi PC Small Group" channel:

inet:service:channel:member:account::user="jeffrey goldberg"

Modeling the Messages

We used several embed columns to display the messages and relevant properties such as account username, and the names of the platform and channel:

Although we could have used the :reply property on the inet:service:message form to model a response to a specific message, we kept our modeling simple to match the participants’ use of Signal. While Signal users can respond directly to a message by clicking on it and selecting "reply" from the resulting menu, the chat participants did not appear to use this feature. Instead, they appeared to direct their response to a specific user through the message text, as seen below:

Message Replies, Reposts, and Threads on Bluesky

Shortly after publishing Goldberg’s initial article on the Signal chat, The Atlantic promoted the article on the social media network Bluesky - another platform (inet:service:platform). The Atlantic's post about Goldberg's initial article is a message (inet:service:message), which we linked back to the Bluesky platform. We captured comments on The Atlantic's post as replies - additional messages (inet:service:message) linked to the original post through the :replyto property. We felt that this was the most accurate way to represent the data, as the messages were individual responses to The Atlantic’s post, rather than part of one larger conversation.

This Storm query lifts The Atlantic’s message promoting Goldberg’s article, along with nine replies:

inet:service:message:account::user=theatlantic.com +:time=20250324* -+> inet:service:message:replyto | limit 10

The inet:service:message form also has a :repost property that we used to model accounts that reposted The Atlantic’s Bluesky message. None of these accounts included their own commentary, so we did not populate the :text property. The :time property is empty as Bluesky only displays the date and time of The Atlantic’s original post, rather than when the other accounts reposted the message.

inet:service:message:account::user=theatlantic.com +:time=20250324* -> inet:service:message:repost | limit 3

Conversation Threads

The inet:service:thread form and the :thread property on the inet:service:message form represent messages sent as part of a conversation thread. The Storm query below lifts several Bluesky messages that a journalist made in which he responded to his own prior post, creating a conversation thread of one:

inet:service:thread:creator::profile::user=shaneharris.bsky.social

Analysts can also use inet:service:thread to model other types of conversations, such as an initial post, a reply, and then a response to that reply.

Platforms within Platforms

As monolithic platforms, Signal and Bluesky are fairly simple to model. However, an analyst can use the Synapse data model to capture more complex architectures as well, such as platforms with an overarching parent platform, and instanced platforms, among others.

Platforms with a Parent Platform: Meta and Google

Meta

While Signal and Bluesky are both standalone platforms, some platforms are associated with a parent platform, which we can represent through the :parent property on the inet:service:platform form. Facebook, Instagram, and Threads, for example, are all platforms associated with the larger Meta platform, and are reflected as such in the modeling shown below:

inet:service:platform:parent::name=meta

A user would have separate accounts for each platform, such as a Facebook account and a separate Instagram account. These accounts would be linked on the backend as both platforms are under the same parent platform. From a modeling perspective, this would look like an inet:service:account node for each child platform, where the :profile property is set to a unique ps:contact node representing the user’s profile for their account on that platform. The query below lifts the accounts that an example user would have across several Meta platforms:

inet:service:account:parent::platform::name=meta

The inet:service:account nodes all have the :parent property set to the same overarching inet:service:account node linking the accounts on the Meta backend. This parent inet:service:account node also has the :profile property set to a unique ps:contact. If we have enough visibility to assess that there is one person controlling these accounts, we can represent that person with a ps:person node and link it to the ps:contact node associated with the parent inet:service:account.

Google Workspace

The Vertex Project’s use of Google Workspace is another example of multiple platforms associated with a single parent platform. The Storm query below lifts inet:service:platform nodes representing several of the platforms that are all part of the overarching Google platform:

inet:service:platform:parent::name=google

As a Vertex employee, I have access to Google’s platforms, including Gmail, Drive, Meet, and YouTube, among others. I modeled this by creating unique inet:service:account nodes for each platform and then using the :parent property to link them to an account associated with the overarching Google platform, similar to what we had done when modeling our previous Meta example.

This Storm query pivots from the inet:service:platform nodes shown above to the associated inet:service:account nodes:

inet:service:account:platform::name=google -> inet:service:account

Since I do not have unique profile information for each account, I simplified the modeling by creating one ps:contact node to represent my overall Google Workspace profile, and then linking it to the parent inet:service:account.

This level of modeling detail is reflective of our visibility in this scenario - we know that I am the person associated with these accounts, all of which use the same authentication account. We will not always have this degree of visibility, and can adjust the modeling accordingly. If we lack the knowledge that the accounts use the same authentication account, we would leave the :parent property on the inet:service:account nodes empty, and instead link each account with a unique ps:contact node capturing profile information for that account. We may link one or more of those ps:contact nodes to a ps:person node if we have identified a person associated with the account(s).

Instanced Platforms: Slack

Within Slack, users can create individual servers or instances within the overarching Slack platform. The Vertex Project, for example, maintains an internal, private Slack for employees, and a community Slack for customers and other Synapse users. We modeled both as inet:service:platform nodes, and used the :parent property to map both to Slack as the overarching parent platform, as seen with the Storm query below:

inet:service:platform:parent::name=slack

Although we did not set it here, we could have also used the :family property to further group the Vertex Project’s Slack instances. While Synapse Power-ups model instanced platforms with the :family property set, this is done solely as a convenience for the user. When it comes to decentralized platforms, which we’ll cover in a later case study, analysts can rely on the :family property to both group platforms and deconflict nodes.

Since The Vertex Project employees have access to both the internal and community Slack, we modeled two inet:service:account nodes for each employee: one associated with the internal Slack platform, and another associated with the community Slack platform. We can then record account information specific (and potentially unique) to each instance.

For example, my profile details differ between Vertex’s internal and community Slack instances. The inet:user:account representing my account on the public Synapse Slack has "savage (vertex)" as the username, and is linked to a ps:contact node that has the :name and :title properties populated with my name and "vertex project analyst", to reflect my Slack profile for that server. In a slight contrast, my account on Vertex’s internal Slack has "savage" as the username, while the associated ps:contact node contains just my name and email, which is all that appears on that account’s profile.

Thanks to our visibility in this scenario, we know that both my internal and community Slack accounts use the same authentication credentials, which we can model by using the :parent property to link both Slack accounts to a third account. That third account links to a ps:contact node with my profile information, which, in turn links to a ps:person node representing me, since we know that I am a person and associated with the authentication account and subsequent "child" accounts.

The following Storm query lifts the two child accounts: one representing my account on the community Synapse Slack, and the other representing my account on Vertex’s internal Slack:

inet:service:account:profile::name="mary beth lee" +:platform::parent::name=slack

When modeling channels and messages, we can reference the appropriate platform and account so that we’re properly documenting where a message was sent and which account sent it. The following Storm query lifts the Slack messages we’ve modeled:

inet:service:message:platform::parent::name=slack

A bot named "Slackbot" sent two of the messages shown in the image above. We used an inet:service:agent node to represent the Slackbot, and set the :creator property to the Slack account of the user responsible for creating it (in this case, Visi).

inet:service:agent:name=slackbot

Decentralized Platforms: Mastodon

How does an analyst use the inet:service:* forms to capture data pertaining to a federated platform, such as Mastodon? An analyst would represent a specific instance - such as @mastodon.social or @infosec.exchange - as a unique inet:service:platform node, leaving the :parent property blank as the servers are not connected to an overarching Mastodon platform. Instead, the analyst should use the :family property to group the servers as part of the Mastodon family, as seen in the query results below:

inet:service:platform:family=mastodon

Refining the Data Model for Improved Analysis

Replacing the inet:web:* forms with the inet:service:* forms has multiple benefits, including making the model more inclusive and allowing analysts to represent real-world data with improved accuracy. In our example use case, we were able to leverage the inet:service:* forms to capture platforms, accounts, and messages with greater fidelity, particularly when it came to modeling responses and other nuances surrounding how services were configured and where conversations took place. The modeling changes also gave us more options for how to display the modeled data, particularly when combined with the use of embed columns.

To learn more about Synapse, join our Slack community, check out our videos on YouTube, and follow us on Bluesky (or on X).