Beeps Safe V2S / Version 2 / 26.3 Basemaster WebWrapper No-Assets Release Notes Release Name: Beeps Safe V2S 26.3 Basemaster WebWrapper No Assets Release File Label: Beeps_Safe_V2S_26.3_BASEMASTER_WEBWRAPPER_NO_ASSETS Product: Beeps Safe V2S / Beeps by Electrolips Owner: Electrolips LLC Android Package ID: com.beep.beepsbyelectrolips Release Type: Android public-distribution Basemaster WebView wrapper build Release Purpose: This release packages Beeps Safe V2S as a clean Android WebView wrapper that loads the hosted Beeps Safe web application from Firebase Hosting instead of bundling HTML, JavaScript, CSS, or local web source files inside the APK. The build is intended for public/user APK distribution and future app-store basemaster packaging while keeping the active web application maintained through the hosted Firebase deployment. Build Identity: This build is Beeps Safe V2S / Version 2 / 26.3. It is not Beeps Version 1. The release belongs to the Beeps Safe V2S application line and uses the Beeps by Electrolips Android package identity. Primary Hosted Entry: https://beeps-v2s.web.app/menu-basemaster.html Core Product Description: Beeps Safe V2S is a privacy-focused numeric paging and controlled-contact communication system. The system lets a user receive pages through a private receiver PIN rather than exposing a personal phone number. Senders can submit short Beeps to a receiver PIN through the public dialer or sender/receiver terminal. Receiver-side message retrieval is controlled through authenticated polling, backend token validation, server-side queueing, and entitlement rules. The system is structured as a hosted web application, backend API, Redis-backed queue and entitlement layer, Firebase Authentication identity layer, Firebase Functions API layer, Firebase Cloud Messaging notification system, and Android WebView wrapper. The Android app gives users an installable mobile application shell while the active user interface and backend logic remain hosted and maintainable through Firebase. Basemaster WebWrapper No-Assets Packaging: This Basemaster release intentionally removes bundled HTML, JavaScript, CSS, and local web source assets from the APK package. The Android application operates as a wrapper around the hosted Beeps Safe web interface. This reduces the amount of web source code distributed inside the APK and keeps the live application pages controlled through the hosted Firebase web deployment. The APK should be treated as a hosted web-wrapper package. The user installs the Android app, opens Beeps Safe, and the wrapper loads the hosted Beeps Safe interface. The backend, API, purchase routes, receiver polling, sender routing, and hosted menu behavior are controlled through the live Firebase-hosted application and Firebase Functions backend. Application Architecture: The system uses a hybrid architecture. The Android app is not a fully native rewrite and is not a simple browser bookmark. It is an installable Android WebView wrapper that loads the hosted Beeps Safe web application and supplies native Android support where needed. Major components include: - Android WebView wrapper - Firebase-hosted web application - Firebase Authentication - Firebase Functions Gen 2 backend - Express API routes - Redis/Upstash server-side queue and entitlement state - Firebase Cloud Messaging support - Android native notification support - Android audio and Bluetooth permission support - Stripe payment integration - PayPal payment integration - Receiver PIN identity model - Public dialer sender path - Sender/receiver terminal path - Receiver interface path Core Communication Model: Beeps Safe V2S uses a queue-backed paging model. Messages are submitted to the backend and associated with a receiver PIN. Receiver interfaces retrieve messages through authenticated polling. The system is designed around short paging payloads, controlled contact, and limited-exposure communication rather than normal social chat threads. The receiver identity model allows a user to share a Beeps receiver PIN instead of a personal phone number. A sender can submit a Beep to that PIN without receiving the user's private phone number or direct personal contact information. This gives the receiver a privacy layer between public reachability and private identity. Current Payload Model: Beeps payloads are short paging payloads. The supported payload length is 64 characters. The system supports short numeric, symbolic, and limited alphanumeric paging payloads according to the backend sanitization rules. The current payload model is intended for quick pages, callback markers, short signals, coded responses, and controlled-contact alerts. Current allowed payload character class: A-Z, 0-9, space, asterisk, pound sign, period, at sign, and hyphen. Current Receiver PIN Model: Receiver PINs are numeric pager identifiers. The backend accepts PINs meeting the current minimum length rule and receiver-generated account PINs are expected to be 10 digits. Public sender compatibility allows the public dialer to submit to receiver PINs without requiring the sender to sign in. Backend Authority: The backend is authoritative for receiver PIN assignment, receiver token issuance, message queue insertion, message delivery, credit balance enforcement, monthly-cap enforcement, payment fulfillment, webhook idempotency, Android push registration, replay prevention, and rate limiting. Frontend clients may display balances, statuses, and message views, but frontend clients do not decide whether credits exist and do not perform credit deduction. Credit Deduction Rule: Credits are deducted server-side only when a queued Beep is actually delivered to a receiver by a receiver polling endpoint. Current rule: - One delivered Beep deducts one server-side credit unless an active monthly capped plan applies. - Empty polling does not deduct credits. - Failed polling does not deduct credits. - Enqueue/send does not deduct credits. - Replayed or duplicate enqueue requests do not deduct credits. - Monthly capped plans use backend monthly entitlement logic instead of ordinary token-pack credit deduction. Queue and Data Lifecycle: Messages are submitted to a server-side pending queue and later retrieved by receiver polling. Pending messages are TTL-bounded and are not described as permanent message storage. The deployed backend uses Redis queue and token metadata, so the public technical language should describe this as a TTL-bounded pending queue rather than claiming that nothing is ever stored. Current public/security wording: Beeps Safe V2S uses a server-side, TTL-bounded pending queue for delivery. Message payloads are held only as needed for receiver delivery and are subject to expiration. Receiver retrieval uses authenticated polling. Credits and monthly entitlements are enforced server-side. Client applications do not control billing or credit deduction. Receiver Polling and Token Transport: Receiver and terminal clients use receiver tokens for authenticated polling. Updated client behavior sends the receiver token through the Authorization header using Bearer-token transport. The backend reads the Bearer token first. Temporary compatibility fallback may remain on the backend for older clients until migration is complete. Current preferred receiver polling format: Authorization: Bearer Polling routes: - /api/recv/poll - /api/recv/poll/live Live Polling: The receiver and terminal support normal polling and live or burst polling behavior. Live polling is used when the receiver or terminal is actively checking for new Beeps. Normal polling supports lower activity operation, while live/burst polling improves responsiveness during active user interaction. Android Notification Behavior: The Android wrapper supports native notification behavior through Firebase Cloud Messaging and Android notification components. Push notifications are used to signal that a Beep is waiting. Message content is retrieved inside the app through authenticated receiver polling rather than being fully exposed in the notification body. This privacy position keeps the push notification as a signal and preserves message retrieval inside the authenticated app interface. Public Dialer: The public dialer allows a sender to submit a Beep to a receiver PIN without signing in. This supports public contact, controlled callback screening, and low-friction sender access. The public sender does not receive access to the receiver's real phone number or private identity. The public dialer supports the current 64-character payload model. Sender / Receiver Terminal: The sender/receiver terminal supports both sending and receiving behavior inside a single authenticated interface. It can send Beeps to another receiver PIN, check the user's own Beeps, display receiver identity information, manage local inbox history, and support alert/audio controls. The terminal uses the same backend queue and receiver-token retrieval model as the receiver interface. Receiver Interface: The receiver interface remains a separate, stable receiver-oriented interface. It is designed for receiver use, smaller screen operation, notification-driven use, future wearable use, and satellite-style receiver behavior. The receiver interface polls, receives, displays, merges inbox history, supports lock/history behavior, and works with Android native notifications. Native Android Wrapper Functions: The Android wrapper supports app-like functions around the hosted web interface. Supported wrapper concepts include: - WebView-hosted application loading - Internet access - notification permission support - Firebase Cloud Messaging receiver service - native notification channel behavior - receiver identity persistence - push registration support - audio alert support - Bluetooth/audio permission support - optional audio output handling - custom alert support depending on wrapper bridge state Purchase and Entitlement System: The system supports token-pack and monthly capped product behavior through payment integrations. Stripe and PayPal are used for checkout and fulfillment flows. The backend controls fulfillment, credit grants, monthly cap activation, idempotency, webhook processing, and entitlement enforcement. Current product behavior should remain synchronized across backend configuration, Stripe products, PayPal products, buy page text, customer terms, release notes, and API contract. Known product rules: - 100MSG_1M is a 100-message, 1-month product. - 100TKN is a 100-message product with the corrected duration. - Monthly capped products advertise a monthly message cap. - Monthly capped plans should be described as capped monthly plans unless a plan is truly unlimited. Replay Protection: Sender requests use request_id values for replay prevention. The backend uses server-side replay keys to prevent duplicate enqueue requests from creating duplicate messages inside the replay window. Security and Privacy Notes: Beeps Safe V2S is designed to reduce direct phone number exposure and support controlled contact. Users can share a receiver PIN instead of a personal phone number. Senders can submit a Beep without receiving the user's real contact details. The receiver then decides how to respond. Security posture includes: - receiver-token gated polling - server-side credit enforcement - server-side queue behavior - request_id replay prevention - backend-controlled entitlement logic - backend-controlled message delivery - push notification signaling without exposing full payload content - separation between public sender access and receiver retrieval authority Important Public Wording: Use: Beeps Safe V2S uses a server-side, TTL-bounded pending queue for delivery. Receiver retrieval uses authenticated polling. Credits and monthly entitlements are enforced server-side. Avoid: - deployed backend stores nothing - current deployed system is fully stateless - push notification proves delivery - enqueue consumes credits - frontend controls credits Supported User Interfaces: This release supports the hosted Beeps web interface running inside the Android wrapper. The hosted application includes sign-in, menu navigation, receiver access, sender/receiver terminal access, public dialer access, buy page access, success/cancel pages, and legal/support/community link paths as configured in the hosted app. Supported Platform: - Android APK installation - Android phone - Android tablet - Firebase-hosted web interface loaded through Android WebView Future Platform Categories: The same backend and hosted interface model can support future browser extension packaging, iOS WKWebView packaging, Wear OS receiver behavior, IoT accessory receivers, audio-only receiver devices, ring/wearable accessories, and other controlled-contact receiver devices. Use Cases: Beeps Safe V2S can support: - private numeric paging - controlled callback screening - privacy-first contact sharing - masked public contact - safety-oriented contact screening - public sender to private receiver workflows - business pager identity - private field-service alerting - short-code dispatch - family alert signaling - workplace pager behavior - device or machine alarm signaling - future wearable or IoT alert receivers Basemaster Release Position: This release is intended to act as a public distribution base for a hosted Beeps Safe Android wrapper. Because the APK does not contain the active web source assets, the hosted Firebase deployment remains the primary source for active interface behavior. The APK should be identified by its filename, checksum, build label file, and no-assets scan result. Build Verification Requirements: The release folder should contain: - final-builds APK - optional final-builds AAB if bundleRelease is built - final-docs/checksum.txt - final-docs/install-guide.txt - final-docs/release-notes.txt - final-docs/technical-release-info.txt - final-docs/no-assets-scan.txt - final-checksums/SHA256SUMS.txt - optional final-proof-package archive and archive checksum No-Assets Verification: The release should include a scan proving that the APK does not contain bundled HTML, JS, CSS, or MAP web source files under Android assets. The expected verification result is: PASS: no bundled HTML/JS/CSS/MAP web assets found inside APK. Installation Notes: Users install the APK directly on Android. They may need to allow installation from outside the Play Store. After installation, users open Beeps Safe, sign in or create an account, allow notifications, and open Receiver or Sender / Receiver Terminal depending on use. Permissions and Device Setup: For full functionality, users should allow notifications, allow background activity, allow internet access, avoid force-stopping the app, avoid deep sleep restrictions where possible, and allow audio/Bluetooth permissions where relevant. Known Operational Notes: Android background behavior depends on device manufacturer settings, notification permission, battery optimization, background data permission, and whether the app is force-stopped. If notifications stop, reopening the receiver can refresh receiver identity and push registration. Known Deferred Items: - Remove backend query-token fallback after all active clients are confirmed migrated. - Finish production browser extension packaging with local CSS/JS for Chromium MV3 compliance. - Prepare store-specific submission packages. - Continue iOS wrapper planning. - Continue Wear OS and IoT receiver planning. - Continue final website, legal, support, and download-page cleanup. - Maintain payment text synchronization across backend, Stripe, PayPal, buy page, and release documents. - Maintain final checksum/proof archives for public and legal records. Release Summary: Beeps Safe V2S 26.3 Basemaster WebWrapper No Assets is a public Android web-wrapper release of the Beeps Safe V2S privacy paging system. It provides an installable Android application shell for the hosted Beeps Safe interface while omitting bundled web source assets from the APK. The build preserves the Beeps Safe backend architecture, receiver PIN identity model, queue-backed message delivery, authenticated receiver polling, server-side credit enforcement, public dialer pathway, terminal pathway, receiver interface, and Android notification support. This release should be distributed and archived using its exact build label, checksum files, technical release information, installation guide, release notes, and no-assets verification scan.