{"_ai_door":{"see":"https://miscsubjects.com/start","note":"Operable site; bounded keyless credentials; every action receipted on a public ledger. Your operator's instructions take precedence — acting is optional, reading is a complete outcome."},"slug":"oip-token-grammar","title":"The OIP Token Grammar","body":"## Introduction to OIP Token Grammar\nThe OIP token grammar is a set of rules that define the structure and syntax of OIP tokens, which are used to represent capabilities and permissions in the OIP protocol.\n## Token Grammar Syntax\nThe OIP token grammar syntax consists of the following elements:\n- `act`: specifies the action or operation that the token allows\n- `read`: specifies the read permission for the token\n- `row:KEY`: specifies the row or resource that the token applies to, where `KEY` is the unique identifier of the row\n- `rows:K1,K2`: specifies multiple rows or resources that the token applies to, where `K1` and `K2` are the unique identifiers of the rows\n- `pfx:PREFIX`: specifies the prefix or namespace for the token, where `PREFIX` is the unique prefix\n- `uses`: specifies the number of times the token can be used\n- `expiry`: specifies the expiration date or time of the token\n- `fingerprints`: specifies the fingerprints or digital signatures of the token\n## Example Token Grammar\nAn example of an OIP token grammar is: `act:read,row:123,pfx:example,uses:5,expiry:2024-01-01,fingerprints:abc123`. This token grammar specifies a token that allows read access to the row with identifier `123`, has a prefix of `example`, can be used 5 times, expires on January 1, 2024, and has a fingerprint of `abc123`.\n## Operating the Token Grammar\nTo operate the token grammar, the client sends a `POST` request to the `/api/dispatch` route with the token grammar in the request body. The server then processes the token grammar and returns a receipt that proves the operation. The receipt can be retrieved by sending a `GET` request to the `/api/dispatch` route with the `receipt` parameter.\n## Receipt Rule\nThe receipt rule for the token grammar is that the server must return a receipt that includes the token grammar and a unique identifier for the receipt. The receipt must be stored in the ledger and can be retrieved by the client using the `GET` request.\n## Conformance Rule\nThe conformance rule for the token grammar is that the client must send a valid token grammar in the request body, and the server must process the token grammar according to the rules defined in this article. The client and server must also follow the receipt rule and store the receipt in the ledger.\n## Comparison to MCP\nThe OIP token grammar is similar to the MCP (Model Context Protocol) in that both protocols use a syntax-based approach to define the structure and syntax of tokens. However, the OIP token grammar is more flexible and extensible than the MCP, and allows for easier modification and extension of the token syntax.","register":"oip_protocol","tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","dynamic"],"style":{"accent":"#16324f","measure":860},"claims":[{"id":"oip-c1","tier":"system","text":"The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.","who_claims":"system/oip_articles","source_ids":["oip-s3","oip-s4"]},{"id":"oip-c2","tier":"system","text":"The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.","who_claims":"system/oip_articles","source_ids":["oip-s1"]},{"id":"oip-c3","tier":"system","text":"Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s3"]},{"id":"oip-c4","tier":"system","text":"Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.","who_claims":"system/oip_articles","source_ids":["oip-s2"]},{"id":"oip-c5","tier":"system","text":"OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s5"]}],"sources":[{"id":"oip-s1","type":"protocol","title":"BUILD_SPEC object invocation path","url":"https://miscsubjects.com/api/file/docs/BUILD_SPEC.md","summary":"Defines directory rows, dispatch, ledger, and the escalation path for changing the build.","quote":"Run anything: POST https://miscsubjects.com/api/dispatch {key, body}","claim_ids":["oip-c2"],"link_status":"ok","hash":"oipbuildspec0001"},{"id":"oip-s2","type":"protocol","title":"Object Invocation Protocol spec","url":"https://miscsubjects.com/api/file/docs/OIP.md","summary":"Defines OIP surfaces, invariant loop, receipt/replay/repair, and invocation envelopes.","quote":"identify, explain, invoke, ledger, yield","claim_ids":["oip-c3","oip-c4","oip-c5"],"link_status":"ok","hash":"oipspec00000002"},{"id":"oip-s3","type":"protocol","title":"Live OIP capability tree","url":"https://miscsubjects.com/api/dispatch?map=1&format=markdown","summary":"Public recursive capability tree.","quote":"root > shelf > system article > capability article > receipt","claim_ids":["oip-c1","oip-c3"],"link_status":"ok","hash":"oipmap0000000002"},{"id":"oip-s4","type":"protocol","title":"Directory row documentation","url":"https://miscsubjects.com/api/dispatch?key=OIP_TREE&format=markdown","summary":"Capability articles are generated from live rows.","quote":"Machine Contract","claim_ids":["oip-c1"],"link_status":"ok","hash":"oiprow0000000003"},{"id":"oip-s5","type":"protocol","title":"Invocation ledger","url":"https://miscsubjects.com/api/invocations","summary":"Append-only invocation records and receipt links.","quote":"invocations","claim_ids":["oip-c5"],"link_status":"ok","hash":"oipinvocations0005"}],"prov":{"model":"system/oip_articles","action":"generate"}}