reference.txt

Prompt 1: Windows
Role: You are an expert Windows Software Engineer, System Architect, Cybersecurity Specialist, and Network Engineer.

Task:
Help me design and architect a Windows-native local network file, folder, and clipboard-sharing application based on the requirements below.

Focus specifically on Windows 10 and Windows 11 implementation details.

Provide:

1. High-Level System Architecture
2. Recommended Technology Stack
3. LAN Discovery Design
4. End-to-End Encryption Architecture
5. Database Schema
6. Authentication Workflows
7. Device Management Workflows
8. Windows-Specific Clipboard Integration
9. Windows Drag-and-Drop Implementation
10. Notification System Design
11. Background Service Architecture
12. File Transfer Protocol Design
13. Security Threat Analysis
14. Deployment Strategy

Requirements:

Role: You are an expert Full-Stack Software Engineer, System Architect, and Security Specialist.
Task: Help me design and architect a cross-platform local network file, folder, and clipboard-sharing application based on the requirements below. Provide a high-level system architecture overview, a breakdown of recommended tech stacks for the frontend and backend, and the logical database and authentication workflows.
1. Product Overview & Target Platforms
App Goal: A cross-platform application that allows seamless file, directory, and clipboard sharing between authenticated devices on the same local network (LAN) or Mobile Hotspot.
Security Standard (E2EE): The application must implement strict End-to-End Encryption (E2EE) for all local network payloads. All clipboard syncs and file transfers must be encrypted in transit using standard cryptographic protocols (e.g., exchanging public keys upon discovery to establish a secure AES/ChaCha20 tunnel) to prevent local network packet sniffing.
Supported Platforms: Windows, macOS, and Android.
2. Authentication & Account Creation
Registration: Users create an account using their Phone Number (username), their First Name, and a password.
Security & Storage: Passwords must be securely hashed using a one-way unique cryptographic hash function (e.g., Argon2id or bcrypt) before being stored in the backend database. Plaintext storage is strictly prohibited.
Master Recovery Key: Upon successful registration, the backend must generate a unique, random 16-character alphanumeric Master Recovery Key (formatted as XXXX-XXXX-XXXX-XXXX). This key is displayed to the user as a backup, and its cryptographic hash is stored securely in the database.
3. Device Management & LAN Discovery
Device Nicknames: Upon logging into a new device or creating an account, the user is prompted to assign a "Device Nickname" (e.g., "ThinkPad" or "Office Phone").
Discovery Logic: The app discovers active devices running the app on the local network. It must strictly filter out and hide non-logged-in devices, guest devices, and smart appliances (TVs, Printers, etc.).
UI Categorization: Discovered devices are displayed in the UI as <first_name>'s <device_nickname>. They are split into two categories:
"Your Devices": Devices logged into the exact same user account. This category must remain completely hidden from the UI until at least one of the user's own devices is discovered on the network.
"Other Devices": Devices logged into different user accounts.
Device Revocation: Users can view a list of trusted devices and remotely revoke network trust. Initiating a device revocation requires the user to re-enter their password for security verification.
4. Feature Set by Account Type
Scenario A: Same Account ("Your Devices")
Cross-OS Clipboard Sync (E2EE): Seamlessly encrypts and synchronizes clipboard data across all devices with specific constraints:
Synchronizes text automatically.
For images, it must ONLY broadcast raw screenshot data (e.g., when the OS inherently copies a screenshot to the clipboard). It must NOT broadcast arbitrary image files or file paths copied by the user to prevent network choking.
Zero-Friction File & Directory Sharing (E2EE): Sending payloads to a "Your Devices" endpoint does not require manual acceptance. The encrypted transfer begins instantly. The app must support recursive directory sharing (zipping and transferring entire folder structures, not just individual files).
Desktop Drag-and-Drop Zones: For Windows and macOS, implement a floating or designated UI "drop zone" where users can drag files/folders directly from their OS file explorer to instantly trigger a transfer.
Resumable Transfers: File transfers must support chunking so they can be paused and resumed if the network drops.
Notifications:
Incoming Transfer: Display a notification: "Receiving item(s)" alongside a live progress indicator.
Completion: Display a confirmation: "Received item(s)".
Clipboard Update: Display a "Clipboard updated" notification whenever the clipboard syncs. Provide a toggle in settings to allow users to completely disable this specific notification.
Scenario B: Different Account ("Other Devices")
No Clipboard Sync: Clipboard data is completely isolated and never shared.
Permission-Based File & Directory Sharing (E2EE): Sending a file or folder requires the receiving device to manually approve the transfer.
Resumable Transfers: Supported, exactly as in Scenario A.
Notifications & Actions:
The share request triggers an interactive system notification on the receiver's device containing "Accept" and "Decline" buttons.
The user must be able to tap these actions directly from the notification tray without opening the main app UI.
Upon acceptance, the E2EE key exchange completes, and the transfer begins with a progress indicator.
Completion: Upon successful transfer, show: "Received item(s)".
5. Streamlined Forgot Password Workflow
If a user forgets their password, the account must be recovered strictly through a two-tiered offline system without external SMS Gateways:
Tier 1 (Master Recovery Key): The user clicks "Forgot Password" and is prompted for their Phone Number and 16-character Master Recovery Key. The backend hashes the inputted key and validates it. If it matches, the user can create a new password.
Tier 2 (Admin Intervention): If the user has lost both their password and Recovery Key, the UI prompts them to contact the System Administrator. Provide a basic administrative backend mechanism to manually issue a temporary login state.
6. Expected Output From You:
Tech Stack Recommendation: Suggest the best architecture for this. Recommend a cross-platform UI framework, a lightweight background language/daemon for handling LAN discovery, chunked transfers, and the E2EE cryptographic layer, and a robust central backend/database stack for authentication.
Database Schema: A brief schema design showing how users, password hashes, hashed recovery keys, and devices (with nicknames and session tokens) are stored.
API & Workflow Design: Outline the network workflows for handling mDNS discovery, the E2EE key exchange handshake (e.g., Diffie-Hellman), the logic for routing file sharing (Same Account vs. Different Account), and the logical flow of the Master Recovery Key check.

