-
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
any user can currently query any other user's displayname and avatar over federation if they know their userid. (SPEC-374) #168
Comments
I would like to add, that the spec should allow to specify a different avatar for each room you are in. If done right, this would allow to not set any default avatar, but a cute (maybe publicly embarrassing) one in the encrypted family chat that is not public (best avatar is also encrypted) hence not giving away anything unnecessary to the public as the OP mentioned. |
@CySlider spec currently allows per-room displaynames and avatars. It's just not a functionality exposed in Riot. (Avatars and displaynames are really just per-room state events that Riot pretends are user attributes rather than room attributes) |
@non-Jedi Perfect. Kinda missed that in my quick scan. Sorry for my ignorance. If I find some free time I'll see if I can create a pull request for Riot making use of this. |
Hmm, I checked the spec again and I can not see any API call to set a room specific avatar. The only way for the client to set an avatar seems to be:
which clearly is not room aware. Even if I send an room event with the intent to override the user's avatar with an m.room.member event. I would suggest a call like:
Which overrides the default avatar for the user in that room. UPDATE: PUT not GET |
You can set a per-room avatar or displayname by just setting the values into your own |
matrix-org/synapse#5083 covers this for the CS API, but not SS API |
Today I learned about one org that is running their synapse without federation because of privacy concerns regarding this issue. |
This seems to be fixed in synapse by matrix-org/synapse#9203? |
Correct, this was handled on Synapse's side, but it's still not standardized in Matrix. |
The behavior that was implemented in matrix-org/synapse#9203 has since been added to the spec through MSC3550. So I think this issue can be closed. |
Submitted by @matthew:matrix.org
this seems needlessly leaky
(Imported from https://matrix.org/jira/browse/SPEC-374)
The text was updated successfully, but these errors were encountered: