# WebDAV Server Architecture

## Recommended Approach: Adapter (not Proxy)

The WebDAV server is an **adapter**: it implements the WebDAV protocol and translates requests into Internxt Drive API + Network calls. It does **not** forward to another WebDAV server.

```mermaid
flowchart LR
    subgraph Client [WebDAV Client]
        Finder[Finder/Cyberduck]
        Rclone[Rclone]
    end

    subgraph Adapter [WebDAV Adapter]
        WebDAV[WebDAV Server]
        Mapping[Path to UUID]
        Crypto[Encrypt/Decrypt]
    end

    subgraph Internxt [Internxt Backend]
        DriveAPI[Drive API]
        Network[Bridge/Network]
    end

    Finder -->|PROPFIND GET PUT| WebDAV
    WebDAV --> Mapping
    Mapping --> DriveAPI
    WebDAV --> Crypto
    Crypto --> Network
```

## Data Flow

| WebDAV Request | Internxt Operation |
|----------------|-------------------|
| PROPFIND (directory listing) | Storage.getFolderContentByUuid |
| GET (read file) | File metadata → Network.download → Decrypt |
| PUT (write file) | Encrypt → Network.upload → createFileEntry |
| MKCOL (create folder) | Storage.createFolderByUuid |
| DELETE | Trash or permanent delete |
| MOVE | Storage.moveFileByUuid / moveFolderByUuid |

## Complexity

- **Simple:** PROPFIND, MKCOL – Drive API only, no encryption
- **Medium:** DELETE, MOVE – Drive API
- **Complex:** GET, PUT – Bridge/Network + mnemonic encryption

drive-web uses `Network.client` (Bridge) and `NetworkFacade` for up/download. Bridge credentials come from the user session.

## Implementation Order

1. **Phase 1:** PROPFIND (list directory) – ✅ implemented
2. **Phase 2:** MKCOL, DELETE, MOVE – ✅ implemented
3. **Phase 3:** GET (download) – Bridge + decryption – ✅ implemented
4. **Phase 4:** PUT (upload) – Encryption + Bridge – ✅ implemented

### Name Decryption

Internxt uses zero-knowledge encryption. The API returns encrypted names (`name`). When `plain_name` is missing, the server can decrypt names with `CRYPTO_SECRET2` (or `CRYPTO_SECRET`) – analogous to drive-web `aes.decrypt` logic with `secret2-parentId`/`secret2-folderId`. Without a set secret, raw (encrypted) names are used.

## Token vs Bridge Credentials

- **Drive API:** Uses `xNewToken` (Authorization: Bearer)
- **Network/Bridge:** Requires `bridgeUser` + `userId` (from user credentials) and mnemonic for encryption

**Bridge credentials from refreshUser:** The `/users/refresh` endpoint returns `user` (UserResponseDto) with:
- `bridgeUser` – User email
- `userId` – hashed with SHA256 and used as Bridge password
- `bucket` – Bucket ID for uploads
- `mnemonic` – for file encryption
- `rootFolderId` – Root folder UUID

Thus the browser token (via refreshUser) provides all data needed for Drive API and Bridge.