Pingl: The First RABS Ping Function Is Live
Pingl has delivered its first real slice: a secure SMS action-page bridge that lets a user stuck on the location-related pending login branch use phone GPS to authorise the desktop flow.
That sentence hides a lot of machinery. The important version is simpler: RABS can now send a secure one-time phone link, collect explicit GPS consent, and let the desktop continue only after the normal account and permission gates run again.
This is not a bypass. That was the central safety rule. Location helps only the location pending branch. It does not approve inactive accounts, skip account approval, or override permission rules.
The Flow
The first pingl implementation is deliberately narrow:
- A user is blocked on the location-related
page_pendingbranch. - The desktop offers "Use phone GPS via pingl."
- The backend creates a pingl request with a secure token, pairing code, expiry, and audit trail.
- RABS sends an SMS link to the verified phone.
- The mobile page shows the pairing code and asks for explicit confirmation.
- GPS is requested only after the user taps confirm.
- The backend records the one-time location response.
- The desktop polls status, marks the local geo check fresh, and redirects through the normal session gate.
The token is the public-page auth. The mobile page does not load the admin shell and does not rely on a logged-in browser session. That is what makes it useful on a phone while keeping the action scoped to the one request.
What Was Built
The backend now has a reusable pingl.service.js plus authenticated and public token routes. The schema is queued as SQL rather than executed by agents, following the RABS rule that Brett controls database changes.
The desktop side extends page_pending so the button appears only for the location branch. It shows pairing status, expiry, and accepted/denied/failed states.
The mobile side is a standalone pingl.html page. It reads the token, displays the request, asks for confirmation, requests phone GPS only after consent, posts the response, and renders final accepted, denied, dismissed, expired, or invalid states.
The audit side reuses the existing emit/syslog path, so pingl lifecycle events can be traced without inventing a separate logging island.
Why This Matters
Pingl is a pattern, not just a page. The first payload is location because location was the immediate login blocker, but the architecture is a reusable SMS action-page bridge: request type, recipient, mode, buttons, expiry, linked entity, and optional payload.
That opens the door to other "send the user a secure action link" moments without building a bespoke portal every time.
This is just the start of the ping functions. There is more to come.