Upcoming API changes?

[Azeirah]

@marcobarcelos asked for this, and I think others would be interested as well.

In the recently closed issue, I mentioned I had Claude rummage through a xochitl beta binary version with Ghidra to see if it could see what is upcoming in terms of API changes.

It produced an entire research report, but a lot of it is probably noise. But there are some super interesting findings:

Everything below the horizontal line below is copied verbatim from Claude's research report, I haven't looked into any of its findings myself.

The Xochitl binary version is 3.27.1.1451, the beta version of the reMarkable software was 3.27.1.0

---

URL templates from xochitl 3.27.1 (fmtlib {} format strings)

{}{}/files/{}            ← GET/PUT blob (rmapi already uses this shape)
{}{}/files/{}/metadata   ← unknown — 404 on every host we tried
{}{}/folders/{}          ← unknown — 404 everywhere
{}{}/tree/{}             ← unknown — not tried yet
{}/delta                 ← unknown — 404 everywhere
{}.tectonic.remarkable.com  ← regional host template

The first two {} in {}{}/files/{} are presumably <host> + <base-path>. xochitl probably runs them as {host=https://eu.tectonic.remarkable.com}{base=/sync/v3}/files/{hash} — i.e., the same URL we've been hitting.

New rm-* HTTP header family

ASCII strings, embedded as constants:

rm-batch-number       rm-expect-version
rm-filename           rm-migrate-auth-v2
rm-parent-hash        rm-path
rm-recovered-empty-hash      rm-recovered-missing-hash
rm-sha256-mismatch    rm-sync-id
rm-test-data          rm-token-ttl-hint

Of these, rmapi only knows rm-filename (plus rm-token-ttl-hint, which is a response header). Strong candidates for the missing-required ones the server now demands:

• rm-expect-version — almost certainly the schema version (3 or 4)
• rm-sync-id — probably a per-sync correlation ID
• rm-parent-hash — for content-addressed v4 blob lookups
• rm-path — full document path (replacing rm-filename?)
• rm-migrate-auth-v2 — auth migration flag

URL templates (fmtlib {} style format strings)

/sync/v3/
{}{}/files/{}            ← GET blob (same as rmapi)
{}{}/files/{}/metadata   ← NEW endpoint rmapi doesn't know about

Source tree leaked via build paths: xofm::libs::sync::core::* and xofm::libs::syncinterface::*. documentsync_1_5.cpp exists — the "1.5" in their terminology equals what rmapi calls sync15/v3.

Other strings of interest

• tortoise (UTF-16) — the JWT scope sync:tortoise is real, not just a name
• document, collection near tortoise — entity types
• xofm::libs::integrations::storage::SyncThirdParty — third-party sync integration class

Discovered endpoint families

A static initializer (e.g. FUN_0046ce90, FUN_0047b8a0 — there are ~70 like it, one per compilation unit that uses sync URLs) registers these URL templates via fmt::format:

"/sync/v3/" + "{}missing"        → /sync/v3/missing
"/sync/v3/" + "{}check-files"    → /sync/v3/check-files
"/gentree/v1/" + "{}GetEntries"
"/gentree/v1/" + "{}GetFiles"
"/gentree/v1/" + "{}DeleteEntry"
"/gentree/v1/" + "{}EntrySession"
"/gentree/v1/" + "{}PutFile"
"/gentree/v1/" + "{}GetFile"      ← the new blob fetch

Plus an unused "rM sync tree" label (a SHA-256 seed for tree hashing — QCryptographicHash::QCryptographicHash(_, 4) = Sha256).

Probe results on these endpoints

endpoint	host	result
GET /sync/v3/missing	EU tectonic	200 {"hashes":[]} — defined; op=GetMissingFiles
POST /sync/v3/check-files {"files":[hash]}	EU tectonic	200 {"missingFiles":[]} — defined; op=CheckFiles
* /gentree/v1/*	EU tectonic and legacy	404 UnknownOperationName — entire namespace 404s on every host we tried

So:

• /sync/v3/missing and /sync/v3/check-files are real, new endpoints exposed on tectonic that we hadn't tried before.
• /gentree/v1/* is defined in xochitl beta firmware but does not exist on production ingress. Either: deployed only on staging/internal hosts, gated behind a feature flag we don't have, or routed through an mTLS-protected internal gateway that the device alone can reach.

[Azeirah]

I think the most notable points are:

1. {}.tectonic.remarkable.com
2. tortoise - some internal name?
3. SyncThirdParty - Either sync related to their Dropbox/Drive/Office integrations or upcoming third party sync support?
4. All the gentree/v1/ endpoints. No clue what they're about, but they seem interesting.

Note, I have no clue what of this is just internal testing and I don't know how old or new it is either.

[Azeirah]

rmapi-v4-investigation.md

Here's the full file for anyone interested.

[rmitchellscott]

Missing and check-files aren’t new. Pretty sure those are used for the archive to cloud feature and have been for some time. rmfakecloud has had those endpoints for ~2 years.

[Azeirah]

Missing and check-files aren’t new. Pretty sure those are used for the archive to cloud feature and have been for some time. rmfakecloud has had those endpoints for ~2 years.

Ah fair, this automated reverse engineering was based on what Claude knew about the backend given rmapi as a context. I'm not super familiar with how the reMarkable backend works.

Do think there're still other new interesting tidbits in there though.

[rmitchellscott]

Do think there're still other new interesting tidbits in there though.

I'm not aware of gentree so that'll be one to keep an eye on for sure!

So far I think the SyncThirdParty is just the storage and calendar integrations.

[Azeirah]

Do think there're still other new interesting tidbits in there though.

I'm not aware of gentree so that'll be one to keep an eye on for sure!

So far I think the SyncThirdParty is just the storage and calendar integrations.

Yeah I dunno, would need to dig deeper to know for sure. gentree is interesting though.

Might be related to "generative" as in "Generative" AI? E.g. how you can generate .rmdoc files from .docx files? Though it wouldn't make too much sense to have that in xochitl, you don't ever upload .docx files to the conversion step.

Probably a stretch.