Make `origin` field go away

[turt2live]

Updated by @richvdh 2023/05/30:

origin is specced but redundant in:

• transaction
• the body of a /backfill response.
• the body of /make_join responses.
• the body of v1 and v2 /send_join requests.
• the body of /make_knock responses.
• the body of /make_leave responses.
• the body of v1 and v2 /send_leave requests.
• the body of v1 and v2 /invite requests.

Previously, now fixed:

• PDU (fixed by Remove origin from unsigned_pdu_base.yaml #998)
• The redaction algorithm of all room versions up to 10 (fixed by MSC3989 and room version 11)
• the body of v1 and v2 /send_join responses (fixed by Remove the origin field in PUT /send_join responses #2050).

For completeness: origin is also specced as part of the X-Matrix authentication mechanism, where it is not redundant.

---

Related: matrix-org/synapse#3816

[turt2live]

Worth noting that the spec at one point said that the origin of a transaction is to be overwritten by the sending server's domain name, however this text has gone missing. In the end, it just reinforces the fact that the field should go away.

If/when the change is made, there should probably be a note about origin being a historical field that the server should ignore, otherwise people might make the same mistake as synapse despite the field being missing from the spec.

[richvdh]

also: send_join is supposed to have an origin (see https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-send-join-roomid-eventid), though synapse doesn't actually send it (matrix-org/synapse#8786)

[ShadowJonathan]

Does this need an MSC to remove?

[turt2live]

yes

[richvdh]

It seems that there already exist some implementations which do not include an origin on their outgoing PDUs, and Synapse does not insist on its presence on incoming events. I'm therefore leaning to the idea that the presence of the field in the spec should be considered a spec bug.

[turt2live]

can the same consideration be made for transaction.origin?

[richvdh]

Possibly, but if there are any implementations that omit transaction.origin, there's more room to argue that such an implementation is buggy (since transactions aren't persisted to a room DAG)