Multi-User
Collaboration.
PZLS supports multiple users working on the same data set. Each user has their own account with role-based access. Changes are synced in real-time via WebSocket. When conflicts happen (two users edit the same entity simultaneously), Pazator detects them and offers resolution.
Roles
Real-Time Presence
When multiple users are connected to PZLS, the LSAD dashboard shows connected clients with their username and role. Operations are broadcast to all connected clients via WebSocket so the recent ops list updates live.
Merge Conflicts
Conflicts occur when two users push changes to the same entity concurrently. PZLS uses
optimistic concurrency: each entity has a version counter. When pushing via
POST /api/sync/ops, you include the version you last saw.
If the server's version is higher, it returns a conflict instead of overwriting.
Conflict Flow
- User A pushes entity X (version 1). Server updates to version 2.
- User B pushes entity X (version 1). Server detects version mismatch → returns conflict with server's current data (version 2) and server's copy.
- B's client stores the conflict locally with both versions saved.
- B can resolve by: keeping server version, keeping local version, or using AI auto-solve to merge them.
Conflict Resolver UI
Access via System → Resolve Conflicts. Shows each conflicting entity with:
- Entity ID and server version
- Server's current data (read-only preview)
- AI Solve — sends both versions to Zor/Gemini/DeepSeek to produce a merged result
- Dismiss — removes the conflict without merging (local change is discarded on next push)
The AI Auto-Solve All button processes all pending conflicts at once. The AI receives both versions with instructions to preserve unique fields and merge conflicting ones intelligently. This requires an AI provider (Gemini or DeepSeek) to be configured.
Offline Queue
When the server is unreachable, push operations are queued in localStorage. The status indicator shows a clock icon with the queue count. Use System → Flush Queue to retry all queued operations when back online. The queue persists across page reloads.
Incremental Sync
For large datasets (1000+ entities), full pulls can time out. Use System → Incremental Pull instead. This uses cursor-based pagination to download data in chunks of 500 entities, avoiding timeouts and reducing memory pressure. The cursor is stored in localStorage and resumes from where it left off.
E2E Encryption
All data can be encrypted with AES-256-GCM before leaving the browser. Toggle it on in Settings → Security → E2E Encryption. Set a passphrase (min 8 chars). Data is encrypted client-side before push and decrypted on pull. The server never sees the plaintext. Without the passphrase, encrypted data on the server is unreadable.
Important: If you lose your passphrase, encrypted data cannot be recovered. All users collaborating must use the same passphrase to read each other's data.
- Assign one person as admin to manage accounts
- Use Incremental Pull for first sync on large databases
- If conflicts happen frequently, coordinate editing windows
- Test AI auto-solve on a few conflicts first to verify quality
- Share encryption passphrases out-of-band (not through PZLS)