The Naibbe cipher

[tlepkali]

Subject: Three order-level measures, from someone who arrived at your architecture independently

Dear Mr Greshko,

I measured the Voynich text (ZL3b) this year and then tried to build a cipher
matching what I'd measured, working without reading the literature so as not to
fit my expectations to other people's. Chunked plaintext, several tables chosen at
random, weighted to match glyph frequencies, multiple spellings per unit — I
converged on very nearly your architecture, and was glad to find it already done
properly.

Three measures defeated my cipher and, it turns out, yours as well; I offer them
as shared ground rather than criticism. I used your `nathist_output_ciphertext.txt`,
cutting both texts into the manuscript's own line lengths so line structure is
matched.

First, though, what your cipher does better than mine did:

  measure                    Voynich    Naibbe
  h2 (digraph-merged)          2.682     2.581     4% off
  mean word length             4.95      5.23      6% off
  Zipf slope                  -0.973    -0.895     8% off
  TTR / types            0.309/3706  0.277/3322   10% off

Now the three.

Adjacent word repetition, measured against a within-line shuffle — the same words
of the same line, reordered. The choice of null turns out to matter more than
anything else here: against a global shuffle the manuscript looks anomalous, and
against the line-level one it doesn't.

    Voynich  274 observed / 269.8 expected = 1.02x  [95% CI 0.92-1.13]
    Naibbe    45 observed / 101.5 expected = 0.44x  [95% CI 0.38-0.53]

The manuscript sits at chance. Naibbe suppresses adjacency, much as natural
languages do (Latin 0.02x). If this is right, the manuscript's oddity is the
absence of a suppression every language has, rather than an excess of repeats —
which took me an embarrassingly long time to see.

Second, the word junction: mutual information between the last k glyphs of a word
and the first k of the next, minus the same quantity under a word-order shuffle,
the subtraction being there to remove estimator bias.

    k=1 excess:   Voynich 0.194 | Latin 0.048 | English 0.071 | Naibbe 0.0021
    ratio k=3/k=1: Voynich 1.25x | Latin 9.07x | English 10.51x | Naibbe 32.4x

The manuscript's constraint appears to sit on the final glyph rather than on the
ending as a whole: one pair — word-final y followed by word-initial q — carries
about 48% of the junction information, and I found no absolute prohibitions.

A caution I owe you here, since it nearly went into this letter as fact: at 6-12k
words I measured that ratio as 0.63x and believed for a while that the manuscript
was the only corpus below 1. It was sample-size bias in the 3-glyph estimate. The
figures above are the full manuscript with matched samples, and the qualitative
gap survives, but the striking version of the claim did not.

Third, word-length autocorrelation at lag 1. This one I owe to the voynich.ninja
discussion of your preprint, where it was raised and not, so far as I could see,
followed up:

    Voynich +0.134 [+0.122, +0.145]      Naibbe -0.031 [-0.043, -0.020]
    Latin -0.029, German -0.040, English -0.137, Greek -0.151, Italian -0.161

Languages alternate word lengths; the manuscript clusters them, and it is the only
corpus I have measured with a positive value. Strongest in the Stars section
(+0.186), weakest in the Herbal (+0.082).

Two things I should be straight about. The LAAFU comparison isn't meaningful for
either of us, since neither model has a line model at all and both get measured on
artificial line cuts — I mention it only so you know I looked. And on length: your
9,243 plaintext words give 34,764 ciphertext words, so the manuscript's 34,167
would carry roughly 9,000 words of Latin, about twenty book pages across 225
leaves. That may well be fine for a heavily illustrated herbal; I raise it as an
open question rather than an objection, and I don't know how to weigh it.

What strikes me is that all three are about order — what follows what — while the
construction of individual words, which is the harder-looking problem, your cipher
already handles. Whether that is a useful direction or a dead end I genuinely
don't know.

Methods and code are yours if they'd help, and I'd be glad to be told where I've
gone wrong.

With thanks for the paper,