Beeps Safe V2S 26.3 — sender-receiver-terminal.html Description
The sender-receiver-terminal.html file is the combined Beeps terminal interface. It is designed as a single hosted HTML page that gives the user both sides of the Beeps system in one screen: a sender panel for sending short Beeps to another receiver PIN, and a receiver panel for receiving Beeps sent to the user’s own PIN. The file functions as a terminal-style control surface for the Beeps Safe V2S system. It is not merely a public dialer page. It is the higher-control sender/receiver operator screen that combines identity, receiver polling, sender keypad entry, queue checking, push-aware receiver behavior, and backend communication.

The terminal is intended to operate inside the hosted Firebase web app and inside the Android WebView wrapper. In the Android APK, MainActivity.kt loads the hosted Beeps interface, and this terminal page can be opened from the app menu or directly by URL. The terminal remains a web interface, but it interacts with the Android layer when native push registration, audio alerts, or WebView bridge behavior is available. This lets the same terminal file operate as a browser page, a Firebase-hosted web page, and an Android WebView screen.

The terminal’s main role is to let a signed-in Beeps user send and receive Beeps without exposing a personal phone number. The receiver side uses a private receiver PIN and a backend-issued receiver token. The sender side lets the user enter another receiver PIN and a short payload. The backend receives sender requests through /api/enqueue and receiver requests through /api/recv/poll or /api/recv/poll/live. The terminal page is therefore the user-facing control panel, while functions/index.js remains the enforcement layer for routing, token validation, replay protection, credit deduction, and monthly-cap control.

The terminal file should be understood as a single-page client. It contains the visible layout, buttons, keypad, input fields, status text, JavaScript event handlers, API calls, and receiver polling behavior needed for terminal use. It does not own server authority. It can request a token, display the receiver PIN, send a Beep, poll for waiting Beeps, and show the result, but it cannot decide whether credits exist, whether a token is valid, whether a monthly plan is active, or whether delivery is allowed. Those decisions are handled by the backend.

Terminal Menu and Main Screen Areas
The terminal page is normally divided into several functional areas. The first area is the header or title area. This identifies the page as the Beeps sender/receiver terminal and may include navigation back to the main menu. The header gives the user a clear way to understand that they are in the full terminal, not just the public dialer. In a hosted WebView build, this header may also reflect Electrolips branding, Beeps Safe V2S naming, or the current version line.

The second area is the account or receiver identity area. This is where the user’s receiver PIN is shown after sign-in or receiver registration. The receiver PIN is the number other people use to send Beeps to this user. The terminal may include a refresh identity function, a reset/reroll identity function, or a receiver-token refresh function. These should be described separately because they do different things. Refresh Identity normally means keeping the same receiver identity where possible while refreshing the receiver token or local receiver state. Reset Identity or Reroll means replacing the receiver PIN and creating a new receiver identity path.

The third area is the receiver-control area. This area is used to check for incoming Beeps. It may include buttons or controls such as Check, Poll, Start Live, Stop Live, Clear, or Receiver Status. Normal polling checks for waiting messages on demand. Live polling repeatedly checks for messages while the receiver is active. The terminal should make clear that empty checks do not deduct credits. Credits are deducted only when a queued Beep is actually delivered to the receiver by the backend.

The fourth area is the sender-control area. This area is used to send a Beep to another receiver PIN. The user enters the target receiver PIN, enters the Beeps payload, and presses Send. The sender side should normalize or limit payload entry before sending, but the backend remains the final authority. The current system supports a 64-character payload limit for the public dialer and terminal. The terminal should prevent accidental over-entry, but the backend must still enforce the final 64-character rule.

The fifth area is the keypad or keyboard area. This area gives the user a pager-style input surface. It may include number keys, symbol keys, letter keys, backspace, clear, space, send, and possibly quick command keys. The keypad makes the page feel like a communications terminal rather than a normal text form. It also lets the same interface work well on phones, tablets, touchscreens, kiosks, WebView wrappers, and future wearable or accessory interfaces.

The sixth area is the status/log area. This area displays whether a send succeeded, whether a receiver poll returned messages, whether live mode is running, whether a token is missing or expired, whether credits are insufficient, or whether a backend request failed. The terminal should show enough status for the user to know what happened without exposing private backend details. For example, it can say that a Beep was sent, a Beep was received, the receiver is live, no messages are waiting, credits are low, or sign-in is required.

