The CoordX Protocol carries signed and encrypted entries between parties. It proves who wrote each entry and who had permission to write it. It does not say what an entry means. That task belongs above the protocol layer. This paper describes the CoordX type system, the layer that gives entries a meaning. A type is a short document that says how to read one part of a shared record: which entries count, what each position means, what a party may do there, and what a party must do next. The type system has two key properties. It is trustless: a type is an ordinary signed object fixed by its digest, and every party evaluates it for itself over entries that the CoordX Protocol has already verified. No party has to trust a server, a registry or another party's software. It is swappable: a type names the interpreter it is written for, so many interpreters, of different capabilities and designs, can be used side by side in one record. We describe how to write type schemas, and we define the expressive power of the schema language. Payloads form a regular language. Entry structure forms a regular tree language. Every rule and every computed value is a total function in the primitive recursive class, so evaluation always halts. We compare this with KQML, FIPA-ACL and CBCL, and we relate it to language-theoretic security.
People, companies and software agents often must work on shared records even when they do not trust each other. Today they usually give those records to a central server. The server keeps the canonical copy, authenticates users, and decides who has permissions to act on the record. The CoordX Protocol removes the need for that central server. In the CoordX protocol the author of a record holds full permission over it. Permission for any other party to create, read or update the record is assigned by explicit grants and keys. An invitation only starts contact between two parties. It gives no permission. Each record is a causal tree of signed entries, and each entry is immutable. Each entry names the permission that allowed it. Any party can get the proof of that permission and check it without help from anyone. Two honest parties that check the same bytes, with the same keys and local settings, always get the same answer. The content is encrypted, so the relays that may carry it in transit see only sealed bytes. To exclude a party from future content, the other parties move to new keys. The protocol does not choose a winning version, does not put entries in time order, and does not need global agreement. Applications decide what the entries mean above the level of the protocol.