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.

• PDU (fixed by Remove origin from unsigned_pdu_base.yaml #998)

• Places with a similar shape to PDU:

  • the body of /make_join responses.
  • the body of v1 and v2 /send_join requests.
  • the body of v1 and v2 /send_join responses (though note that synapse doesn't actually send it (unless it was included in the request??), per Missing 'origin' field when responding to send_join over federation synapse#8786).
  • 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.

• The redaction algorithm of all current room versions; cf MSC3989.

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)

[jplatte]

Re.

the body of a send_join request

I'm seeing an origin field in other places:

• The response fields of GET /make_knock/{roomId}/{userId}
• The response fields of GET /make_leave/{roomId}/{userId}
• The Room State object (used in the response of PUT /send_join/{roomId}/{eventId})
• The InviteEvent object (used in request and response of PUT /invite/{roomId}/{eventId})

Are some of these also redundant?

[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)

I'm having a hard time deciphering this. I think what I meant was: any implementation that does not send transaction.origin is buggy, and:

The difference between transaction.origin and pdu.origin is that the ecosystem already has to deal with missing pdu.origin.

This is because Synapse does not enforce the presence of pdu.origin, and will therefore happily relay events that have no origin to other servers. In other words: if, when you receive a pdu, you insist on origin, then you cut yourself off from whole rooms; if you insist on transaction.origin, you only cut yourself off from the one server that is failing to send them.

[richvdh]

Re.

the body of a send_join request

I'm seeing an origin field in other places:

• The response fields of GET /make_knock/{roomId}/{userId}

• The response fields of GET /make_leave/{roomId}/{userId}

• The Room State object (used in the response of PUT /send_join/{roomId}/{eventId})

• The InviteEvent object (used in request and response of PUT /invite/{roomId}/{eventId})

Are some of these also redundant?

Links to the relevant parts of the spec would be useful, but off the top of my head: they sound like they are just special cases of pdu.origin.

[richvdh]

Re.

the body of a send_join request

I'm seeing an origin field in other places:

* The response fields of `GET /make_knock/{roomId}/{userId}`

* The response fields of `GET /make_leave/{roomId}/{userId}`

* The `Room State` object (used in the response of `PUT /send_join/{roomId}/{eventId}`)

* The `InviteEvent` object (used in request and response of `PUT /invite/{roomId}/{eventId}`)

Are some of these also redundant?

@jplatte I found most of these references and updated the description accordingly, but I can't find what you mean with respect to the Room State object (I even looked at older spec versions). Can you provide a link to help me out?

[jplatte]

The response of PUT /_matrix/federation/v1/send_join/{roomId}/{eventId} is

Array of integer, Room State.

And the spec also uses the name "Room State" for the entire response object of the v2 endpoint. This object contains an origin field.

[richvdh]

The response of PUT /_matrix/federation/v1/send_join/{roomId}/{eventId} is

Array of integer, Room State.

And the spec also uses the name "Room State" for the entire response object of the v2 endpoint. This object contains an origin field.

Ok, that sounds like what I mean by "the body of v1 and v2 /send_join responses" in the description, so I think we've got everything on your list. Thanks!

[jplatte]

Ah yes, I guess just wrote all that I found, "other places" was wrong and misleading.

[richvdh]

Ah yes, I guess just wrote all that I found, "other places" was wrong and misleading.

To be honest I think that instance probably wasn't listed at the time you added your update - we just both found it independently! Anyway no worries, we're on the same page now.