139 lines
5.2 KiB
Markdown
139 lines
5.2 KiB
Markdown
# Massenger
|
|
|
|
Massenger is a working Telegram-like messenger MVP built in this folder with one shared client codebase for Windows and Android.
|
|
|
|
## Stack
|
|
|
|
- `src/Massenger.Server`: ASP.NET Core 10 Web API + SignalR + SQLite.
|
|
- `src/Massenger.Shared`: shared DTO/contracts used by server and client.
|
|
- `src/Massenger.Client`: .NET MAUI client targeting `net10.0-windows10.0.19041.0` and `net10.0-android`.
|
|
|
|
## Implemented
|
|
|
|
- user registration and login
|
|
- JWT access tokens with rotating refresh tokens
|
|
- secure client-side session persistence
|
|
- seeded demo accounts and sample chats
|
|
- user search
|
|
- direct chats
|
|
- group chats
|
|
- channels with owner-only publishing
|
|
- message history persisted in SQLite
|
|
- file attachments with metadata persisted in SQLite
|
|
- voice notes as audio-classified attachments
|
|
- message edit/delete with realtime updates
|
|
- authenticated attachment download
|
|
- real-time message delivery with SignalR
|
|
- Android push registration API and FCM-based push delivery pipeline
|
|
- configurable server URL in the client
|
|
- publishable Windows `exe`
|
|
- publishable Android `apk`
|
|
|
|
## Not Implemented
|
|
|
|
This is not full Telegram parity. The following are not implemented in this MVP:
|
|
|
|
- calls and video
|
|
- microphone recording UI for voice notes
|
|
- inline audio playback controls
|
|
- stickers and inline media previews
|
|
- end-to-end encryption
|
|
- moderation, advanced channel admin roles, multi-device sync edge cases
|
|
- Windows cloud push notifications
|
|
|
|
## Demo Accounts
|
|
|
|
- `alice / demo123`
|
|
- `bob / demo123`
|
|
- `carol / demo123`
|
|
|
|
These are created automatically on first server start in `src/Massenger.Server/Data/massenger.db`.
|
|
|
|
## Run
|
|
|
|
1. Start the backend:
|
|
|
|
```powershell
|
|
./scripts/run-server.ps1
|
|
```
|
|
|
|
2. Run the Windows client from Visual Studio or CLI:
|
|
|
|
```powershell
|
|
dotnet build .\src\Massenger.Client\Massenger.Client.csproj -f net10.0-windows10.0.19041.0
|
|
.\src\Massenger.Client\bin\Debug\net10.0-windows10.0.19041.0\win-x64\Massenger.Client.exe
|
|
```
|
|
|
|
3. Run the Android client from Visual Studio or install the generated APK:
|
|
|
|
```powershell
|
|
dotnet build .\src\Massenger.Client\Massenger.Client.csproj -f net10.0-android
|
|
```
|
|
|
|
The default server URL is:
|
|
|
|
- Windows: `http://localhost:5099`
|
|
- Android emulator: `http://10.0.2.2:5099`
|
|
|
|
On a physical Android device, set the server URL manually in the app to the PC LAN IP, for example `http://192.168.1.10:5099`.
|
|
|
|
## Publish
|
|
|
|
Windows EXE:
|
|
|
|
```powershell
|
|
./scripts/publish-windows.ps1
|
|
```
|
|
|
|
Android APK:
|
|
|
|
```powershell
|
|
./scripts/publish-android-apk.ps1
|
|
```
|
|
|
|
Smoke test against the running backend:
|
|
|
|
```powershell
|
|
./scripts/smoke-test.ps1
|
|
```
|
|
|
|
## Published Artifacts
|
|
|
|
- Windows EXE: `src/Massenger.Client/bin/Release/net10.0-windows10.0.19041.0/win-x64/publish/Massenger.Client.exe`
|
|
- Android APK: `src/Massenger.Client/bin/Release/net10.0-android/publish/com.seven.massenger.apk`
|
|
- Signed Android APK: `src/Massenger.Client/bin/Release/net10.0-android/publish/com.seven.massenger-Signed.apk`
|
|
|
|
## Solutions
|
|
|
|
- XML solution: `Massenger.slnx`
|
|
- classic Visual Studio solution: `MassengerClassic.sln`
|
|
|
|
## Auth Notes
|
|
|
|
- Access tokens are short-lived JWTs.
|
|
- Refresh tokens are rotated on refresh and stored as hashed server-side sessions.
|
|
- Logout revokes the active session immediately, and the revoked access token stops working because the server validates the session id (`sid`) on authenticated requests.
|
|
- The JWT signing key in `src/Massenger.Server/appsettings.json` is a development default. Replace it with a strong secret via configuration before any real deployment.
|
|
|
|
## Attachment Notes
|
|
|
|
- Attachments are stored on the server under `src/Massenger.Server/Data/Attachments`.
|
|
- Metadata stored for each attachment: original file name, content type, file size, upload time, and owning message.
|
|
- Audio files are classified as `voice notes` by MIME type / file extension and use the same secure attachment pipeline.
|
|
- Attachment content is downloaded through an authenticated API route, not via a public static files directory.
|
|
|
|
## Channel And Message Lifecycle Notes
|
|
|
|
- Channels are broadcast rooms: the creator is the owner, selected users join as subscribers, and only owners can publish.
|
|
- Message edit/delete is synchronized through SignalR `MessageUpdated` events.
|
|
- Delete is implemented as a soft-delete on the message row with attachment cleanup on the server.
|
|
|
|
## Push Setup Notes
|
|
|
|
- Android push in this repo is implemented through Firebase Cloud Messaging HTTP v1 on the server and `FirebaseMessagingService` on the Android client.
|
|
- Server-side device registrations are stored in SQLite in the `PushDevices` table and managed through `api/push/devices`.
|
|
- To enable real Android delivery, set `Push:FirebaseProjectId` and either `Push:ServiceAccountJsonPath` or `Push:ServiceAccountJson` in `src/Massenger.Server/appsettings.json` or environment-specific configuration.
|
|
- Before building the Android APK, fill `src/Massenger.Client/Resources/Raw/firebase.android.json` with the Android Firebase values: `applicationId`, `projectId`, `apiKey`, `senderId`.
|
|
- If the Firebase configuration is left empty, the app still builds and the server still accepts device registrations, but actual FCM delivery is skipped.
|
|
- The current Windows desktop target remains unpackaged (`WindowsPackageType=None`), so this pass does not implement Windows cloud push.
|