The seventh area is the navigation/menu area. This area may include links back to menu.html, buy.html, receiver-only pages, public dialer pages, account pages, support pages, privacy/legal pages, or community pages. In the Basemaster no-assets release, these links should point to hosted pages rather than bundled local APK files. That keeps the Android app small and lets the hosted deployment remain the source of truth for interface updates.
Receiver Operation

To operate the receiver side of the terminal, the user first opens the terminal page and signs in if required. Once signed in, the terminal retrieves or displays the user’s receiver PIN. This PIN is the user’s Beeps address. Other people can send Beeps to that PIN through the public dialer, another terminal, or another approved sender interface.

After receiver identity is available, the terminal requests or uses a receiver token. The receiver token is not the same thing as the visible PIN. The PIN is the address. The token is the private authorization credential that lets the receiver retrieve queued messages for that PIN. The terminal should store or hold the token only as needed for authenticated polling. The backend validates the token before releasing messages.

The receiver can manually check for waiting Beeps by pressing the normal check or poll button. This calls the backend polling endpoint with the receiver PIN and receiver token. Updated terminal behavior sends the token through the Authorization header using Bearer-token transport. The backend reads the Bearer token first. Temporary query-token fallback may still exist for older clients, but the hardened future version should use Bearer-only receiver polling.

If no messages are waiting, the terminal displays an empty or no-message status. Empty polling does not deduct credits. If messages are waiting and the token and entitlement are valid, the backend delivers the queued Beep to the terminal. Delivery is the point where the backend deducts one credit or consumes one monthly-cap usage unit. This is important because sending a Beep does not itself deduct receiver credits. Actual receiver delivery is what triggers deduction.

The receiver may also use Live mode. Live mode repeatedly checks for incoming Beeps while the terminal is open. This is useful when the user wants the terminal to behave like an active pager console. Live mode should not open extra receiver windows. It should keep receiving messages in the terminal’s receiver panel and display them one by one as they arrive. Live polling and normal polling must have the same billing rule: delivered messages consume credit or monthly usage, empty polls do not.

If the Android wrapper is being used, the receiver can also rely on push notification signaling. When a sender queues a Beep, the backend may send an FCM push notification to the registered Android device. That notification should only signal that a Beep is waiting. It should not expose the full payload in the notification body. The terminal or receiver page then retrieves the actual Beep through authenticated polling.

Sender Operation
To operate the sender side of the terminal, the user enters the target receiver PIN. The target PIN is the destination address. The terminal should strip or ignore non-digit characters where PIN rules require numeric receiver identifiers. The backend also normalizes the PIN before accepting or rejecting the request.

After entering the destination PIN, the user enters the Beeps payload. The payload is the short message or code being sent. Beeps payloads are intentionally short paging payloads, not long chat messages. The current terminal behavior supports up to 64 characters. The payload may include numbers, letters, spaces, and approved symbols such as star, pound, dot, at-sign, or dash depending on the deployed sanitizer. The frontend can guide the user, but the backend enforces the final accepted character set and length.

The user then presses Send. The terminal creates an enqueue request to the backend route /api/enqueue. The request includes the target PIN, the payload, and a unique request_id. The request_id is required for replay prevention. If a send request is accidentally repeated, the backend can reject the duplicate request_id instead of inserting the same Beep twice into the queue.

A successful send means the backend accepted the Beep into the pending queue for the receiver PIN. It does not mean the receiver has already read the message. It also does not mean the receiver’s credit was deducted at send time. The message is waiting in the backend queue until the receiver polls and retrieves it. If the receiver has a registered Android device, the backend may send a push signal telling the receiver that a Beep is waiting.

If sending fails, the terminal should show a clear error state. Typical failure reasons include missing PIN, invalid PIN, missing payload, payload too long, missing request_id, duplicate request_id, route rate limiting, or server error. The user-facing terminal should keep the explanation short enough to be usable, while the backend keeps the exact error code for debugging and API consistency.
Keyboard and Keypad Operation

The terminal keyboard is the user’s main input tool. It should operate like a pager-style communications keypad. The user can select the destination PIN field, press number keys, and build the receiver PIN. The user can then select the payload field and enter the Beeps payload using the keypad or the device keyboard. On phones and tablets, the onscreen terminal keypad makes the page usable even when the normal device keyboard is inconvenient.

Number keys insert numbers into the currently active field. When the PIN field is active, number keys add digits to the receiver PIN. When the payload field is active, number keys add digits to the message payload. This dual-use behavior lets the same keypad control both addressing and message entry. The terminal should make the active field visually obvious so the user knows whether they are typing the destination PIN or the message payload.