Additional Windows-Specific Requirements:

- Clipboard monitoring must integrate with the Windows Clipboard APIs.
- Support clipboard synchronization of text and screenshots only.
- Detect screenshots copied via Windows Snipping Tool, Print Screen, Snip & Sketch, and Windows Screenshot APIs.
- Ignore copied file paths and copied image files.
- Implement a floating drag-and-drop transfer zone that remains available system-wide.
- Support drag-and-drop directly from Windows Explorer.
- Use native Windows notifications through Windows App SDK / WinUI notification APIs.
- Interactive notifications must support transfer progress and action buttons.
- Background discovery and synchronization should run as a Windows Service or lightweight background daemon.
- The application must support automatic startup with Windows login.
- Include recommendations for:
  - WinUI 3 vs Electron vs Flutter Desktop
  - Rust vs Go vs C++ for the networking daemon
  - Windows Credential Manager integration
  - Windows Firewall handling
  - mDNS implementation on Windows

Expected Output:

Provide production-grade architecture suitable for a commercial application comparable to LocalSend, AirDroid, KDE Connect, or Apple's Continuity ecosystem.


Prompt 2: macOS
Role: You are an expert macOS Software Engineer, System Architect, Cybersecurity Specialist, and Network Engineer.

Task:
Help me design and architect a macOS-native local network file, folder, and clipboard-sharing application based on the requirements below.

Focus specifically on modern macOS implementation details.

Provide:

1. High-Level System Architecture
2. Recommended Technology Stack
3. LAN Discovery Design
4. End-to-End Encryption Architecture
5. Database Schema
6. Authentication Workflows
7. Device Management Workflows
8. macOS Clipboard Integration
9. Finder Drag-and-Drop Implementation
10. Notification System Design
11. Background Service Architecture
12. File Transfer Protocol Design
13. Security Threat Analysis
14. Deployment Strategy

Requirements:

