Compatibility policy and main constraints
Principle
The test is whether something is observable by ordinary users or third-party clients. What is observable stays compatible with upstream Misskey. What is not (admin features, infrastructure-specific features) may be optimized or changed to fit Cloudflare.
| Area | Policy |
|---|---|
| User-facing API and streaming | Strictly compatible with upstream. Behavior in third-party clients (Miria and others) is guaranteed |
| Web client | Upstream's, used as-is (below) |
| ActivityPub | Federates in the same format as upstream |
| Database | The same PostgreSQL schema as upstream |
| Admin API and admin UI | Where third-party clients do not use them, optimization, changes, and removal are allowed |
| Infrastructure-specific features | Features tied to upstream's infrastructure (S3 settings, SMTP server settings, job queue operations) may be changed or removed |
| New features | Not added, as a rule |
Web client
The web client is upstream Misskey's, running almost exactly as it does upstream.
| Item | Description |
|---|---|
| Source | The pinned upstream commit is built without modification and served as static files |
| HTML | The Worker generates the same structure as upstream's server (initial data, OGP, per-page rendering for users, notes, and so on) |
| Behavior | The client talks to the same API and streaming as upstream, so screens and interactions are the same |
| Visible differences | Only those caused by server-side constraints (see "Main constraints" below and API compatibility) |
Data compatibility
| Item | Description |
|---|---|
| Schema | The same as upstream. Upstream's migrations are authoritative; Workers never change the schema |
| Migrations | Upstream's migrations are converted to SQL and bundled. They are recorded the same way as upstream, so a database migrated by upstream can be carried over in either direction |
| Existing data | An existing Misskey PostgreSQL database can be connected and used as-is |
| IDs | Generated the same way as upstream (aidx). The scheme is never changed on an existing database |
Main constraints
The main differences from upstream. The per-endpoint list is in API compatibility, and the reasons are in Workers-specific constraints.
| Item | Upstream | misskey-cf |
|---|---|---|
| Database | PostgreSQL | PostgreSQL only. Cloudflare D1 cannot be used (the schema depends on PostgreSQL-specific types) |
| Full-text search | Meilisearch and others (optional) | SQL substring match only |
| Charts | Recorded in dedicated tables | Computed from the source data on request. Decrements and event-based series (federation, request counts) are 0 |
| Rankings (featured notes, trends) | Aggregated in Redis | Approximated by aggregating the same window in PostgreSQL |
| Timelines | Kept in Redis | PostgreSQL returns the same results. The length cap is not reproduced |
| Settings changes | Immediate | Reach other execution environments up to 30 seconds later |
| Upload limit | 250 MB (default) | 100 MB (default) |
| Automatic sensitive-media detection | Available (optional) | Not available |
| SMTP | Cloudflare Email Service. SMTP settings are not used | |
| Reaction buffering | Available (optional) | Not available (always applied immediately) |
| Job queue admin UI | Shows and operates on every job | Failed and delayed jobs only |
| Server info | Machine CPU, memory, and so on | Fixed values |
| Initial setup | Setup password is optional | Setup password is required |