Develop a proof-of-concept to demonstrate how atServer can be accessed from a web application.

[VJag]

Is your feature request related to a problem? Please describe.

Objective: Develop a proof-of-concept (POC) to demonstrate how atServer can be accessed from a web application.

Background: Recent innovations now make it feasible to effectively access atServer from web applications. These innovations include:

WebSockets to atServer: Previously, atServer only allowed socket connections. It now supports WebSockets, enabling web-based access. APKAM: With APKAM, there is no need to ask users for keys to access the secondary server. We can create temporary ephemeral access keys. WASM: Accessing the secondary server requires key generation, payload signing, etc., which we've implemented in Dart. Finding equivalent libraries in JavaScript would be time-consuming. With WebAssembly (WASM), we can reuse much of the existing Dart implementation. APKAM Widget: This widget allows for APKAM requests to be approved, simplifying the process of managing access keys and enhancing security.

Describe the solution you'd like

Tasks:

WebSocket Integration:

• Implement WebSocket connection to atServer.
• Ensure the web application can communicate with atServer via WebSockets.

APKAM Integration:

• Utilize APKAM to generate temporary ephemeral access keys.
• Implement the use of these keys for accessing the secondary server.

WASM Integration:

• Use WebAssembly to reuse existing Dart code for key generation, payload signing, etc.
• Ensure seamless interaction between the web application and atServer using these functionalities.

Develop Web Application:

• Create a basic user interface to demonstrate the connection and interaction with atServer.
• Implement features to showcase WebSocket communication, secure access using APKAM, WASM, and the APKAM widget.

Deliverables:

• [x] A web application demonstrating the successful access and interaction with atServer.
• [ ] Documentation on the setup and usage of the POC.
• [ ] Source code committed to the repository with appropriate comments and documentation.

Benefits: Validate the feasibility of accessing atServer from web applications. Provide a foundation for further development and integration of atServer in web-based projects. Leverage existing Dart implementations using WASM, saving development time and effort. Simplify and secure access management with APKAM and the APKAM widget.

Describe alternatives you've considered

No response

Additional context

No response

[cpswan]

https://gist.github.com/mmaitlen/9c51792cff715deb58f167ff8e9791c2 might help

[VJag]

I completed the task "A web application demonstrating successful access and interaction with atServer." Check-in and documentation will be done in the next sprint.

[VJag]

Discussion Summary with Gary:

Node.js Version of atClient: Explore the development of a Node.js version of atClient.

Authentication from Browser: We discussed three potential approaches:

Option 1: Use passkeys for authentication. Option 2: Store the atKeys file on the secondary server, encrypted with a symmetric key derived from a user-entered password. Option 3: Save atKeys in external password managers, though the size of the atKeys file may pose challenges. Future Possibility: Explore running the full atClient in the browser, potentially using WebAssembly (WASM) or as a JavaScript library.

Web Work by Gary: Gary is working on exposing atClient's functionality to web clients. This can be extended to run atClient as a microservice, allowing its functionalities to be consumed through APIs.

Action Items:

1. Conduct a spike to validate various server-side authentication methods.
2. Analyze and develop a plan for creating a Node.js version of atClient.