Role: You are an expert Full-Stack Software Engineer, System Architect, and Security Specialist.
Task: Help me design and architect a cross-platform local network file, folder, and clipboard-sharing application based on the requirements below. Provide a high-level system architecture overview, a breakdown of recommended tech stacks for the frontend and backend, and the logical database and authentication workflows.
1. Product Overview & Target Platforms
App Goal: A cross-platform application that allows seamless file, directory, and clipboard sharing between authenticated devices on the same local network (LAN) or Mobile Hotspot.
Security Standard (E2EE): The application must implement strict End-to-End Encryption (E2EE) for all local network payloads. All clipboard syncs and file transfers must be encrypted in transit using standard cryptographic protocols (e.g., exchanging public keys upon discovery to establish a secure AES/ChaCha20 tunnel) to prevent local network packet sniffing.
Supported Platforms: Windows, macOS, and Android.
2. Authentication & Account Creation
Registration: Users create an account using their Phone Number (username), their First Name, and a password.
Security & Storage: Passwords must be securely hashed using a one-way unique cryptographic hash function (e.g., Argon2id or bcrypt) before being stored in the backend database. Plaintext storage is strictly prohibited.
Master Recovery Key: Upon successful registration, the backend must generate a unique, random 16-character alphanumeric Master Recovery Key (formatted as XXXX-XXXX-XXXX-XXXX). This key is displayed to the user as a backup, and its cryptographic hash is stored securely in the database.
3. Device Management & LAN Discovery
Device Nicknames: Upon logging into a new device or creating an account, the user is prompted to assign a "Device Nickname" (e.g., "ThinkPad" or "Office Phone").
Discovery Logic: The app discovers active devices running the app on the local network. It must strictly filter out and hide non-logged-in devices, guest devices, and smart appliances (TVs, Printers, etc.).
UI Categorization: Discovered devices are displayed in the UI as <first_name>'s <device_nickname>. They are split into two categories:
"Your Devices": Devices logged into the exact same user account. This category must remain completely hidden from the UI until at least one of the user's own devices is discovered on the network.
"Other Devices": Devices logged into different user accounts.
Device Revocation: Users can view a list of trusted devices and remotely revoke network trust. Initiating a device revocation requires the user to re-enter their password for security verification.
4. Feature Set by Account Type
Scenario A: Same Account ("Your Devices")
Cross-OS Clipboard Sync (E2EE): Seamlessly encrypts and synchronizes clipboard data across all devices with specific constraints:
Synchronizes text automatically.
For images, it must ONLY broadcast raw screenshot data (e.g., when the OS inherently copies a screenshot to the clipboard). It must NOT broadcast arbitrary image files or file paths copied by the user to prevent network choking.
Zero-Friction File & Directory Sharing (E2EE): Sending payloads to a "Your Devices" endpoint does not require manual acceptance. The encrypted transfer begins instantly. The app must support recursive directory sharing (zipping and transferring entire folder structures, not just individual files).
Desktop Drag-and-Drop Zones: For Windows and macOS, implement a floating or designated UI "drop zone" where users can drag files/folders directly from their OS file explorer to instantly trigger a transfer.
Resumable Transfers: File transfers must support chunking so they can be paused and resumed if the network drops.
Notifications:
Incoming Transfer: Display a notification: "Receiving item(s)" alongside a live progress indicator.
Completion: Display a confirmation: "Received item(s)".
Clipboard Update: Display a "Clipboard updated" notification whenever the clipboard syncs. Provide a toggle in settings to allow users to completely disable this specific notification.
Scenario B: Different Account ("Other Devices")
No Clipboard Sync: Clipboard data is completely isolated and never shared.
Permission-Based File & Directory Sharing (E2EE): Sending a file or folder requires the receiving device to manually approve the transfer.
Resumable Transfers: Supported, exactly as in Scenario A.
Notifications & Actions:
The share request triggers an interactive system notification on the receiver's device containing "Accept" and "Decline" buttons.
The user must be able to tap these actions directly from the notification tray without opening the main app UI.
Upon acceptance, the E2EE key exchange completes, and the transfer begins with a progress indicator.
Completion: Upon successful transfer, show: "Received item(s)".
5. Streamlined Forgot Password Workflow
If a user forgets their password, the account must be recovered strictly through a two-tiered offline system without external SMS Gateways:
Tier 1 (Master Recovery Key): The user clicks "Forgot Password" and is prompted for their Phone Number and 16-character Master Recovery Key. The backend hashes the inputted key and validates it. If it matches, the user can create a new password.
Tier 2 (Admin Intervention): If the user has lost both their password and Recovery Key, the UI prompts them to contact the System Administrator. Provide a basic administrative backend mechanism to manually issue a temporary login state.
6. Expected Output From You:
Tech Stack Recommendation: Suggest the best architecture for this. Recommend a cross-platform UI framework, a lightweight background language/daemon for handling LAN discovery, chunked transfers, and the E2EE cryptographic layer, and a robust central backend/database stack for authentication.
Database Schema: A brief schema design showing how users, password hashes, hashed recovery keys, and devices (with nicknames and session tokens) are stored.
API & Workflow Design: Outline the network workflows for handling mDNS discovery, the E2EE key exchange handshake (e.g., Diffie-Hellman), the logic for routing file sharing (Same Account vs. Different Account), and the logical flow of the Master Recovery Key check.

