SDKs
The libraries talk to the File Service and know nothing about your posts, contracts or chats. Naming follows the rest of the CCS ecosystem: a -client package runs in a backend with a machine credential, a -user-client package runs as the signed-in user. Every package is published privately on GitHub Packages under @central-code-station.
| Package | Runs in | Version |
|---|---|---|
@central-code-station/ccs-files-client |
Your Node.js backend, with a machine client | 1.3.0 |
@central-code-station/ccs-files-user-client |
Web apps (plain TypeScript, Angular, React), as the signed-in user: uploads with progress, pause and resume, previews, folder browsing | 1.2.0 |
ccs_files_user_client |
Flutter apps on Android, iOS and desktop: the same, with an upload queue that survives restarts | 1.2.0 |
The user clients also run the backend-mediated flow, where the app holds no File Service token: your backend creates the ticket with ccs-files-client, the app sends the bytes with the user client’s upload engine, your backend completes it. The Node and web clients are published privately on GitHub Packages under @central-code-station; the Flutter package is installed from the ccs-file-server repository at a release tag. Every library knows the same wire format and the same error classes.
Events reach your apps through the Notification Service’s own libraries, and your backend through a webhook; see Events.