Skip to content

Features

What Priveloq Chat does, grouped by what you came looking for. Nothing on this page describes something the application does not do.

Messaging

Conversations that behave the way people expect a modern messenger to behave.

  • Direct conversations and group conversations, with a participant list the server enforces rather than the interface merely draws.
  • Real-time delivery over a persistent connection, with an ordinary request as the fallback when that connection is unavailable.
  • Delivery and read state, so it is clear whether a message arrived and whether it was seen.
  • Presence and typing indicators, throttled so that a keystroke handler does not become the busiest thing in the deployment.
  • Message history paged from the server, with the page size a deployment setting rather than whatever a client asks for.
  • A durable notification centre that works with no push provider configured at all.
  • Standards-based browser push where a deployment configures it - no native application, no vendor push service of ours.

Calls

Ring somebody from the conversation you are already in.

  • One-to-one audio and video calls, started from the conversation header.
  • Group calls, with the participant ceiling set by the deployment.
  • Screen sharing, granted as a capability in the signed join credential rather than by hiding a button.
  • Ring timeouts and abandoned-call handling enforced by a background service, never by a browser that may have been closed.
  • Call history, including the calls nobody answered.
  • Per-account limits on how often calls may be started and how often one conversation may be rung, which is the anti-harassment control.
  • No telephone dialling, no recording, no transcription and no live streaming.

Media

Files that stay behind the same authorisation as the conversation they were sent to.

  • Images, documents, audio, video, and voice notes recorded in the composer.
  • Uploads stored outside the web root, so no file is reachable by path alone; startup refuses a configuration that would place them inside it.
  • Every fetch and every download authorised against the conversation - a copied link is not a key.
  • The declared file type is checked against the actual bytes; an executable renamed to look like a picture is refused.
  • Embedded photograph metadata is removed before storage, so a shared picture does not carry its location with it.
  • Per-kind size limits, a cap on attachments per message, and a per-account upload rate limit.
  • Local disk or S3-compatible object storage, kept private either way.

Privacy

Conversations you would rather were not visible on a screen somebody else can see.

  • Priveloq Vault: selected conversations are kept out of the ordinary conversation list.
  • A hidden conversation is absent from search results and from notification detail until the vault is open.
  • The vault is unlocked with a secret separate from the account password, and the unlock is bound to one browser session.
  • An open vault closes itself after a period of inactivity, and can be closed on every device at once.
  • Repeated wrong attempts pause the vault and leave the account itself untouched.
  • A forgotten vault secret is replaced by proving the account - the old one is not stored in a form anybody, including an administrator, can read back.

Guest communication

One conversation for somebody outside the organisation, and nothing else.

  • Single-use invitation links that expire on their own and can be revoked before redemption.
  • The guest chooses a display name. No account, no password, no email confirmation.
  • Messaging, file sharing and voice notes inside the room, subject to what the deployment allows.
  • Audio calls, video calls and screen sharing, each individually switchable by the deployment.
  • A guest credential is valid for exactly one room and reaches no other conversation, no directory and no account.
  • Automatic removal of the room and its contents when the retention window closes, enforced by a background service.
  • A ceiling on how many rooms one host may have open at once.

Administration

The controls the people who answer for the deployment actually need.

  • Invitations: issue, track and revoke. There is no public registration to police.
  • Accounts and roles, with permissions granted to roles rather than written into the code that checks them.
  • Account suspension, which takes effect on the next request rather than at the next cookie expiry.
  • Session review and revocation, per device.
  • Multi-factor reset for somebody who has lost their authenticator.
  • Guest room oversight: which rooms are open, and the ability to end one - with no route into what was said in it.
  • A security audit trail of sign-ins, role changes, suspensions, invitations and revocations.
  • A read-only view of the effective configuration, so an operator can see what the deployment is actually running with.

Security

Summarised here, and set out properly on the security page.

  • Invite-only accounts. No public registration endpoint exists to be reached.
  • Multi-factor authentication, which policy can require of a role.
  • Account lockout after repeated failed sign-ins.
  • Authenticated by default: a page that does not state that it is public is not served to an anonymous caller.
  • Short-lived, per-participant conference credentials scoped to one room.
  • A content security policy with no wildcard in it, and inline scripts permitted by nonce rather than wholesale.
  • Rate limits on sign-in, password reset, invitation redemption, uploads, vault unlocks and this website's contact form.

Private communication without public signup.

Request access or sign in to your existing account. Accounts are created by invitation, so there is no public registration to work through.