Add support for MSC4155 #1013
No reviewers
nex
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status/Blocked
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
To-Merge
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!1013
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "ginger/msc4155"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
rendered msc here. Closes #836.
debian_versionfor consistencya5a8dc32bc053c18f9b6988d3bbcea0c97e28ef8@ -77,0 +80,4 @@// return an error for blocked invites. ignored invites aren't handled here// since the recipient's membership should still be changed to `invite`.// they're filtered out in api::client::message::is_ignored_pduif matches!(recipient_filter_level, FilterLevel::Block) {this is different from the old behavior where if the recipient had the sender ignored in
m.ignored_user_listtheir membership would never be changed. the spec says "Servers must not send room invites from ignored users to clients" (which is done with the changes tois_ignored_pdu) and also "Servers may optionally decide to reject [invites from ignored users]", so this should be compliant@ -411,2 +430,3 @@for recipient_user in &invitees {if let Err(e) =invite_helper(&services, sender_user, user_id, &room_id, None, body.is_direct)invite_helper(&services, sender_user, recipient_user, &room_id, None, body.is_direct)if this
invite_helpercall fails (say, because the recipient has us blocked and we get an error from their HS), it only logs a warning and doesn't fail the request. at this point in the creation process we can't exactly return an error but it still feels very bad to not provide any feedback at all here.We don't provide feedback if invites fail at all during the room create process anyway, there isn't really a way to without failing the whole request
makes sense. I'd argue that's a flaw with the room creation process as specced but opening a MSC to fix it is probably out of the scope of this PR lol
WIP: Add support for MSC4155to Add support for MSC4155520ca315be862bcfa17d@ -295,0 +309,4 @@&& event.get_content::<RoomMemberEventContent>().is_ok_and(|content| content.membership == MembershipState::Invite)&& servicesDoes this ignore ALL invites from an ignored sender? Or only ones to ourselves?
turns out this function doesn't get called with member state events at all! the fixed filtering code does only ignore invites to ourselves
Are state events handled properly? Invites from remote users in particular show up in sync under their own room with stripped state events, rather than in the timeline
tzprofile field da222d6e35asyncmarker b60a63c026u.prefix051564fbaffaa35e4ffe