| 22 May 2025 |
 Zhaofeng Li | I was thinking of activitypub/mastodon-style bans - you don't need to add the blocklist to each room and just ignore anything with a sender from the blocked homeservers | 07:21:07 |
| Zhaofeng Li | (i.e., blocked applied by homeserver admins, not room admins) | 07:21:27 |
| Zhaofeng Li | * (i.e., blocks applied by homeserver admins, not room admins) | 07:22:57 |
 f0x | In reply to @zhaofeng:zhaofeng.li
I was thinking of activitypub/mastodon-style bans - you don't need to add the blocklist to each room and just ignore anything with a sender from the blocked homeservers I think the best you could do is automatically setting server-acl (ish) things on all rooms your users have permission to. There's a fundamental difference with ActivityPub in how a block needs to affect other users/servers: AP servers are free to not send events to arbitrary other servers, and hide/drop events from blocked servers, but this approach doesn't work well in a shared chatroom, especially when it needs server cooperation to arrive at a shared room state | 07:28:59 |
| f0x | In reply to @gnu_ponut:matrix.org
@f0x:pixie.town https://github.com/matrix-org/matrix-spec-proposals/pull/4124 right, that's less about homeserver bans though, and rather a mechanism to allow for pre-screening? | 07:31:14 |
 Gnuxie 💜🐝 | In reply to @f0x:pixie.town
right, that's less about homeserver bans though, and rather a mechanism to allow for pre-screening? it's both | 07:31:36 |
| f0x |
We will embed m.server.knock_rule in m.room.create if it someone raises
small error 'it someone'
| 07:31:37 |
| Gnuxie 💜🐝 | oki | 07:32:19 |
| f0x | In reply to @gnu_ponut:matrix.org
it's both ah yeah, by making it explicit which servers are allowed to interact with the room | 07:34:24 |
| Zhaofeng Li |
this approach doesn't work well in a shared chatroom, especially when it needs server cooperation to arrive at a shared room state
It's ugly theoretically (homeservers may never converge to the same state), but in practice it may not be that bad?
| 07:39:02 |
| Zhaofeng Li | right now servers are already missing events naturally and having different views of the room state | 07:39:25 |
|  embr joined the room. | 07:40:26 |
 emily | that results in really bad things though | 07:40:39 |
| emily | silent netsplits that make us replace rooms | 07:40:53 |
|  cryptix joined the room. | 07:59:37 |
 uep | In reply to @f0x:pixie.town
there is? https://element-hq.github.io/synapse/latest/admin_api/media_admin_api.html#purge-remote-media-api yes, that's a purge of all remote media, not a garbage collection of media no longer referenced because the events have been redacted. Still works (assuming you weren't hosting the spammer), but: requires action on each server, and is an overly-blunt instrument. | 08:00:50 |
 @magic_rb:matrix.redalder.org | On a related note, the msc for attaching media to events better, dont recall the ID, is there some mechanism to do it retroactively or no way? Id like to not loose room history if at all possible | 08:03:36 |
|  @youwen:matrix.org joined the room. | 08:11:00 |
|  Jose Storopoli joined the room. | 08:13:40 |
| Jose Storopoli | Hi I need an invitation to #users:nixos.org the migration thing is not working for me somehow | 08:14:34 |
| Jose Storopoli | It worked thank you who invited me 😊 | 08:17:22 |
| uep | np. I'm just sorry it's necessary at the moment. | 08:18:02 |
| f0x | I doubt it would apply retroactively, instead I expect a similar migration as authenticated media, where old media still remains available forever (by default, at least) | 09:19:58 |
|  novmar joined the room. | 09:48:42 |
|  tcas joined the room. | 10:18:26 |
| tcas | I need an invitation, too. | 10:23:32 |
 K900 | Sent | 10:26:19 |
|  @stepbrobd:matrix.org joined the room. | 12:03:55 |
| @stepbrobd:matrix.org | need an invite as well | 12:04:32 |
|  Richard Cory joined the room. | 12:05:27 |