Letter keys insert letters into the payload field. If the terminal includes a letter keyboard or alphanumeric input mode, letters should normally be capitalized or normalized to the accepted Beeps payload format. Beeps payloads are meant to be short, clear paging strings. The terminal should avoid turning the payload box into a long chat box.
Symbol keys insert approved Beeps symbols. Common symbols for a pager-style Beeps payload may include star, pound, dot, at-sign, dash, and space.
These symbols are useful for short codes, handles, callback markers, location-style notation, or prearranged distress and status codes. The backend sanitizer should still reject unsupported symbols even if a modified client attempts to send them.
The Space key inserts a space into the payload. The Clear key clears the active field or clears the current message entry, depending on how the file is wired. The Backspace key removes the last character from the active field. A Reset or Clear All function may clear both the target PIN and payload so the user can start a new send operation. These controls are important for touch operation because the user may not always have a physical keyboard.

The Send key submits the current target PIN and payload to the backend. The Send key should not work if the target PIN is missing or if the payload is empty. It should also prevent obvious over-limit messages before the backend request is made. A good terminal implementation disables Send while a request is already in progress to reduce accidental double sends. The backend request_id replay rule provides a second layer of protection.

The Enter key on a physical keyboard may be used as a send shortcut if the payload field is active, but this should be handled carefully. On some devices, Enter may insert a newline or trigger form submission. Because Beeps payloads are short one-line messages, the terminal should either prevent multiline entry or normalize it safely. The preferred behavior is a single-line payload box with explicit Send control.

The keyboard should support fast operation. A user should be able to type a receiver PIN, type a short code, send it, clear the message, and send another Beep without leaving the terminal. For receiver operation, the user should be able to start live mode and keep the terminal open while incoming Beeps appear in the receiver log.

Menu Options and What They Are For

The Home or Main Menu option returns the user to the main Beeps menu page. This is useful when the user wants to leave the terminal and open other parts of the hosted app, such as the public dialer, receiver-only page, buying page, downloads page, account page, or legal/support pages.
The Receiver option opens or focuses the receiver side of the terminal. This is used to view the user’s receiver PIN, check receiver status, request a receiver token, start polling, or start live polling. The receiver section is for receiving Beeps sent to the user’s own PIN.

The Sender option opens or focuses the sender side of the terminal. This is used to enter another person’s receiver PIN and send a short Beeps payload. The sender section does not require access to the receiver’s private token. It sends to a destination PIN through the public enqueue route.

The Live Receiver or Start Live option turns on repeated receiver polling. This makes the terminal behave like an active receiving console. While live mode is active, the terminal keeps checking for new messages. Incoming messages should appear inside the terminal receiver log. Live mode should not deduct credits unless a message is actually delivered.

The Stop Live option turns off repeated receiver polling. This is useful for saving battery, reducing network activity, or stopping receiver checks when the user is done monitoring the terminal. Stop Live should not delete the receiver PIN or token. It only stops the repeated polling loop.

The Check or Poll option performs a one-time receiver check. This is used when the user does not want continuous live mode. A one-time check asks the backend whether messages are waiting and retrieves messages if allowed. Empty checks do not consume credits.

The Refresh Identity option should refresh the receiver’s token or receiver state without necessarily replacing the receiver PIN. This is useful when a receiver token expires, the page reloads, the Android WebView state changes, or the receiver needs to re-register with the backend. Refresh Identity should be kept separate from Reset Identity.

The Reset Identity or Reroll option replaces the receiver identity. This may generate a new receiver PIN and new token metadata. This is a stronger action than Refresh Identity because it can make the old PIN unusable or no longer preferred. It should be treated as an identity-change action.

The Register Push or Enable Notifications option connects the receiver identity to the Android FCM token when the app is running inside the Android WebView wrapper. The terminal or receiver page sends the receiver PIN, receiver auth token, FCM token, and platform value to the backend. This allows the backend to notify the device when a Beep is waiting.

The Buy Credits or Plans option opens the payment page. The terminal itself should not grant credits. It should send the user to the hosted buy page where Stripe or PayPal checkout/order creation is handled. After payment completion, webhook processing on the backend grants credits or activates monthly capped plans.
The Clear Log or Clear Screen option clears the visible terminal output. It should not delete backend messages unless the messages were already delivered. It is mainly a visual cleanup function. It helps the user keep the terminal readable during repeated testing or active use.
The Help, Terms, Privacy, Support, or Community links are informational and support routes. In the Basemaster hosted model, these links should go to the hosted Beeps/Electrolips pages rather than local APK assets. This lets legal/support wording be updated without rebuilding the Android wrapper.
How a User Sends a Beep from the Terminal

