Key log

A team in ZestSSH keeps a record of every change to who is in it, their roles and their keys. Each change is an entry signed by the member who made it and chained to the entry before, and every member’s device checks each entry for itself. The Trust page shows that record: the key log.

The key log is part of a team, so you see it in the teams you belong to. Every member sees it, on a computer and on a phone, whatever their role. See Teams overview for more on teams.

Open it

First switch to the team in the switcher, which says Personal while your personal space is open. See Teams overview for where the switcher is.

On a computer:

Choose Team in the rail. It is there while a team is open.
Choose Trust, under Records.

On a phone:

Open More.
Under Team, choose the team.
Choose Trust, under Records.

The team’s Overview also lists its Recent changes; See all opens the Trust page.

What it lists

At the top, ZestSSH says how many entries this device checked, for example “This device checked all 42 entries”. Below it is the Head: six groups of four characters, such as 3f9a 07c2 e41b 9d08 5a6e c113. They are the first 24 hexadecimal digits of the newest entry’s hash.

Then every change, newest first. On a computer the list has these columns:

Column	What it shows
#	The entry’s number in the record
Change	What changed, in words, for example who was added or whose keys were replaced
By	The member who signed it, or You
Signed with	Which version of that member’s keys signed it, as `keys v2`
First seen here	When this device first saw the entry

On a phone each change takes two lines: what changed, then who signed it, the key version and when this device first saw it.

Entries carry no times of their own, so First seen here is when this device received each one: Today, Yesterday, a weekday within the last week, a date, or Earlier for entries from before this device kept those dates. Those dates stay on this device.

The list shows 100 changes at a time. Show older changes shows the next 100.

Only the key changes

Choose Key changes instead of All changes to see only the entries that bring, replace or retire a key:

the team made, with its first keys,
a member added, or added again,
a member’s keys replaced, or given back by two owners after a recovery,
a vault’s key or the team’s key replaced,
a vault’s certificate authority.

Open an entry

Choose a change to see exactly what was signed:

Signed by: the member, and the version of their keys,
Kind: the entry’s type,
Entry hash: its own hash,
Links to: the hash of the entry before, or “Nothing: this is the first entry”,
Signature,
First seen here,
What was signed: the entry’s body, exactly as signed.

A hash or signature that does not fit on one line is cut in the middle. Its copy button copies all of it.

For a session a member opened while ZestSSH Cloud could not be reached, the entry also shows when it was, by their device’s clock. If your device can open the vault the host is in, it also shows the host, their reason, and how ZestSSH Cloud stood as their device found it. Otherwise it says those are sealed for the people who can open the vault.

Copy entry copies the entry as JSON: its number, type, signer and key version, the hash it links to, its own hash, its signature and its body as signed.

Check it again

Each entry was checked when it reached this device. Check again checks the whole record once more, from the first entry, taking nothing on trust. It checks each signature, each link to the entry before, each change against the team’s rules as they stood, and that the entries lead to the head this device keeps.

When all of it holds, ZestSSH says “Checked again just now”, with how many entries, and that every signature and link holds.
When an entry does not, ZestSSH says which one: “Entry #17 does not hold. Do not trust changes from it on, and tell your team’s owners.” The reason is shown below it, with Copy details.

Compare with a teammate

Copy head copies the six groups of the head. If a teammate’s Trust page shows the same head, your devices see the same history. Read it to each other on a call or in person.

Save the log for an audit

Owners and admins see Save the log. ZestSSH saves the whole signed record as a JSON file, named like orchard-record-1a2b3c4d-20261018.json: the first eight characters of the team’s id, then the date. Every entry is in it exactly as it was signed, so anyone can check its signatures without ZestSSH.

On a computer you choose where the file goes. ZestSSH then says where it went.
On a phone the system’s own save dialog opens.

The file holds:

the format (zestssh-orchard-record, version 1), the team’s id, the head, how many entries, and when it was saved,
how_to_check: how each entry is signed and how its hash is made, in words, so the file can be checked with nothing else,
for each entry, oldest first: its number (seq), type, the signer (by) and their key version (by_key_version), the hash it links to (prev), its own hash, its signature (base64) and its body as signed (body_json).

How entries are signed and hashed

This is what how_to_check says:

Each entry is signed with Ed25519 by the member named in by, with that member’s keys at by_key_version as the record stood before it. A member’s public key (ed25519_pub) is in the entry that added them, or in their latest change of keys.
The signed message is, in this order: the text zestssh.orchard-record.v1, the team’s id, seq, prev, type, body_json, by and by_key_version. A number (seq, by_key_version) is written as 4 bytes, big-endian. Everything else is a 4-byte big-endian length followed by its bytes: text in UTF-8, prev as the bytes its hex names, and nothing for the first entry.
An entry’s hash is SHA-256 over its signed message followed by its signature, written as a 4-byte big-endian length and the signature’s bytes.
prev is the hash of the entry before. The last entry’s hash is the head.

The file holds nothing secret: names in it are sealed, and the keys in it are public keys and commitments to keys.

What it proves, and what it does not

The key log shows that:

every change was signed by a member allowed to make it, under the team’s rules as they stood,
each change is chained to the one before, so none was taken out, changed or slipped in,
ZestSSH Cloud cannot add a member, give anyone a role or pass off a change on its own: each entry needs the signature of a member allowed to make it, and every member’s device refuses an entry whose signature or rules do not hold.

It cannot show that a member’s keys belong to that person. Someone’s keys reach you through ZestSSH Cloud when they join, which is why adding a person starts with comparing their words with them. See Create a team and invite people.

The entries carry no times, so the key log does not say when a change was made, only when this device first saw it.

Next steps

Teams overview for teams, vaults and roles.
Create a team and invite people for adding members and comparing their words.