AppServices: Why do events sent to AS's use "user_id", whereas events use "sender"

[anoadragon453]

Should be addressed in an AppServices v2. Just means we have to rename that field for each event we're sending off :)

[turt2live]

They do use sender already though? If not then no bridges would work, surely.

[anoadragon453]

They use "sender", but in the AS spec the field is called "user_id", which just means when I'm taking in an event with a "sender" field, I have to rename it to "user_id" before I send it off to the AS, is all :)

…

On 30/05/18 17:40, Travis Ralston wrote: They do use |sender| already though? If not then no bridges would work, surely. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1269 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABR7mB5690jqaaCWzLSMfPKcCdgi9meCks5t3suYgaJpZM4UToOL>.

[turt2live]

It looks like synapse actually sends both:

{
  "events": [
    {
      "age": 49803788,
      "content": {
        "avatar_url": null,
        "displayname": "_beep_user",
        "membership": "join"
      },
      "event_id": "$15270030010CYXhA:dev.t2bot.io",
      "membership": "join",
      "origin_server_ts": 1527003001647,
      "room_id": "!vfFxDRtZSSdspfTSEr:matrix.org",
      "sender": "@_beep_user:dev.t2bot.io",
      "state_key": "@_beep_user:dev.t2bot.io",
      "type": "m.room.member",
      "unsigned": {
        "age": 49803788
      },
      "user_id": "@_beep_user:dev.t2bot.io"
    }
  ]
}

Maybe this should be considered a spec bug?

[anoadragon453]

Indeed, and/or an implementation bug as that seems entirely unnecessary.

…

On 30/05/18 18:11, Travis Ralston wrote: It looks like synapse actually sends both: |{ "events": [ { "age": 49803788, "content": { "avatar_url": null, "displayname": "_beep_user", "membership": "join" }, "event_id": "$15270030010CYXhA:dev.t2bot.io", "membership": "join", "origin_server_ts": 1527003001647, "room_id": "!vfFxDRtZSSdspfTSEr:matrix.org", "sender": "@_beep_user:dev.t2bot.io", "state_key": "@_beep_user:dev.t2bot.io", "type": "m.room.member", "unsigned": { "age": 49803788 }, "user_id": "@_beep_user:dev.t2bot.io" } ] } | Maybe this should be considered a spec bug? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1269 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABR7mIzgibUizOcq7SSk4Qt26Y95Dwuoks5t3tK6gaJpZM4UToOL>.

[Half-Shot]

(Would be good if someone could check Synapse to see if there isn't any subtle difference)

[richvdh]

@Half-Shot: they are identical; the copy is done here: https://github.com/matrix-org/synapse/blob/master/synapse/events/utils.py#L197

This is an artifact of the fact that there was an older format for events (known as "v1" in some places) which used user_id here; that was of course unclear.

[anoadragon453]

It would be really great to know which of the fields in @turt2live's example are mandatory and which are not as well.

[Half-Shot]

@anoadragon453 What do you mean by mandatory, mandatory for whom?

[anoadragon453]

The app service. But I suppose everything is mandatory if we've been sending it in the past already.

[Half-Shot]

The app service. But I suppose everything is mandatory if we've been sending it in the past already.

Which one? There are many appservices. I can't remember any appservice poking at user_id, but from what I remember the node bridge/sdk don't really interact with the events at all anyway so it's not a problem from that perspective. All my bridges use sender so it's no problem my side. It would be worth deprecating it and seeing what breaks.

[anoadragon453]

I think we'll just cut it in v2 app services with a prominent warning.