First, the user opens sender-receiver-terminal.html from the Beeps menu or Android WebView app. The sender panel is used when the user wants to send a Beep to someone else. The receiver panel is used when the user wants to receive Beeps sent to their own PIN.

Second, the user enters the receiver PIN of the person they want to contact. This PIN is the destination. It is not the sender’s own private token. It is the public-facing pager-style receiver number.

Third, the user enters the Beeps payload. The payload should be short and direct. The terminal supports short paging messages up to the current limit of 64 characters. The user can type with a device keyboard or press the terminal keypad buttons.

Fourth, the user presses Send. The terminal sends the PIN, payload, and request_id to /api/enqueue. If the backend accepts the request, the terminal shows a sent or queued status. The message is now waiting for the receiver to retrieve it.

Fifth, if the receiver device is registered, the backend may send an Android push signal to the receiver. The push signal tells the receiver that a Beep is waiting. The actual message is not supposed to be exposed inside the notification body.

Sixth, the receiver retrieves the Beep by opening the app or terminal and polling through the authenticated receiver endpoint. The backend validates the receiver token and PIN before releasing the message.

How a User Receives a Beep in the Terminal
First, the user opens the terminal and signs in if required. The receiver section should display the user’s receiver PIN or provide a way to register o
r refresh receiver identity.

Second, the terminal obtains or uses a backend-issued receiver token. This token is used for authenticated polling. The token should be sent using the Authorization: Bearer format in the current updated client behavior.

Third, the user presses Check or starts Live mode. Check performs a one-time poll. Live mode repeatedly polls while active. Both modes use backend receiver polling routes.

Fourth, if no Beeps are waiting, the terminal displays a no-message or empty result. No credit is deducted for an empty poll.

Fifth, if a Beep is waiting and the receiver has valid authorization and entitlement, the backend returns the message to the terminal. The terminal displays the received Beep in the receiver output area or log.

Sixth, after delivery, the backend deducts one credit or applies one unit of monthly-cap usage. The terminal may display the remaining credit value returned by the backend. The frontend should treat that value as display information only, because the backend is the source of truth.
Single-File Importance

The sender-receiver-terminal.html file is important because it is a complete operational Beeps console in one HTML page. It combines sender entry, receiver identity, receiver polling, live mode, keyboard input, status display, and backend API handoffs. It is the best single file for demonstrating how Beeps works as a controlled-contact pager system rather than only a static webpage or ordinary contact form.

The file also demonstrates the separation between interface and authority. The terminal gives the user controls, but the backend enforces the rules.

Sending is handled by /api/enqueue. Receiving is handled by /api/recv/poll and /api/recv/poll/live. Device notification registration is handled by /api/device/register. Receiver-token issuance is handled by /api/receiver/token. Payment and entitlement changes are handled through checkout routes and webhook processing. The terminal is the control panel, not the enforcement engine.

For the Basemaster no-assets release, this terminal file is hosted on Firebase Hosting instead of being bundled into the APK assets. The Android Web
View wrapper loads the hosted page. This means the terminal can be updated on the hosted deployment without rebuilding the APK, while the APK continues to provide the Android shell, native notification support, and WebView environment.

Beeps Safe V2S 26.3 — beeper-receiver-firebase.html Description
The beeper-receiver-firebase.html file is the dedicated receiver interface for Beeps Safe V2S. Its main purpose is to let a signed-in user create, view, refresh, and operate a private Beeps receiver identity. The receiver identity is represented by a receiver PIN. Other people can send Beeps to that PIN through the public dialer, sender/receiver terminal, or other approved sender interfaces. The receiver page is where the user checks for waiting

Beeps, receives delivered Beeps, registers the Android device for push notifications, and maintains receiver-side state.

This file is separate from the public dialer and separate from the combined sender/receiver terminal. The public dialer is mainly for sending to a PIN. The sender/receiver terminal combines sending and receiving in one operator screen. The receiver HTML file is focused on the receiving side only. It is the cleaner page for users who only want to monitor their own Beeps receiver address and retrieve incoming Beeps.

The receiver page runs as a hosted Firebase web page and can also run inside the Android WebView wrapper. In the Basemaster no-assets Android build, this file is not intended to be packaged as a local APK asset. Instead, the Android wrapper loads the hosted Beeps interface from Firebase Hosting. That means receiver behavior, receiver wording, link changes, and UI changes can be updated through the hosted web deployment rather than rebuilding the APK.

