myxelium/Toju
1
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects 2 Releases 37 Wiki Activity

fix: Bug - Local files should be remembered by client

Browse Source
This commit is contained in:
SocksOnHead
2026-06-11 01:54:00 +02:00
parent 5bf4f698df
commit 494a05e606
19 changed files with 1611 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
toju-app/src/app/domains/attachment/README.md
View File

@@ -149,6 +149,14 @@ An optional experimental VLC.js adapter can be enabled from General settings. Wh
## Persistence
Attachment file persistence is platform-agnostic. `AttachmentStorageService` owns the `server/<room>/<bucket>` and `direct-messages/...` path layout and delegates the raw byte IO to a pluggable `AttachmentFileStore` chosen by `PlatformService` (mirroring how `DatabaseService` picks a DB backend):
- **Electron** (`ElectronAttachmentFileStore`): real on-disk files via `window.electronAPI`; supports chunked reads and streamed (append) receive; `maxPersistableBytes = Infinity`.
- **Capacitor / Android** (`CapacitorAttachmentFileStore`): native `@capacitor/filesystem` under `Directory.Data` (lazy-loaded per the LESSONS rule); inline media is displayed through a `convertFileSrc` webview URL instead of a renderer `Blob`, avoiding large-media memory pressure on mobile; `maxPersistableBytes = Infinity`.
- **Browser** (`BrowserAttachmentFileStore`): a per-user IndexedDB virtual filesystem (`metoyou-attachment-files::<userId>`, store `files` keyed by path), so a user's own uploads and downloaded media survive reloads; `maxPersistableBytes = MAX_BROWSER_INLINE_MEDIA_SIZE_BYTES` (50 MB) so very large media stays peer/in-memory only.
The transfer service consults `attachmentStorage.canStreamToDisk()` / `canPersistSize(size)` so the browser cap degrades gracefully (oversized media is kept in memory / peer-served instead of failing the disk path), and streamed receive only runs on stores with a real append primitive.
On Electron, local audio/video uploads are played through the original filesystem path when Electron exposes one, and received audio/video downloads are appended to an app-data file as chunks arrive. Completed audio/video downloads are then played through a file-backed media URL instead of being reloaded into a renderer `Blob`, which avoids full-file renderer memory pressure during download, startup restore, and playback. The storage path for downloaded server-room files is resolved per room and bucket:
```
@@ -163,7 +171,7 @@ Direct-message attachments use the conversation id instead of the server-room pa
Room and conversation names are sanitised to remove filesystem-unsafe characters. The bucket is `video`, `audio`, `image`, or `files` depending on the attachment type. The original filename is kept in attachment metadata for display and downloads, but the stored file uses the attachment ID plus the original extension so two uploads with the same visible name do not overwrite each other.
`AttachmentPersistenceService` handles startup migration from an older localStorage-based format into the database, and restores attachment metadata from the DB on init. On Electron, saved audio/video records are restored as file-backed URLs; other restored files still need their bytes loaded when a `Blob` URL is required. On browser builds, files stay in memory only.
`AttachmentPersistenceService` handles startup migration from an older localStorage-based format into the database, and restores attachment metadata from the DB on init. On restore, `ensureInlineDisplayObjectUrl` resolves the stored path and, when the active store exposes a directly loadable URL (`providesInlineObjectUrl`, i.e. Capacitor), uses that URL as-is; otherwise it rebuilds a `Blob` from the stored bytes (Electron via chunked reads, browser via whole-file read with the correct MIME). Because the browser store persists bytes to IndexedDB, sent and received files are remembered across reload/restart on every platform.
## Runtime store