Offline Feature for our Product

[Murali Thangaraj]

Hi Team,

We are evaluating offline functionality for our RMS and CAD web products and are currently analyzing the best approach for implementation. As part of this effort, several design, security, and operational questions have come up, and I would greatly appreciate your feedback based on your experience.

If you have implemented offline capabilities in a CJIS-compliant RMS, CAD, or other public safety application, I would be interested in learning how you approached the following:

• Have you implemented offline functionality in a CJIS-compliant RMS or CAD web application?
• What synchronization strategy worked best for your solution?
• How did you handle record conflicts during synchronization?
• How did you secure data stored locally on the device?
• What challenges did officers encounter while working offline?
• Would you recommend full offline functionality or limiting offline capability to draft creation and editing?
• Are there any CJIS, security, or operational concerns that should be considered before proceeding with implementation?

Any lessons learned, recommendations, or pitfalls to avoid would be greatly appreciated.

Thank you for your time and feedback.

Thanks,
Murali

[Eric Osterberg]

Hi Murali,

Thanks for reaching out — these are exactly the questions I've been chewing on for Tickets CAD (the open-source CAD I maintain). Short answer to each, then a note on how I'd want to engage further.

1. Have you implemented offline in a CJIS-compliant CAD?
Partially. Tickets CAD's NewUI is a PWA with offline shell + cached read state and draft authoring for mobile-unit work. It does not yet do full offline status changes / dispatching with conflict resolution — that's the next architectural layer, and the one your questions all converge on.

2. Synchronization strategy.
The pattern that holds up under real-world CAD load is hybrid: append-only logs (CRDT-style) for anything narrative — ICS-214 unit logs, action notes, message threads — because two officers writing simultaneously should interleave, not overwrite. Per-field last-writer-wins with vector-clock timestamps for status / location / simple metadata. A separate idempotent command queue with client-generated UUIDs for any API call that mutates shared state, so reconnects don't double-fire. PouchDB ↔ CouchDB is the proven reference architecture; Yjs / Automerge if you go full CRDT.

3. Record conflicts.
Three buckets by entity type:

• Append-only entities (logs, comments): no conflicts by construction.
• Per-field LWW (incident status, unit location): server merges deterministically, last server-acknowledged timestamp wins.
• Narrative-heavy free-text fields edited offline by multiple users: manual reconciliation UI with side-by-side diff. Every resolution gets an audit entry capturing what was discarded and by whom (CJIS §5.4.1).

4. Securing data at rest.
Web Crypto API (AES-GCM-256) over IndexedDB. Key derived per session from user passphrase via PBKDF2 (≥600k iterations) wrapped by a device-bound public key. Never persist plaintext CJI. Auto-wipe on N failed unlocks. The hard part is documenting the FIPS 140-3 posture in a way your CJIS auditor accepts — browser crypto is generally OK if you can map each primitive to its validated algorithm, but it takes paperwork. WebAuthn or a hardware key adds a real second factor that survives device theft.

5. Officer challenges.
The five we keep seeing:

• "Did it save?" — the offline/syncing/conflict UX bar is do-or-die.
• Stale lookups (NCIC, BMV, FCC, callsigns) — cache aggressively, but stamp the cache with last-fetched-at and dim stale rows.
• Status surprises — dispatcher reassigned the unit while officer was offline. The merge has to be obvious and acknowledged, not silent.
• Disk pressure on long shifts — explicit retention + eviction policy.
• End-of-shift unsynced records — device stolen / battery dead with unflushed writes. Solved partly by aggressive sync, partly by
  server-side incident-creation-from-incomplete-draft tooling.

6. Full offline vs. drafts-only.
Full offline is what officers actually need for weak-signal patrol, but the engineering bill is roughly 10× drafts-only and the CJIS documentation burden is much larger. My recommended posture: full offline read of recent shift state + full offline draft authoring, but any state change that affects other users (status, assignment, dispatching) is either online-only or queued with an explicit "tentative — awaiting sync" badge until the server acks. Officers get most of the value with most of the safety.

7. CJIS / security / ops concerns.
The ones you don't see in the obvious places:

• §5.5 session timeout when offline — what enforces it? Local timer + last-unlock window. Document the threshold.
• §5.6 offline reauth — cached credential verification with a maximum offline-window policy (24h is common; some states want 8h).
• §5.4 audit — local audit log must sync within agency policy; if the device is lost mid-shift, the server-side replication is your reconstruction story.
• §5.13 mobile device — the offline cache is the regulated boundary; MDM is effectively required for a real CJIS deployment.
• Data residency — some state CJIS agreements forbid CJI leaving the state at rest. Offline devices crossing state lines on mutual aid is a real gap.
• Wipe-on-tamper — a PWA cannot trigger this; you need a companion MDM agent or an OS-level managed app.
• Forensic recovery on lost device — what's the playbook for unsynced records? Define before you ship, not after.

---

On engaging further. Each of those answers compresses a couple of weeks of design work. I'm happy to keep trading notes at this level for free if it sharpens both our products — that's the point of having an open-source CAD in the conversation. If you want a deeper engagement (review of your sync design, threat model, CJIS auditor-prep, prototype review), I'd want to proceed in one of two ways:

1. Paid consulting — hourly or fixed-scope, NDA fine, your IP stays yours.
2. Open-source collaboration — if the offline layer you're building (or pieces of it) will be released under an OSI-approved license that the broader public-safety community can adopt, I'll contribute design time at no charge. Tickets CAD users would benefit from the same plumbing; that's a win for both of us.

Either path is fine — happy to chat about which fits where you're headed. If neither, the email above is still yours to use.

Regards,

Eric Osterberg
Tickets CAD — https://ticketscad.com
https://github.com/openises

--
You received this message because you are subscribed to the Google Groups "Open Source CAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-source-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAFZskHm-tdb43LqVgxbv_HcZgM%3D0qes6CkVHJ9gPynC%3DUs_WoA%40mail.gmail.com.

[Murali Thangaraj]

Eric,

Thank you for your quick response. I require some time to digest the response :). I will take a day and get back to you with questions if any. 

Thanks

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAJLaYFVjmJR4%3DmG848jK-fK6-uUNswaN6uvmVnp-zcuzt50wwQ%40mail.gmail.com.