The receiver HTML file communicates with the backend through API routes in functions/index.js. The page may call receiver registration, receiver-token issuance, receiver polling, live polling, peek/status checks, and Android device registration endpoints. The HTML file provides the user interface and sends requests, but the backend remains the authority for PIN assignment, token validation, delivery, credit deduction, monthly-cap enforcement, queue handling, replay prevention, and push notification triggering.

Receiver Identity and PIN

The receiver PIN is the user’s Beeps address. It is the number other users enter when they want to send a Beep to this receiver. The receiver page displays this PIN after the user signs in and registers or loads their receiver identity. The PIN should be treated like a public pager address, not like a private password. A user can share the PIN with people who are allowed to send them Beeps.

The receiver token is different from the receiver PIN. The PIN is the address. The token is the authorization credential used to retrieve messages for that PIN. The receiver HTML file obtains or stores this backend-issued token so it can poll for waiting Beeps. The token should not be shown as the user’s public address. It should be used internally by the receiver page when calling the backend polling endpoints.

The receiver page may include a Refresh Identity function. Refresh Identity should be understood as refreshing the receiver state, token, or local receiver session while keeping the same receiver identity where possible. This is useful when the receiver token expires, the page reloads, the Android WebView state resets, or receiver polling stops working because authorization needs to be refreshed.

The receiver page may also include a Reset Identity or Reroll function. Reset or Reroll is stronger than Refresh. It may replace the current receiver PIN and create a new receiver identity. This is useful when the user wants a new Beeps address or wants to abandon the old one. The documentation should keep these terms separate: Refresh Identity means keep the same identity if possible; Reset/Reroll means replace the receiver identity.

Receiver Polling

Receiver polling is the process where the receiver page asks the backend whether any Beeps are waiting for the user’s PIN. The page sends the receiver PIN and receiver token to the backend. The backend validates the token, checks that the token belongs to the requested PIN, checks credits or monthly entitlement, and then returns any deliverable queued Beeps.

The normal receiver polling route is used for manual checks. The user presses a Check, Receive, Poll, or similar button, and the receiver page performs one backend request. If no message is waiting, the page displays an empty or no-message status. Empty polling does not deduct credits. Failed polling does not deduct credits. Credits are deducted only when a queued Beep is actually delivered.

The receiver page may also support Live polling. Live polling repeatedly checks for waiting messages while the receiver page remains open. This makes the receiver behave more like an active pager console. Live polling should not use different billing behavior from normal polling. Delivered Beeps consume one credit or one monthly-cap usage unit. Empty live polls consume nothing.

Updated receiver behavior sends the receiver token with the Authorization header using Bearer-token transport. The preferred request format is Authorization: Bearer <receiver_token>. The backend reads the Bearer token first. Temporary query-token fallback may still exist for older clients, but the hardened future version should remove URL query-token transport and require Bearer-only receiver polling.

Message Delivery Rule
The receiver HTML page does not deduct credits by itself. Credit deduction happens inside the backend when a queued Beep is actually delivered to the receiver. This is a central rule of Beeps Safe V2S.

Sending a Beep does not deduct receiver credits. Empty polling does not deduct credits. Failed polling does not deduct credits. Duplicate enqueue attempts do not deduct credits. One delivered Beep deducts one credit, unless the receiver is operating under an active monthly capped plan, in which case the backend applies monthly-cap usage rules.

The receiver page may display remaining credits after polling. That displayed value is information returned from the backend. The frontend should not be treated as the source of truth for balance, entitlement, or monthly plan status. The backend controls those values.
Android Push Notification Registration

When the receiver page is running inside the Android WebView wrapper, it can work with the Android Firebase Cloud Messaging layer. The receiver page or Android bridge obtains the device FCM token and sends it to the backend device-registration route. The registration request should include the receiver PIN, receiver authorization token, FCM token, and platform value.

The purpose of push registration is to let the backend alert the Android device when a Beep is waiting. The push notification should not contain the full private Beeps payload. It should only signal that a Beep is waiting. The actual message content is retrieved later through authenticated receiver polling.

This design separates notification from delivery. A push notification means the backend has signaled the device. It does not mean the message has been delivered, read, or charged yet. Delivery happens only when the receiver page polls, the backend validates authorization, and the queued message is returned to the receiver.
Receiver Page Controls

