MSC3755: Member pronouns #3755
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,95 @@ | ||||||
| # MSC3755: Pronouns | ||||||
|
There was a problem hiding this comment. I'm certain it's already been discussed in one or more threads already, but an option might be to get halfway to extensible profiles by implementing what the per-room and per-space behaviour would be. It doesn't necessarily solve the global profile usecase (because peeking and rooms and such), but we can at least target cases where this information is likely to show up in (individual rooms and spaces). Taking @dkasak's suggestion of profile events in a room (where I will note many of the described conditions already exist), we can encrypt the state events when possible and simply let it be a freeform, namespaced, object. These state events would override the nearest parent to describe the profile for that context. Once we have extensible profiles for real, this would look like:
We'd define things like The formal details of this system would be worked out by extensible profiles, but as a stopgap it might work while appeasing the general crowd's concerns. Given encrypted state events is scifi at the moment, and join conditions are a thing, it might be fine to not list that as a hard dependency for the time being (acknowledging that the server will be able to peek into your various per-space and per-room profiles, but it already can see what the space is and profile data within). There was a problem hiding this comment. (At the risk of digressing from this MSC)I believe this can be expanded (and made more easy to work with) by adjusting The same for rooms, where it'd point to a space, or "global" for the user profile, to make it explicit which profile its following. In a previous idea, I was thinking up some elaborate inference rules by how clients would update their profile upon changes, but after some thinking, I decided this was very fragile and overly complex for clients to implement. (For those interested, i talk about it around here in the Element Design room). This almost warrants its own MSC, but seeing as extensible profiles is still in-progress, i'll hold off on that, and just poke this idea here. (Possibly via this idea, one can easily manage multiple profile rooms at once, to hold multiple identities via a single user account, and update them seperately.) There was a problem hiding this comment. Yes, this kind of global < space < subspace cascading is exactly what I had in mind. I would still suggest that a family of separate
There was a problem hiding this comment. Or, if MSC3760: State sub-keys gets accepted, that could also be pertinent. |
||||||
|
|
||||||
| There are no pronoun labels in Matrix. | ||||||
| We often look to | ||||||
| [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) | ||||||
|
There was a problem hiding this comment. I personally think that the data structures defined in this proposal can be additive, and could be "imported" to the profile room MSC when that progresses or passes. |
||||||
| as the solution to this problem, but little progress has been made | ||||||
| and even with 1769, there would still need to be a representation of | ||||||
| pronouns. | ||||||
|
|
||||||
| ## Proposal | ||||||
|
|
||||||
| Rather than creating new precedents like [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) | ||||||
| and waiting indefintley for them, this solution relies | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| on extending the m.room.member state event with a new optional field: | ||||||
|
Comment on lines
+12
to
+14
There was a problem hiding this comment. While I welcome this effort, I'm strongly against fattening the The fact that those are bundled together leads to frequent confusion and implementation mistakes, because you now need to handle things like repeated Including more fields in it would just serve to increase this churn. And if we could do it for preferred pronouns, why not add even more stuff to it? There are already comments on the MSC expressing interest in adding other info there too. I would much prefer we make extensible profiles sooner rather than muddying up the membership event waters further. There was a problem hiding this comment. I do agree, especially with
unfortunately there doesn't seem to be much confidence about how this will happen. So as discussed in #3755 (comment) I am going to continue simplifying this MSC as a thing to land while extensible profiles are worked upon. I do not mind the proposal being blocked or opposed if extensible profiles does become unblocked. There was a problem hiding this comment. As far as Cat is concerned its not that big of a concern to expand Clients that dont care about this MSC dont need to parse the data and should just carry on with their lives as if nothing changed as far as i am aware. Due to that we already have this complexity i fail to see why we shouldnt utilise it. Another MSC is free to try to simplify matters by doing the proposed stripping down of the membership event that i propose earlier in this comment. The bigger concern is putting in other things that are not as justifiable for inclusion that are more fitted to Extensible profiles. There is a whole laundry list of things i would love to see today but i know all of those are more suited for extensible profiles because trying to do them via To end i would like to say that Extensible profiles making this MSC not needed is ofc the optimal solution but i envision this MSC as a bandaid fix and not as the end all be all fix because that is closer to what Extensible profiles will provide us. There was a problem hiding this comment. Putting this in Instead, let's just make this a separate Once profiles-as-rooms become a thing, we'll send exactly the same events into them, but there they will refer to a global public profile instead of a per-room one. This also gives us a way to eventually deprecate |
||||||
| `m.pronouns.en`. | ||||||
| The name of this field uses a [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) | ||||||
| code to classify a set of pronouns for the english language. | ||||||
|
|
||||||
| `m.pronouns.en` is a list of pronouns in order of user preference. | ||||||
|
|
||||||
| The pronouns each have the required fields `subject` | ||||||
| & `object` | ||||||
| as well as the optional fields `possessive`, | ||||||
| `possessive-determiner`, | ||||||
| `reflexive` and `singular`. | ||||||
| These are directly inspired from the site https://pronoun.is, | ||||||
| which gives examples for how to use a set of pronouns. | ||||||
| This set of pronouns only works with the english language | ||||||
| and cannot be used to specify pronouns for other languages | ||||||
| or blindly copied to do so. | ||||||
| A single text field can be considered problematic, | ||||||
| especially with neopronouns, as it can be hard for someone | ||||||
|
There was a problem hiding this comment. Neopronouns are something that's entirely novel to the LGBTQ+ community as of yet, a small note explaining what neopronouns are would probably help here. |
||||||
| who is new to a set of neopronouns to derive the others from just the | ||||||
| subject & object pronouns. We believe that specifying only | ||||||
| the subject and object pronouns can unfortunately lead to neopronouns | ||||||
| being ignored when referring to someone who has them. | ||||||
| Specifying each pronoun means that clients and bots can also use | ||||||
| the pronouns when referring to other users. | ||||||
|
|
||||||
|
|
||||||
| The following gives an example for the pronouns `They/Them`: | ||||||
|
|
||||||
| ``` | ||||||
| { | ||||||
| "m.pronouns.en":[ | ||||||
| { | ||||||
| "subject":"they", | ||||||
| "object":"them", | ||||||
| "possessive":"theirs", | ||||||
| "possessive-determiner":"their", | ||||||
| "reflexive":"themselves", | ||||||
| "singular":"themself" | ||||||
| } | ||||||
|
There was a problem hiding this comment. and if multiple pronouns are fine (or if the person isn't sure what they are using at a given time), I guess this can be extended with ? |
||||||
| ] | ||||||
| } | ||||||
| ``` | ||||||
|
|
||||||
| ### Disclaimer | ||||||
|
|
||||||
| The author is not a linguist and knows nothing about natural language. | ||||||
|
|
||||||
| ## Potential issues | ||||||
|
|
||||||
| Changing avatars and displayname is already a cause of concern for | ||||||
|
There was a problem hiding this comment. Changing avatar and display name also overrides any values that does not match the default value. Does this proposal address that? One way would be to send the default values in a separate event (preferably among other profile stuff in MSC1769, in fact I would prefer pronouns to be addressed in a comprehensive proposal among other profile properties than making a new one) while using this event to override them...? For example, my default pronouns are |
||||||
| users who are in lots of rooms as it takes a long time on Synapse to | ||||||
| update the member event for all the rooms. | ||||||
|
|
||||||
| The profile directory may also [leak](https://github.com/matrix-org/synapse/issues/5677) | ||||||
| someone's pronouns that are used only in certain contexts and out them. | ||||||
|
|
||||||
| This is very english centric and only specifies pronouns for english. | ||||||
|
There was a problem hiding this comment. Are other languages an issue for another MSC or is there a plan to extend this? I can think of at least Swedish, Spanish, Russian, French, Esperanto as having gendered pronouns, some have accepted neutral ones, and many other languages likely exist too with multiple pronoun choices. There was a problem hiding this comment. There is also weird case of Finnish where there is only singular "hän" pronoun, but in spoken language everyone is "se" (it) anyway and I wonder if that being fine should be separately communicable. There was a problem hiding this comment. This is a good point. I explain a little it about how we could make this more generic and extensible here #3755 (comment) but I think we're better off moving back to some simpler summary/description fields that can accommodate for other languages (and special cases) better. I'm going to check out some of the links others have posted since before I start that though. |
||||||
|
|
||||||
| Pronouns could be used maliciously by inserting abusive text in their place. | ||||||
|
|
||||||
| ## Alternatives | ||||||
|
|
||||||
| * An [extensible](https://github.com/matrix-org/matrix-spec-proposals/pull/1767) | ||||||
| state event combined with [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769). | ||||||
|
|
||||||
| * An alternative involving per room profiles and spaces [MSC3189](https://github.com/matrix-org/matrix-spec-proposals/pull/3189). | ||||||
|
|
||||||
|
|
||||||
| ## Security considerations | ||||||
|
|
||||||
| No considertion taken so far. | ||||||
|
|
||||||
| ## Unstable prefix | ||||||
|
|
||||||
| While this MSC is not considered stable by the specification, implementations *must* use | ||||||
| `ge.applied-langua.msc3755` as a prefix to denote the unstable functionality. For example, | ||||||
| the `m.pronouns.en` field would instead be `ge.applied-langua.msc3755.pronouns.en` instead. | ||||||
|
|
||||||
| ## Dependencies | ||||||
|
|
||||||
| None known. | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the numerous potential issues and cleaner alternative solutions, I don't think this is viable. Users both in Matrix and many other platforms have started using nicknames to display this and other information which means that the need for this isn't too urgent to wait for a cleaner solution like the profiles MSC.
While one might argue that this information is necessary to correctly address a user, this argument could be made for languages (needed to communicate with the user in their preferred language), timezones (needed to communicate with the user at reasonable times), titles (also needed to correctly address the user) and probably many others. And, as usual, there's already an MSC for that; this being extensible profiles. There's no reason for this specific metadata to be given a special place.
There's also no avoiding the fact that this change has potential to cause controversy politically, which is probably something to avoid in a protocol's specification.
To clarify, I am strongly opposed to this MSC specifically and believe it should come under MSC1769.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd argue that is a strong indicator that a clean solution should be needed, if everyone needs to dump that information into their nicknames, instead of a bio or the likes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh I think that is a reason why people want extensible profiles all the time. This MSC is basically a subset from it in a way. However, while I still want ext profiles, I do think this change is necessary. Pronouns are part of every day life by now. And honestly it is a major social offense misusing it. While choosing a wrong timezone is bad, it is not an offense.
I strongly believe you can weigh pronouns and things like titles or timezones the same way as pronouns. They are not even close to being equal.
Also, additionally languages are a non issue as people tend to just use it when writing. It usually solves itself with normal social interaction. While pronouns can't do that because you need them before you can start interacting with a person.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@no-defun-allowed Please refer to all the minimised and deleted comments, variety in votes and the various arguments going on in threads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't explain anything.
It's pretty not obvious, hence me asking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@no-defun-allowed
Please refer to: https://dictionary.cambridge.org/dictionary/english/controversial
[read in slightly sarcastic tone] You'll notice that what is currently occuring in relation to MSC appears to closely resemble the situation described in the dictionary above. The theme of the discussion is a political issue, hence "political controversy".
In any case, as I believe I've made my point and you are making no points of your own, I'll take any further replies to be trolling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, it's controversial, but I don't see the "political" part at all. And, honestly, I also don't see why I, or the Matrix developers, should take opinions of people whom call proponents of ideas they don't like "lunatics" or etc too seriously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine, I'll bite one last time, since you've made a point
If you were to take a guess where on the political compass the line separating those "for" and "against" this idea (not this MSC) is, you'd answer your own question. In any case, the important part of my point was "controversy" not "political".
Please refer to: https://spec.matrix.org/v1.2/proposals/
Specifically:
So I guess there's no reason other than integrity. They are free to ignore anyone who disagrees with spec changes they want to implement, but then they're undermining the credibility of Matrix. No other reason really.
Not my words so I see no relevance of this to your argument.
This comment was marked as off-topic.
Sorry, something went wrong.