Additional macOS-Specific Requirements:

- Clipboard monitoring must integrate with NSPasteboard.
- Support synchronization of text and screenshots only.
- Detect screenshots generated through macOS screenshot shortcuts and native screenshot utilities.
- Ignore copied file references and image file paths.
- Implement a floating drag-and-drop transfer zone.
- Support drag-and-drop directly from Finder.
- Use native macOS Notification Center APIs.
- Interactive notifications must support Accept and Decline actions.
- Background synchronization must run using LaunchAgents or LaunchDaemons.
- Support automatic startup after user login.
- Integrate securely with Keychain Access.
- Use Bonjour/mDNS for local network discovery.
- Respect Apple's sandboxing and privacy permissions.

Include recommendations for:

- SwiftUI vs Flutter Desktop vs Electron
- Rust vs Go vs Swift Networking
- Keychain integration
- Network Extension framework usage
- App Store distribution vs direct distribution

Expected Output:

Provide production-grade architecture suitable for a commercial application comparable to AirDrop, LocalSend, KDE Connect, or Apple's Continuity ecosystem.


Prompt 3: Android
Role: You are an expert Android Software Engineer, System Architect, Cybersecurity Specialist, and Network Engineer.

Task:
Help me design and architect an Android-native local network file, folder, and clipboard-sharing application based on the requirements below.

Focus specifically on modern Android implementation details (Android 13+).

Provide:

1. High-Level System Architecture
2. Recommended Technology Stack
3. LAN Discovery Design
4. End-to-End Encryption Architecture
5. Database Schema
6. Authentication Workflows
7. Device Management Workflows
8. Android Clipboard Integration
9. Notification System Design
10. Background Service Architecture
11. File Transfer Protocol Design
12. Security Threat Analysis
13. Deployment Strategy

Requirements:

