| 23 Jul 2021 |
 mscbot | [MSC3291] "MSC3291: Muting in VoIP calls" has been created: https://github.com/matrix-org/matrix-doc/pull/3291 | 00:47:09 |
|  Guest9 joined the room. | 05:12:55 |
 TravisR | !github create "Room event fields say content is the HTTP body" "> When interacting with the REST API, this is the HTTP body.
This isn't entirely true if dealing with certain APIs. Should clarify what endpoints expect it to be the body rather than blanket statement this." | 20:34:17 |
 Github | Created issue: https://github.com/matrix-org/matrix-doc/issues/3294 | 20:34:19 |
| 24 Jul 2021 |
 Sorunome | where is documentation on the widgets api and how to use it? | 11:30:31 |
 anoa | Sorunome: https://github.com/matrix-org/matrix-doc/pull/2764 has the details | 11:35:31 |
| Sorunome | great, thank you | 11:36:25 |
 Dominic Fischer | How does a client know when their invite has been rescinded/cancelled? Sync spec for convenience. | 12:15:21 |
| anoa | In reply to @dominaezzz:matrix.org
How does a client know when their invite has been rescinded/cancelled? Sync spec for convenience. I believe you'll receive the room down leave. | 12:17:38 |
 Nico | In reply to @andrewm:amorgan.xyz
I believe you'll receive the room down leave. ^this | 12:17:51 |
| anoa | as in, the leave dict of /sync. | 12:17:54 |
| Dominic Fischer | Ah, I had a feeling. Thanks! | 12:19:25 |
| Sorunome | In reply to @andrewm:amorgan.xyz
Sorunome: https://github.com/matrix-org/matrix-doc/pull/2764 has the details soru can't seem to find documentation on receiving specific events / state events / account data, but recalls something like that existing? and poking around matrix-widget-api repo seems to confirm that existing? | 14:49:16 |
| Sorunome | ah, it's 2762 | 14:50:30 |
|  creme joined the room. | 20:56:06 |
| 25 Jul 2021 |
|  preston changed their profile picture. | 03:22:20 |
 Luilegeant | Hello, I would like to have an option to configure presence over federation. In simple words: "authorise / block a list of HS to receive my HS presence events.".
Should I consider writing a MSC for this or just look into a PR into synapse "directly" ?
Side question (to make sure I've understood the spec correctly): When a user's presence is sent over federation the receiving HS does the calculation on which of his users receives the presence info (and we currently have no way from the emitting HS to limit this) ? | 06:04:06 |
| TravisR | Implementing it in Synapse would probably be the first step, likely as a per-user option backed by account data (for ease of use). The MSC would mostly just define what that account data object looks like, similar to how ignoring users works. | 06:06:54 |
| TravisR | As for how it's sent, yes: the sending server figures out which servers need to know then throws that over federation for the receiver to distribute. It's the same principle for events barred by history visibility. | 06:07:36 |
| Luilegeant | In reply to @travis:t2l.io
Implementing it in Synapse would probably be the first step, likely as a per-user option backed by account data (for ease of use). The MSC would mostly just define what that account data object looks like, similar to how ignoring users works. Right now, I was looking at a simple feature that a sysadmin would turn on or off on the server level rather than something that could be tuned on a per user basis.
Example:
- An office HS would advertise presence to its member but not to the outside world.
- My family HS would advertise presence for its member, but be able to receive my presence update from my work account from my work HS.
The reason I'm proposing this "little" change would make it easier for me than jumping into the big topic of refactoring the presence permission thingy (as mentioned in a few tickets/pr).
| 06:11:33 |
| TravisR | ah, the only reason I mention a per-user config is that Synapse typically gears itself towards a large variety of deployments. The most extensible of those deployments is per-user configs, with the server being able to send down a default to clients (akin to how fully_read markers work, where the account data is read only for the client but sent by the server). | 06:14:13 |
| TravisR | Something defined at the server level would be awkward for public/large deployments, though obviously ideal for fixed-scope or single user instances. | 06:14:42 |
| Luilegeant | This makes me thing of another option: enable presence only on the current HS and not elsewhere and its similar to MSC1862 | 06:20:07 |
| Luilegeant | Thank you for the feedback, i'll dig into the rabbit hole a bit further... 🐰 | 06:20:31 |
|  ferhan joined the room. | 15:38:00 |
|  neil_away changed their display name from neil to neil_away. | 20:22:50 |
| mscbot | [MSC3083] "MSC3083: Restricting room membership based on membership in other rooms" has now finished final comment period: https://github.com/matrix-org/matrix-doc/pull/3083 | 21:17:35 |
| 26 Jul 2021 |
|  Erkin Alp joined the room. | 12:30:53 |
| Erkin Alp left the room. | 12:31:34 |
|  uhoreg changed their display name from uhoreg (away) to uhoreg. | 14:06:12 |
