[Feature Request] Import co-typist context?

[FuJacob]

Feature Request

Description

I have several months of data collected by co-typist and want to migrate to cotabby.

Use Case

Let me import my history in to cotabby.

---

Submitted via tabby feedback form

[fcalazans]

I would love this feature.

[MathieuCorti]

Had a look at that, the training data based on the user typing history is saved in cotypist.db, which is is protected by an app-managed key, likely Keychain-backed. Unless someone manage to reverse-engineer the encryption/keychain flow, it's most likely not possible to migrate the data.

[jkrauska]

Had a look at that, the training data based on the user typing history is saved in cotypist.db, which is is protected by an app-managed key, likely Keychain-backed. Unless someone manage to reverse-engineer the encryption/keychain flow, it's most likely not possible to migrate the data.

appears to be an encrypted SQLite database (SQLCipher)

[jkrauska]

Had a look at that, the training data based on the user typing history is saved in cotypist.db, which is is protected by an app-managed key, likely Keychain-backed. Unless someone manage to reverse-engineer the encryption/keychain flow, it's most likely not possible to migrate the data.

appears to be an encrypted SQLite database (SQLCipher)

Uses GRDB.swift + SQLCipher (found github.com/groue/GRDB.swift and the SQLCipher format signatures in the binary; SQLite/SQLCipher is statically linked, which is why otool -L showed no libsqlite3). It uses stock SQLCipher 4 defaults (4096-byte pages, AES-256-CBC, PBKDF2-HMAC-SHA512, per-page HMAC).

One non-obvious detail: the key in the keychain is passed as a passphrase string, not as a raw key.

You can ask any robot to find the key and then inspect your data.

CREATE TABLE "user_inputs" (
    "id"                    TEXT     PRIMARY KEY NOT NULL,
    "createdAt"             DATETIME NOT NULL,
    "updatedAt"             DATETIME NOT NULL,
    "cotypistVersion"       INTEGER,
    "appBundleIdentifier"   TEXT     NOT NULL,
    "appProperties"         TEXT     NOT NULL,   -- JSON
    "textFieldProperties"   TEXT     NOT NULL,   -- JSON
    "screenshotText"        TEXT,                -- OCR'd text
    "textUpToCursor"        TEXT     NOT NULL,
    "selectedText"          TEXT,
    "textAfterCursor"       TEXT,
    "textLanguage"          TEXT,
    "propertyBagString"     TEXT,                -- JSON
    "screenshotData"        BLOB,                -- raw image bytes
    "domain"                TEXT,
    "typingContext"         TEXT
);
CREATE TABLE "app_overrides" (
    "id"         TEXT     PRIMARY KEY NOT NULL,
    "overrides"  TEXT     NOT NULL,   -- JSON
    "updatedAt"  DATETIME NOT NULL
);

user_inputs is the whole product in one table: each row captures one editing moment — the text split around the caret (textUpToCursor / selectedText / textAfterCursor), plus environmental context (appBundleIdentifier, domain, typingContext, OCR'd screenshotText, and the raw screenshotData image). The three JSON columns (appProperties, textFieldProperties, propertyBagString) are denormalized metadata bags rather than separate tables.

[jkrauska]

so now I know how to /extract/ my data.. but I don't know how to feed it back to cotabby. How does cotabby store my data?