Ditto Version 4.7.0 Increases Visibility and Security in Your Local Mesh

Ditto version 4.7.0 is here! It brings significant advancements to Ditto's mesh presence, now allowing peers to communicate information about themselves to other peers. The presence graph, commonly referred to as presence, represents the current state of the mesh from a specific peer’s point of view. These new features expand the types of data developers can define and collect from peers, such as how peers interact with each other. This unlocks visibility into mesh health that improves real-time decision-making.

This change aims to give developers the necessary tools to gain visibility over the devices in the local mesh and protect their networks against unauthorized, outdated, or potentially malicious entities.

Overview of 4.7.0

Increase visibility of the mesh with peer metadata: The new peer metadata APIs allow developers to define any application-specific information about each peer, such as role and state, and sync this information to other peers in the local mesh. This enables developers to have a much better understanding of the types of peers currently in their mesh and make real-time decisions based on this information.

Improve mesh security and control with the connection request handler: The new connection request handler API puts developers in full control of their mesh network. It gives peers the ability to intercept and evaluate new connections, allowing them to reject connections to known bad actors or problematic peers.

What is Peer Metadata?

Peer metadata allows users to set user-specific information on a given peer and enables peers to share and view that information with all others in the mesh. Developers can utilize this feature to define peers in any way they want, such as application versions, roles, or any other critical business logic. Accessible through these APIs, developers can use this information to confirm whether or not devices are on updated versions, if the correct devices are present in their mesh, and more based on defined business logic. This visibility empowers developers to quickly make critical business decisions to ensure proper mesh health at all times.

Take a look at the video below for an overview of why we decided to introduce peer metadata.

Introducing Peer Metadata in Ditto Version 4.7

Peer metadata is the cornerstone of Ditto version 4.7.0 and the first key feature in a push to bolster peer identification within the local mesh. In a future release, we will use peer metadata to improve observability in Ditto's Swift and Android Presence Viewer, allowing all end-users to see a real-time view of each peer's metadata.

What is a Unique Peer Identifier?

Alongside the custom changes developers can now make to peer metadata, each peer now also has a unique string identifier, `peerKeyString`, that is unique across all sessions as it’s tied to a specific storage directory in Ditto.

With this feature, developers can now use a stable identifier to identify and track specific peer behaviors across sessions, improving the level of detail in logs and enabling much easier debugging of specific peers.

What is the Connection Request Handler?

This new API allows peers to evaluate the properties of the connection request, including peer metadata, and decide whether or not to authorize the connection request. Whenever two peers attempt to establish a connection, the Connection Request Handler API is called, and the peer can use the Connection Request object, which includes the `peerMetadata` and `peerKeyString`, to determine if they want to allow or deny the connection from taking place.

Use Cases

Take a restaurant, for example. Peers here could include point-of-sale, printers, kiosks, kitchen displays, and handhelds for waitstaff. Each type of device in the store has a unique role. With peer metadata, these roles can now be easily defined. This means that team leads can more easily keep track of what devices are present in the mesh - if your kitchen display drops out of the mesh, you’ll be the first to know about it. End-users can utilize this enhanced visibility to make critical business decisions quickly.

In terms of security and the `connectionRequestHandler`, you can use the defined `peerMetadata` and `peerKeyString` to label known peers as lost or unauthorized. In the restaurant example from above, this would ensure that lost or stolen devices wouldn’t be allowed to sync with peers in the mesh should the device return to the premises.

How it Works

Developers can easily implement these features. Let’s look a quick example using the Swift SDK. In this example, peers will set, read, and reject incoming connections based on an `applicationVersion` field in each peer’s `peerMetadata`. Below, we will first set the application version for a given peer with the new `peerMetadata` functionality. Setting the metadata will allow other peers in the mesh to read and log which peers are on which version of the application.

1. Setting Metadata for a Peer

Below we are creating a new field called `applicationVersion` and setting its value to `2.0`. This will be shared with other peers in the mesh.

// setting peer metadata for a given peer
try ditto.presence.setPeerMetadata(["applicationVersion": "2.0"])

2. Reading metadata of remote peers:

Now that we know peers will self-declare their application version in the peer metadata, we can add some code to iterate over the presence graph and log the specific application version for each peer in the mesh.

// get array of remote peers
let remotePeers = ditto.presence.graph.remotePeers

for peer in remotePeers {
     print(peer.peerMetadata.applicationVersion)
}

Now, all peers within the local mesh can read the `applicationVersion` of a connecting peer. Now, what if you don’t want peers on 2.0 to communicate with peers on outdated versions?

3. Install a `ConnectionRequestHandler`

Peers on 2.0 can actively reject connections from peers with `applicationVersion` 1.0 by using the connection request handler API.

ditto.presence.connectionRequestHandler = { connectionRequest in
    // if the application version is 1.0 deny the connection
    if (connectionRequest.peerMetadata.applicationVersion == "1.0") {
        return .deny
    }

    // otherwise allow the connection
    return .allow
}

This type of connection request functionality can be used to support many different business cases, such as the example discussed in the Use Cases section above. Make sure to define important business logic in your peer metadata to expand your teams' real-time visibility and streamline decision-making!

Getting started

These features are now available to all Ditto users. Start enhancing your mesh network's presence information and security today by signing up in the Ditto Portal and checking out our comprehensive documentation and release notes. Access the Portal by clicking "get started" here or in the navbar.

We want to hear from you!

Your insights are invaluable to us. Explore the new features and let us know your thoughts. For feedback, support, or more information, submit a request ticket through the Ditto Portal, fill out the contact us form, or reach out on social media. Thank you for your continued support, and we can't wait to see how you leverage Ditto to transform your business.