Authentication · Friction removal · Telephony
Trust Based Auth
Trust based auth removes sign-up, passwords, and repeat verification. Successful interactions earn direct access. Telephony connects calls to web intent, and SMS activates a remembered browser session. Returning users act directly while the server checks current permission.
First interaction Establish trust and a browser session
- Start in the appIntent saved, no sign-up
- Confirm by phoneCall linked to web intent
- Earn trustSuccessful fulfillment confirmed
- Activate browserSMS code establishes session
Return visits Less work for the user; permission still checked
- ReturnBrowser remembers the session
- Check permissionServer checks current trust
- Act directlyNo repeat call or SMS code
Friction removal by design Link to heading
The app lets people express intent before asking them to establish an identity. Their work is already captured when the first call confirms the interaction, and successful fulfillment earns a shorter path next time.
Trust carries forward across visits. SMS activation establishes the browser session; it does not interrupt every subsequent action. A new browser or an expired session needs activation again.
Telephony integration Link to heading
The phone call arrives with context. An Asterisk/GSM gateway sends call events to the web application, where the caller’s phone number is connected to saved intent. An operator can see what the person has already selected. If there are multiple candidate carts, a short cart code resolves the match.
Inbound call Bring the user's web context into the conversation
- User callsFrom their phone
- Asterisk/GSM gatewayAuthenticated call webhook
- Web applicationMatch caller to saved intent
Outbound SMS Connect the phone to a remembered browser session
- Web applicationQueue activation code
- GSM gatewayDeliver SMS
- User's phoneCode activates browser session
The same integration carries SMS activation back to the user’s phone. Calls, saved web intent, and session activation become parts of one flow, reducing repeated explanations and data entry.
Trust follows outcomes Link to heading
Fulfilled commitments unlock direct access. Recorded no-shows restrict it. An operator confirms the outcome; the server updates the user’s trust state.
Trust updates Real outcomes determine permission
Fulfillment confirmed
No-show recorded
Every direct checkout checks the current trust state and the phone-linked session.
New phone numbers start as UNKNOWN. A confirmed fulfillment changes the user to TRUSTED; a recorded no-show changes them to NOT_TRUSTED. The current implementation uses completed orders as the evidence for these decisions.
The model also supports MEDIUM, which permits direct orders with the possibility of operator review. The outcome handler currently assigns the trusted and restricted states; it does not automatically assign this intermediate state.
Keep permission current Link to heading
A remembered browser still needs current permission. SMS activation establishes access to a phone-linked session. The outcome history determines whether that user is eligible to act directly.
At every direct checkout, the server checks session validity, the matching phone number, and the user’s current trust state. A restriction takes effect even if the browser still has a valid session.
Session tokens are hashed on the server and carried in an HttpOnly cookie. Activation codes expire and have limited attempts. Trust changes record the previous state, new state, related order, and responsible operator.
Implementation Link to heading
Built with Next.js, TypeScript, Prisma, and SQLite, with Asterisk/GSM for calls and SMS. The operator workspace brings call context, saved carts, fulfillment, and trust decisions together.