LanMessenger

Overview

LanMessenger is an open-source browser application for exchanging short messages and files through a shared server on a local network. ASP.NET Core and Razor Pages provide the application and interface, SignalR distributes real-time events, and locally packaged browser dependencies support operation without relying on public content-delivery networks. The current implementation is a prototype with intentionally documented security and persistence boundaries, not a finished secure-messaging product.

1. 1DiscoveryNot complete
2. 2ResearchNot complete
3. 3PlanningNot complete
4. ✓PrototypeComplete
5. 5ValidationNot complete
6. 6DocumentationNot complete
7. 7ReleaseNot complete
8. 8MaintenanceNot complete

Current Focus

Current engineering priorities are to establish a consistent authorization boundary across messaging, uploads, and file access; require protected transport; define a complete device onboarding and revocation lifecycle; and add automated integration and security coverage.

Design Decisions

Use SignalR for real-time communication

Route browser message and file-announcement events through a SignalR hub to provide server-mediated fan-out and automatic client reconnection.

Use Razor Pages for the local interface

Keep the server-rendered interface, application endpoints, and real-time client within one ASP.NET Core application to limit deployment and runtime complexity.

Package browser dependencies locally

Serve the required browser libraries from the application rather than public content-delivery networks so the runtime can operate without internet access.

Keep recent messages in bounded process memory

Retain a small fixed-size queue of recent messages for a simple single-process prototype while accepting that history is not durable across restarts.

Store transferred files on the server filesystem

Write uploads to a configured filesystem location and announce successful transfers to connected clients, keeping the initial storage model compatible with a single server.

Apply optional device keys to protected uploads

Support per-device key validation for upload requests as an additional gate, while recognizing that the current protection does not authenticate the full messaging and file-access lifecycle.

Support in-process IIS hosting

Provide IIS hosting configuration for an ASP.NET Core in-process deployment while keeping deployment-specific transport and network policy outside the current application guarantee.

Tradeoffs

Locally packaged browser assets versus CDN delivery

Local assets support offline LAN operation and avoid runtime CDN availability, but they require an explicit dependency inventory and update process.

Browser clients versus installed desktop clients

A browser interface reduces client installation and centralizes updates, but identity is tied to browser-origin storage and the application must account for browser security boundaries.

Process-local history versus durable persistence

A bounded in-memory queue keeps the prototype small and prevents unbounded growth, but messages are lost on restart and cannot be shared across server instances.

LAN address restrictions versus authenticated authorization

Source-address checks are simple on a controlled network, but their guarantees depend on network topology and cannot establish a user or device identity.

Reusable device keys versus user sessions

Device keys provide a lightweight upload gate, but the present design lacks the lifecycle, scope, and identity guarantees of a complete authenticated session model.

Filesystem transfer storage versus managed persistence

Filesystem storage fits a single-server deployment, but stronger download authorization, retention, collision handling, and multi-instance operation require additional controls.

Known Limitations

• SignalR messaging does not currently establish authenticated user or device identity.
• Device-key validation protects uploads rather than the complete messaging and file-access workflow.
• Uploaded-file access requires stronger authorization and lifecycle controls.
• LAN-only enforcement depends on the deployment topology and is not a complete security boundary.
• The application does not itself guarantee HTTPS enforcement.
• Recent-message history is process-local, bounded, and lost when the application restarts.
• Device onboarding and administration work has been explored but is not integrated into the primary implementation.
• The current persistence model assumes a single writable server and does not support coordinated multi-instance operation.
• The repository does not contain an automated test suite.

Development Log

Lessons Learned

• A local-network assumption must be enforced consistently across every messaging, upload, and download route rather than treated as an identity system.
• Authorizing file creation without applying corresponding policy to retrieval leaves the resource lifecycle only partially protected.
• Locally packaging runtime dependencies improves offline availability but still requires deliberate inventory and maintenance practices.
• In-memory queues and filesystem storage are effective prototype tools, but their restart, concurrency, retention, and backup behavior must be made explicit.
• Security configuration must be exercised by the application and verified; configuration that is not consumed can create an inaccurate operating model.
• Work on an unmerged branch must remain described as experimental until it is reviewed and integrated.

References

• LanMessenger GitHub Repository

Future Improvements

• Define and document the supported local-network threat model and deployment topologies.
• Apply a consistent authentication and authorization model to messaging, uploads, downloads, and administration.
• Require protected transport and explicitly handle trusted proxy boundaries.
• Move transferred files behind controlled delivery with content, quota, retention, and audit policies.
• Add integration and security tests for authorization, device revocation, malformed records, file handling, and network-boundary behavior.
• Adopt durable, concurrency-safe state where message history or multi-instance operation is required.
• Review and integrate or retire the experimental device-administration work.
• Consolidate duplicated browser logic and establish a minimized, reproducible offline dependency bundle.
• Add health reporting, structured operational logging, backup guidance, and recovery procedures.

Future Direction

Future work is directed toward durable state, controlled file delivery, clearer network trust configuration, operational health and retention controls, and a reviewed device-administration workflow. Broader capabilities should follow only after the local-network threat model and reliability requirements are defined.