Role: You are an expert Full-Stack Software Engineer, System Architect, and Security Specialist.
Task: Help me design and architect a cross-platform local network file, folder, and clipboard-sharing application based on the requirements below. Provide a high-level system architecture overview, a breakdown of recommended tech stacks for the frontend and backend, and the logical database and authentication workflows.
1. Product Overview & Target Platforms
App Goal: A cross-platform application that allows seamless file, directory, and clipboard sharing between authenticated devices on the same local network (LAN) or Mobile Hotspot.
Security Standard (E2EE): The application must implement strict End-to-End Encryption (E2EE) for all local network payloads. All clipboard syncs and file transfers must be encrypted in transit using standard cryptographic protocols (e.g., exchanging public keys upon discovery to establish a secure AES/ChaCha20 tunnel) to prevent local network packet sniffing.
Supported Platforms: Windows, macOS, and Android.
2. Authentication & Account Creation
Registration: Users create an account using their Phone Number (username), their First Name, and a password.
Security & Storage: Passwords must be securely hashed using a one-way unique cryptographic hash function (e.g., Argon2id or bcrypt) before being stored in the backend database. Plaintext storage is strictly prohibited.
Master Recovery Key: Upon successful registration, the backend must generate a unique, random 16-character alphanumeric Master Recovery Key (formatted as XXXX-XXXX-XXXX-XXXX). This key is displayed to the user as a backup, and its cryptographic hash is stored securely in the database.
3. Device Management & LAN Discovery
Device Nicknames: Upon logging into a new device or creating an account, the user is prompted to assign a "Device Nickname" (e.g., "ThinkPad" or "Office Phone").
Discovery Logic: The app discovers active devices running the app on the local network. It must strictly filter out and hide non-logged-in devices, guest devices, and smart appliances (TVs, Printers, etc.).
UI Categorization: Discovered devices are displayed in the UI as <first_name>'s <device_nickname>. They are split into two categories:
"Your Devices": Devices logged into the exact same user account. This category must remain completely hidden from the UI until at least one of the user's own devices is discovered on the network.
"Other Devices": Devices logged into different user accounts.
Device Revocation: Users can view a list of trusted devices and remotely revoke network trust. Initiating a device revocation requires the user to re-enter their password for security verification.
4. Feature Set by Account Type
Scenario A: Same Account ("Your Devices")
Cross-OS Clipboard Sync (E2EE): Seamlessly encrypts and synchronizes clipboard data across all devices with specific constraints:
Synchronizes text automatically.
For images, it must ONLY broadcast raw screenshot data (e.g., when the OS inherently copies a screenshot to the clipboard). It must NOT broadcast arbitrary image files or file paths copied by the user to prevent network choking.
Zero-Friction File & Directory Sharing (E2EE): Sending payloads to a "Your Devices" endpoint does not require manual acceptance. The encrypted transfer begins instantly. The app must support recursive directory sharing (zipping and transferring entire folder structures, not just individual files).
Desktop Drag-and-Drop Zones: For Windows and macOS, implement a floating or designated UI "drop zone" where users can drag files/folders directly from their OS file explorer to instantly trigger a transfer.
Resumable Transfers: File transfers must support chunking so they can be paused and resumed if the network drops.
Notifications:
Incoming Transfer: Display a notification: "Receiving item(s)" alongside a live progress indicator.
Completion: Display a confirmation: "Received item(s)".
Clipboard Update: Display a "Clipboard updated" notification whenever the clipboard syncs. Provide a toggle in settings to allow users to completely disable this specific notification.
Scenario B: Different Account ("Other Devices")
No Clipboard Sync: Clipboard data is completely isolated and never shared.
Permission-Based File & Directory Sharing (E2EE): Sending a file or folder requires the receiving device to manually approve the transfer.
Resumable Transfers: Supported, exactly as in Scenario A.
Notifications & Actions:
The share request triggers an interactive system notification on the receiver's device containing "Accept" and "Decline" buttons.
The user must be able to tap these actions directly from the notification tray without opening the main app UI.
Upon acceptance, the E2EE key exchange completes, and the transfer begins with a progress indicator.
Completion: Upon successful transfer, show: "Received item(s)".
5. Streamlined Forgot Password Workflow
If a user forgets their password, the account must be recovered strictly through a two-tiered offline system without external SMS Gateways:
Tier 1 (Master Recovery Key): The user clicks "Forgot Password" and is prompted for their Phone Number and 16-character Master Recovery Key. The backend hashes the inputted key and validates it. If it matches, the user can create a new password.
Tier 2 (Admin Intervention): If the user has lost both their password and Recovery Key, the UI prompts them to contact the System Administrator. Provide a basic administrative backend mechanism to manually issue a temporary login state.
6. Expected Output From You:
Tech Stack Recommendation: Suggest the best architecture for this. Recommend a cross-platform UI framework, a lightweight background language/daemon for handling LAN discovery, chunked transfers, and the E2EE cryptographic layer, and a robust central backend/database stack for authentication.
Database Schema: A brief schema design showing how users, password hashes, hashed recovery keys, and devices (with nicknames and session tokens) are stored.
API & Workflow Design: Outline the network workflows for handling mDNS discovery, the E2EE key exchange handshake (e.g., Diffie-Hellman), the logic for routing file sharing (Same Account vs. Different Account), and the logical flow of the Master Recovery Key check.

Additional Android-Specific Requirements:

- Clipboard synchronization must comply with Android clipboard privacy restrictions.
- Support synchronization of text and screenshots only.
- Detect screenshots copied to the Android clipboard when possible.
- Ignore copied file URIs and image file references.
- Support file and folder sharing using Android Storage Access Framework.
- Use Android Foreground Services for transfers and discovery.
- Use Android Notification Channels.
- Interactive notifications must support Accept and Decline actions directly from the notification tray.
- Support sharing through Android's native Share Sheet.
- Support automatic discovery over Wi-Fi and Mobile Hotspot networks.
- Respect battery optimization policies.
- Integrate securely with Android Keystore.
- Handle runtime permissions using modern Android APIs.

Include recommendations for:

- Jetpack Compose vs Flutter
- Kotlin vs Rust networking layer
- Android Keystore integration
- Foreground Service architecture
- Nearby Connections vs mDNS discovery
- Play Store deployment considerations

Expected Output:

Provide production-grade architecture suitable for a commercial application comparable to Nearby Share, LocalSend, AirDroid, or KDE Connect.