type property missing for m.reference relations

[joepie91]

I received the following event from Synapse for a bridged Telegram message:

  {
    type: 'm.room.message',
    room_id: '!redacted:pixie.town',
    sender: '@telegram_redacted:pixie.town',
    content: {
      msgtype: 'm.text',
      body: 'redacted',
      external_url: 'https://t.me/c/redacted'
    },
    origin_server_ts: 1595536311000,
    unsigned: {
      age: 710692,
      'm.relations': {
        'm.reference': {
          chunk: [
            {
              event_id: '$redacted1'
            }
          ]
        }
      }
    },
    event_id: '$redacted2',
    user_id: '@telegram_redacted:pixie.town',
    age: 710692
  },

However, MSC 1849 says:

m.reference list the event_id and event type of the events which reference that event.

... which implies that the server is required to provide the type property for the m.reference relation, but it is currently missing.

(I realize that the MSC hasn't been finalized and merged yet, but I'm filing an issue anyway to make sure it doesn't get overlooked later.)

[clokep]

Is this a bug with the Telegram bridge?

[joepie91]

As I understand it, the m.relations field is generated by the homeserver based on the related events that it is aware of, so that should be totally separate from any buggy clients/appservices.

(Though even if it were a buggy appservice, that would just make this an input validation issue!)

Anyway, seeing something similar for origin_server_ts in m.annotation, which is also missing:

  {
    content: {
      body: 'redacted',
      msgtype: 'm.text'
    },
    origin_server_ts: 1595367512866,
    room_id: '!redacted:matrix.org',
    sender: '@redacted:example.com',
    type: 'm.room.message',
    unsigned: {
      age: 171403042,
      'm.relations': {
        'm.annotation': { chunk: [ { type: 'm.reaction', key: '💥', count: 1 } ] }
      }
    },
    event_id: '$redacted',
    user_id: '@redacted:example.com',
    age: 171403042
  },

The MSC is slightly less explicit about the requiredness of that one, though.

[jerinjtitus]

Can anyone help me, I was trying to find where percisely m.relations field is generated. I am not completely sure which one it is.

[clokep]

Looks like the code around this is at

synapse/synapse/events/utils.py

Lines 382 to 393 in 9dde9c9

	annotations = await self.store.get_aggregation_groups_for_event(event_id)
	references = await self.store.get_relations_for_event(
	event_id, RelationTypes.REFERENCE, direction="f"
	)
	if annotations.chunk:
	r = serialized_event["unsigned"].setdefault("m.relations", {})
	r[RelationTypes.ANNOTATION] = annotations.to_dict()
	if references.chunk:
	r = serialized_event["unsigned"].setdefault("m.relations", {})
	r[RelationTypes.REFERENCE] = references.to_dict()

[lukasdenk]

(I realize that the MSC hasn't been finalized and merged yet, but I'm filing an issue anyway to make sure it doesn't get overlooked later.)

As statet by @joepie91, the MSC specifying that an m.reference must contain a type is still a proposal. Furthermore, it seems like MSC1849 is split in several proposals (see e.g. here). The specification of event references seems to be handled in MSC3267. There, the specification is different from this PR's description.

@clokep Since MSC3267 is still ongoing work (more specifically, it has no proposal lifetime state label), I would suggest to make clear that this issue should only be resolved after MSC3267 is accepted.

[clokep]

Since MSC3267 is still ongoing work (more specifically, it has no proposal lifetime state label), I would suggest to make clear that this issue should only be resolved after MSC3267 is accepted.

Yeah, the state of those MSCs is quite confusing; MSC3267 specifically says it doesn't declare a bundled aggregation format, but MSC2675 also doesn't declare one. (Note that MSC1849 is obsolete as you mention.)

I'll make a note on MSC3267 about this inconsistency, but for now I'm going to close this issue since it isn't clear it is a Synapse issue.