Skip to main content
To get realtime updates about changes to presence data, use the Presence API. This article includes instructions on how to implement Ditto’s Presence APIs to enable the following end-user functionality for network monitoring and management within your app:
  • Setting and updating peer-specific information, such as name, role, and location.
  • Viewing information about other peers currently connected in the mesh.

​
Accessing Presence APIs

To access API methods for mesh presence functionality, call the presence namespace on the root Ditto object: 

ditto.presence

​
Presence Graph

Once discovered in the mesh, peers automatically establish a presence graph by advertising their device presence within the mesh and forming network connections with other connected peers. The presence graph is a data structure representing the current state of the mesh from a specific peer’s point of view. You can integrate the presence graph into your app to enable end-user functionality like network monitoring, management, and transport optimization. For example, once implemented, end users can input personal information, such as their name, and inspect remote peers connected within the mesh. For more information, see DittoSwiftTools on GitHub.

​
Accessing Presence Graphs

To view your current presence graph: 

let presenceGraph = ditto.presence.graph
Once invoked, Ditto returns the following object, allowing you to perform actions like displaying the status of connected peers and managing network resources: 
{
  localPeer: Peer;
  remotePeers: Peer[];
}
The localPeer is the metadata set by the end user within your app. The remotePeers property provides an array of the other client devices connected to the mesh. (See End-User Defined Metadata for more information.)

​
Observing Presence Graph Modifications

To monitor and handle changes observed to the presence graph, call the change handler with the updated graph object as follows:
Make sure the observer response object remains in memory during runtime; otherwise, Ditto removes it during the periodic garbage collection process running in the background, resulting in the change handler no longer being triggered.
Android: Always close presence observers explicitly. On Android, if a PresenceObserver is garbage collected without being closed first, its finalizer runs on Android’s FinalizerDaemon thread. If the teardown performs any I/O (for example, due to a custom log callback registered via setCustomLogCallback), the finalizer can exceed Android’s hard 10-second timeout, resulting in a java.util.concurrent.TimeoutException crash.To avoid this, always call close() on the observer when it is no longer needed. If you are wrapping the observer in a Kotlin callbackFlow, ensure the awaitClose block calls observer.close() and that the Flow’s coroutine scope is properly cancelled — for example, by collecting within lifecycleScope.

let presenceObserver = ditto.presence.observe { presenceGraph in
// observe changes to the presence graph
}

​
Closing Presence Observers

When you no longer need presence updates, close the observer to release resources: 
presenceObserver.close()
In Kotlin v5, presence.observe() returns a Flow<DittoPresenceGraph> instead of a DittoPresenceObserver. When you collect the Flow within a lifecycle-aware scope like lifecycleScope, cancellation and cleanup are automatic — no manual close() is needed.

​
Peer Key Identifier

Once discovered in the mesh, each peer device running Ditto is automatically assigned a peer key.

​
Reading Peer Keys

View your local device’s peer key or the peer key identifying a specific remote device:
  • To retrieve the peer key for the current peer:

ditto.presence.graph.localPeer.peerKeyString
  • To retrieve the peer key for a remote peer:

let remotePeers = presenceGraph.remotePeers
let firstPeer = remotePeers.first!

let peerkeyString = firstPeer.peerKeyString

​
End-User Defined Peer Metadata

Using the peer-metadata property, you can provide each peer connected within the mesh the ability to set and view information about themselves or read information defined by other peers within the mesh.
Data added to the peer metadata object is shared during the connection handshake. Large data payloads may impact performance on low-bandwidth connections, such as BLE.
The following table provides an overview of key considerations to know before setting peer metadata, as well as Ditto’s recommended best practices to ensure optimal mesh performance and avoid potential issues:
ConsiderationBest Practice
Peer metadata syncs across the mesh with each new connection. Therefore, sharing large data over low-bandwidth transports, such as Bluetooth Low Energy (LE), and low-quality connections may slow or disrupt the connection process.Keep the size of peer metadata to a minimum, especially when syncing over Bluetooth LE or similar low-bandwidth transports. This is because peer metadata exceeding 128 KB, the maximum limit, results in the operation failing and Ditto throwing an error.
Peer metadata is visible to all peers connected in the mesh.Include only non-sensitive information in peer metadata.

​
Setting Local Peer Metadata

To implement functionality providing end users the ability to define metadata, call the setPeerMetadata API method as follows: 

// Setting via Object
try ditto.presence.setPeerMetadata(["location": "inside"])

// Setting via JSON String
let jsonData = "{location:\"inside\"}".data(using: .utf8)!
try ditto.presence.setPeerMetadataJSONData(jsonData)

​
Reading Local Peer Metadata

Once set, inspect the metadata: 

// Reading from the presence namespace
ditto.presence.peerMetadata

// Reading from the presence graph
ditto.presence.graph.localPeer.peerMetadata

​
Reading Remote Peer Metadata

To inspect the metadata set by all other peers in the mesh: 

let remotePeers = ditto.presence.graph.remotePeers
let firstPeer = remotePeers.first!

let peerMetadata = firstPeer.peerMetadata

​
Identity Server Metadata

Identity server metadata is application information that is set when the user is authenticating. As part of the authentication process the application developer can provide information about the peer that is added to the user’s peer object and shared with other peers in the mesh. The identity server metadata is signed by the identity server and validated by all peers reading to prevent spoofing of the information.

​
Setting Identity Server Metadata

The identity server metadata is set during the See End-User Access>Setting Identity Server User Metadata for specifics.

​
Reading Local Peer Identity Server Metadata

To inspect the identity server metadata of the local peer doing the following: 

// Reading from the presence namespace
ditto.presence.identityServiceMetadata

// Reading from the presence graph
ditto.presence.graph.localPeer.identityServiceMetadata

​
Reading Remote Peer Identity Server Metadata

To inspect the identity server metadata set by other peers connected within the mesh: 

let remotePeers = ditto.presence.graph.remotePeers
let firstPeer = remotePeers.first!

let peerMetadata = firstPeer.identityServiceMetadata