matrix-spec/data/api/server-server/examples/pdu_v1.json

{
    "$ref": "components/pdu_base.json",
    "event_id": "$a4ecee13e2accdadf56c1025:example.com",
    "auth_events": [
        [
            "$af232176:example.org",
            {"sha256": "abase64encodedsha256hashshouldbe43byteslong"}
        ]
    ],
    "prev_events": [
        [
            "$af232176:example.org",
            {"sha256": "abase64encodedsha256hashshouldbe43byteslong"}
        ]
    ]
}
Add specification for room version 3: Event IDs as hashes Original proposal: https://github.com/matrix-org/matrix-doc/pull/1659 Implementation proofs (some traversing of the PR tree may be required to get all of them): * https://github.com/matrix-org/synapse/pull/4483 * https://github.com/matrix-org/synapse/pull/4499 This doesn't intentionally change anything from the proposal. Implementation details: The simple part of this is the introduction of a rooms/v3.html document. The somewhat unclear part is the stuff done to the s2s definitions. This pulls `unsigned_pdu` out to `unsigned_pdu_base` (all fields except `event_id`) where it can be reused in `pdu` and `pdu_v3` (for rooms v3). These definitions are further moved into the room version specifications where they can highlight the exact schemas in detail. Version 1 has been updated to include the pre-existing event format, however the core principles of the room have not been changed. The same applies to room version 2. Room versions have immutable core principles once in the spec, otherwise these format changes would land in a pre-existing version. The client-server API event formats will need updating, however that is being punted to a different commit to try and keep these changes reviewable. 2019-01-31 01:03:03 +01:00			`{`
Refactor PDU definitions to reduce duplication (#2070) First of all, all PDU definitions were based on the v1 PDU definition with a few fields overwritten to change the format with needed. While that works when rendering the spec, this is semantically incorrect because it means that the objects must match both schemas, which is impossible. So now we make a base with only the common fields, and we add the others as needed by the room version. Note that there is no more "unsigned PDU" definition since it is not used directly, and hashes and signatures are the same across all versions. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr> 2025-03-04 18:08:42 +01:00			`"$ref": "components/pdu_base.json",`
			`"event_id": "$a4ecee13e2accdadf56c1025:example.com",`
Add specification for room version 3: Event IDs as hashes Original proposal: https://github.com/matrix-org/matrix-doc/pull/1659 Implementation proofs (some traversing of the PR tree may be required to get all of them): * https://github.com/matrix-org/synapse/pull/4483 * https://github.com/matrix-org/synapse/pull/4499 This doesn't intentionally change anything from the proposal. Implementation details: The simple part of this is the introduction of a rooms/v3.html document. The somewhat unclear part is the stuff done to the s2s definitions. This pulls `unsigned_pdu` out to `unsigned_pdu_base` (all fields except `event_id`) where it can be reused in `pdu` and `pdu_v3` (for rooms v3). These definitions are further moved into the room version specifications where they can highlight the exact schemas in detail. Version 1 has been updated to include the pre-existing event format, however the core principles of the room have not been changed. The same applies to room version 2. Room versions have immutable core principles once in the spec, otherwise these format changes would land in a pre-existing version. The client-server API event formats will need updating, however that is being punted to a different commit to try and keep these changes reviewable. 2019-01-31 01:03:03 +01:00			`"auth_events": [`
			`[`
			`"$af232176:example.org",`
			`{"sha256": "abase64encodedsha256hashshouldbe43byteslong"}`
			`]`
			`],`
			`"prev_events": [`
			`[`
			`"$af232176:example.org",`
			`{"sha256": "abase64encodedsha256hashshouldbe43byteslong"}`
			`]`
Refactor PDU definitions to reduce duplication (#2070) First of all, all PDU definitions were based on the v1 PDU definition with a few fields overwritten to change the format with needed. While that works when rendering the spec, this is semantically incorrect because it means that the objects must match both schemas, which is impossible. So now we make a base with only the common fields, and we add the others as needed by the room version. Note that there is no more "unsigned PDU" definition since it is not used directly, and hashes and signatures are the same across all versions. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr> 2025-03-04 18:08:42 +01:00			`]`
			`}`