The receiver page normally includes a sign-in or account state area. This tells the user whether they are signed in and whether receiver identity is available. If sign-in is required, the receiver page should guide the user to authenticate before receiver token issuance or message polling.

The receiver PIN display area shows the active receiver number. This is the number the user gives to senders. It may include a copy button so the user can copy the PIN to clipboard. It may also include short explanatory text identifying the PIN as the user’s Beeps receiver address.

The Refresh Identity button refreshes receiver state. This may reissue the receiver token, reload the receiver PIN, or repair the local receiver session. It should be used when the receiver page is open but polling is failing due to stale state or missing token.

The Reset Identity or Reroll button replaces the receiver identity. This should be treated as a stronger privacy or account action because it can change the receiver PIN. The page should avoid making this action too easy to press accidentally.

The Check, Poll, or Receive button performs a one-time message check. This is the simplest receiver action. It asks the backend for waiting Beeps and displays any delivered messages.

The Start Live button begins repeated receiver polling. This is for active monitoring. The receiver page stays open and checks for incoming messages automatically.

The Stop Live button stops repeated polling. This reduces network activity and prevents the receiver page from continuing active checks.

The Enable Notifications or Register Device button connects the receiver identity to the Android device’s push token when available. This is mainly useful inside the Android WebView wrapper.

The Clear or Clear Log button clears the visible receiver message area. It should not be described as deleting backend messages unless the backend actually has a deletion route. Normally it is just a screen cleanup control.
Receiver Output / Message Display

The receiver output area displays incoming Beeps after backend delivery. Each delivered Beep may include the payload, timestamp, event ID, or status information depending on the current implementation. The payload is the short Beeps message sent to the receiver PIN.

The receiver page should clearly distinguish between no-message status and received-message status. “No messages waiting” means the poll succeeded but the queue was empty. “Message received” means a queued Beep was delivered. “Token expired” or “Invalid token” means receiver authorization needs repair or refresh. “Insufficient credits” means the backend blocked delivery because the receiver has no active entitlement.

The receiver output area can also function as a local activity log. It may show when polling started, when live mode stopped, when a token was refreshed, when push registration succeeded, or when a backend error occurred. This helps with testing and customer support because the user can see what the receiver page is doing.


Security Role of the Receiver HTML File

The receiver HTML file is a client interface, not the security authority. It helps the user operate the receiver, but the backend must enforce all critical rules. A modified HTML page should not be able to bypass token validation, credit enforcement, monthly-cap enforcement, or queue rules.

The receiver page should not contain secret backend keys. It may contain public Firebase client configuration, hosted route paths, UI code, and client-side logic. Private secrets belong in Firebase Functions secrets, payment-provider dashboards, or server-side environment configuration.

The receiver page should not expose full message content through push notification text. It should retrieve private content through authenticated polling. This keeps the Android notification layer as an alert signal rather than a private-message transport layer.

The receiver page should not decide that credits are valid. It should only display credit or entitlement data returned by the backend. Delivery should always require backend approval.


How to Operate the Receiver Page

First, open the Beeps receiver page from the Beeps menu, Android app, or direct hosted URL.

Second, sign in if the page requires authentication.

Third, load or create the receiver identity. The page should display the receiver PIN after the receiver identity is ready.

Fourth, copy or share the receiver PIN with approved senders. This PIN is the address they use to send Beeps to the receiver.

Fifth, press Check or Poll to manually look for waiting Beeps. If a Beep is waiting and entitlement is valid, the backend delivers it to the receiver page.

Sixth, press Start Live if the receiver should keep checking automatically. Keep the page open while live mode is running.

Seventh, press Stop Live when active monitoring is no longer needed.

Eighth, enable notifications if running inside the Android WebView app and notification support is available. This registers the Android device so the backend can signal when a Beep is waiting.

Ninth, use Refresh Identity if the receiver page appears stale, if polling stops working, or if the receiver token needs renewal.

Tenth, use Reset/Reroll Identity only when a new receiver PIN is wanted.
Receiver HTML in the Basemaster No-Assets Build

In the Basemaster no-assets release, the receiver HTML file is part of the hosted web deployment rather than bundled into the APK as a local HTML asset. The Android APK contains the WebView shell, Kotlin wrapper code, notification support, manifest, signing, and Android resources. The receiver interface itself remains hosted.

This architecture keeps the APK smaller and reduces direct exposure of bundled web-interface files inside the Android package. The hosted Firebase web app remains the source of truth for receiver UI updates. The backend remains the source of truth for delivery, queue state, credits, token validation, and entitlement enforcement.