> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neuro-tech.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Clock synchronization and geospatial data

> Estimate clock offsets and exchange location-bound objects through federated services

Time and location are shared infrastructure concerns: sensor ordering, contract deadlines, subscription expiry, and moving assets all depend on them.

## Clock synchronization

| Item                  | Value                             |
| --------------------- | --------------------------------- |
| Namespace             | `urn:nfi:iot:synchronization:1.0` |
| Clock request/result  | `<req>` / `<resp>`                |
| Source request/result | `<sourceReq>` / `<sourceResp>`    |

The client records UTC time `ct1`, sends `<req>`, receives the source UTC time `st`, and immediately records `ct2`.

```text theme={null}
estimated latency     l  = ((st - ct1) + (ct2 - st)) / 2
estimated clock delta Δt = ((st - ct1) - (ct2 - st)) / 2
```

This assumes approximately symmetric path latency. Take repeated samples, reject outliers, and smooth a recent window instead of adjusting from one exchange.

```xml theme={null}
<iq type='get' id='clock-1' to='source@example.net/timer'>
  <req xmlns='urn:nfi:iot:synchronization:1.0'/>
</iq>

<iq type='result' id='clock-1'>
  <resp xmlns='urn:nfi:iot:synchronization:1.0'
        hf='29774635776511' freq='2630640'>2026-08-19T10:15:32.5102314Z</resp>
</iq>
```

`hf` and `freq` optionally describe a high-frequency monotonic timer. Its origin can change after restart or failover, so never persist it as an absolute timestamp. `<sourceReq>` discovers which external source another entity follows.

## Geospatial service

| Item      | Value                                                     |
| --------- | --------------------------------------------------------- |
| Namespace | `urn:nfi:iot:geo:1.0`                                     |
| Commands  | `subscribe`, `unsubscribe`, `publish`, `delete`, `search` |
| Events    | `added`, `updated`, `removed`                             |

A broker component stores transient or persistent objects with latitude, longitude, optional altitude, content/URI payload, identifier, and optional lifetime. Clients can search or subscribe using Mercator bounding boxes.

```xml theme={null}
<iq type='set' id='geo-1' to='geo.example.net'>
  <subscribe xmlns='urn:nfi:iot:geo:1.0'
             minLat='59.30' maxLat='59.40'
             minLon='17.90' maxLon='18.20'
             ttl='60'/>
</iq>
```

The result supplies a subscription `id` and accepted `ttl`. Renew before expiry with margin. Subscriptions end when TTL elapses and can end when the client connection closes. If `minLon` exceeds `maxLon`, the box wraps across the antimeridian.

## Geospatial security

* Enforce service-level limits on object count/size, lifetime, subscription count, and bounding-box area.
* Bind update/delete and subscription IDs to the creator's bare JID.
* Publish only the precision required by the use case.
* Treat location as sensitive personal or operational data and apply provisioning/consent.
* Validate payload media types and URI schemes before rendering or fetching content.