Skip to content
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.

Sign up for GitHub

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

MSC3755: Member pronouns #3755

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

MSC3755: Member pronouns #3755

Changes from 5 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
8a8f8c6
pronouns draft
Gnuxie Mar 18, 2022
2b24f99
Fix the ridiculous prefixes.
Gnuxie Mar 18, 2022
da34fa0
Fix references to other mscs
Gnuxie Mar 18, 2022
21e7d4f
remove prefix from the pronouns object.
Gnuxie Mar 19, 2022
83db1e7
anoa feedback
Gnuxie Mar 19, 2022
97aa5a1
ShadowJonathan feedback
Gnuxie Mar 20, 2022
7b994f3
Explanation for specifying the full set.
Gnuxie Mar 20, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions proposals/3755-pronouns.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
# MSC3755: Pronouns
Copy link

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

How?

Copy link

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.

Copy link

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.

That doesn't explain anything.

Pretty obvious. No need to play the hatchling.

It's pretty not obvious, hence me asking.

Copy link

@0x1a8510f2 0x1a8510f2 Mar 26, 2022 •
edited
Loading

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.

Copy link

@no-defun-allowed no-defun-allowed Mar 26, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The theme of the discussion is a political issue, hence "political controversy".

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.

Copy link

@0x1a8510f2 0x1a8510f2 Mar 26, 2022 •
edited
Loading

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

Sure, it's controversial, but I don't see the "political" part at all.

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".

And, honestly, I also don't see why I, or the Matrix developers, should take opinions of people [...]

Please refer to: https://spec.matrix.org/v1.2/proposals/

Specifically:

  • "The proposal process involves some technical writing, having it reviewed by everyone"
  • "Proposals must act to the greater benefit of the entire Matrix ecosystem, rather than benefiting or privileging any single player or subset of players"
  • "Members of the Core Team pledge to act as a neutral custodian for Matrix on behalf of the whole ecosystem."

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.

[...] whom call proponents of ideas they don't like "lunatics" or etc too seriously.

Not my words so I see no relevance of this to your argument.

This comment was marked as off-topic.

Sign in to view

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  • m.profile in a space overrides the global profile for the entire space
  • m.profile in a subspace overrides the parent space's profile (or global if not set)
  • m.profile in a non-space room overrides the profile of the space parents (if present) or the global profile if unset

We'd define things like m.displayname, m.avatar, and possibly just m.bio for freeform text, but there'd be nothing stopping a richer client from defining org.example.pronouns or org.example.timezone for that matter.

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).

Copy link
Contributor

@ShadowJonathan ShadowJonathan Mar 27, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(At the risk of digressing from this MSC)

I believe this can be expanded (and made more easy to work with) by adjusting m.profile in subspaces and rooms to point explicitly to which profile to follow, if the user has joined a subspace, and wants everyone (including other clients of the same user) to resolve the profile "correctly", it could point to an explicit parent space (or just say "the parent space" if m.space.parent exists) to make clients resolve via there, without having to infer which parent space the user means.

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.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this kind of global < space < subspace cascading is exactly what I had in mind.

I would still suggest that a family of separate m.profile.* state event types be used instead of bundling everything up under a monolithic m.profile. This is for two reasons:

  1. The semantics of updating a finer-grained event are clearer than updating a monolithic m.profile.

    The only thing you can say about a m.profile update is "something in the profile changed" and then the client has to determine what changed manually in order to be able to display a sane message to the user. This is repeating some of the same problems with the profile being bundled in the m.room.member content.

  2. Most profile updates will change only a single profile item.

    Since there are many potentially useful things that can be added to the profile, the event is bound to get rather fat. If we use a monolithic event, this will waste lost of bandwidth and storage since the entire profile has to be repeated each time a single item changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, if MSC3760: State sub-keys gets accepted, that could also be pertinent.


There are no pronoun labels in Matrix.
We are often look to
[MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and waiting indefintley for them, this solution relies
and waiting indefinitely for them, this solution relies

on extending the m.room.member state event with a new optional field: `m.pronouns.english`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding language-specific pronouns, I have a few suggestions;

  • Swap out m.pronouns.{LANG} for m.pronouns: {"LANG": ...}, for better extensibility
  • Standardize on language codes, such as ISO 639-1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first point, I'm neutral about, but I agree with the second point. The two-character ISO 639-1 codes are fairly well-known, and would avoid the confusion of whether we should be using, say, m.pronouns.french, or m.pronouns.français in the future.

Copy link
Contributor

@ShadowJonathan ShadowJonathan Mar 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gnuxie i've seen you applied the second suggestion, but i think i'll retract my first suggestion on the basis that each language really has its own language structure, and so "data"-fying it via m.pronouns is not really helping, potentially.

If you agree with that, i'd consider this thread resolved ^^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that this totally makes sense for the current proposal in that other languages might want to have a different schema.


`m.pronouns.english` 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`

The following gives an exmample for the pronouns `They/Them`:

```
{
"m.pronouns.english":[
{
"subject":"they",
"object":"them",
"possessive":"theirs",
"possessive-determiner":"their",
"reflexive":"themselves",
"singular":"themself"
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

,
{...contenthere}

?

]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep in mind that these are specific to english, and may not apply in other languages the same.

At the very least, make note of this that this data structure shouldn't be copied blindly to other languages.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, this brings the interesting issue though that this would lead to localized data structures. Making it harder to parse as well. It would be good to have some of them as required to not end up in localized keys. Or, if not localized, weird mapping issues across languages.

I do see that issue as well, but having it language specific comes with making it way harder to parse as you can't know all keys upfront, or it might lead to conflicting key usage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder, how should a client expose those to users? an arbitrary list of contents would seem to need a language specific implementation for all the pronouns and in theory a user could have reasonably like 3 different language pronouns in a room? An MSC shouldn't really specify how something should look like in a client, but I have a bit of difficulty imagining how it could look like.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative is that a pronoun structure would be defined for every language, but that would get bloated quickly.

I wonder if it could be offloaded somehow, but regardless, I think that while prioritising English is okay-ish, thinking that every language functions like English is not.

Copy link
Contributor Author

@Gnuxie Gnuxie Mar 22, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I had an idea about how you might be able to get some genericity from this, though I think this is a bit of a lost cause and I'll explain why.

{
  "m.pronouns":{
    "m.pronouns.en":[
      {
        "summary":"They/Them please.",
        "subject":{
          "pronoun":"they",
          "example":"They were eating."
        },
        "object":{
          "pronoun":"them",
          "example":"Why don't you talk to them?"
        },
        "possessive":{
          "pronoun":"theirs",
          "example":"The wok is theirs."
        },
        "possessive-determiner":{
          "pronoun":"their",
          "example":"Why don't you ask if you can try some their food?"
        },
        "reflexive":{
          "pronoun":"themselves",
          "example":"Just let them be themselves."
        },
        "singular":{
          "pronoun":"themself",
          "example":"They like to cook by themself."
        }
      }
    ]
  }
}

So if you require every key on the object m.pronouns to have a corresponding value that is an array of objects (that i guess are pronoun sets) that have to provide a summary. Every other key in the pronoun set has to describe a single pronoun with an object that requires pronoun and example. So you have some genericity and extensibility here (it is still likely a total pain for a client UX though). The issue comes when you have a language where pronouns change the declinations of adjectives and other nouns. These rules in other languages (such a Czech) can be extremely complicated and can take entire pages/tables to describe. It is something like a masters/PhD thesis on its own to work out some kind of language agnostic way to represent things like this and that probably goes without saying.

So I wonder if instead there should just be free text description "objects" in the m.pronouns.en array. Something that allows for a summary (like "she/her" or "any") and a description (with the added multiline context for how to use each individual pronoun in the set). It might be tempting to argue that this should be a feature of a bio, and maybe it could be. However, I would argue that users should not be forced to push pronoun information into a generic biography field where the pronouns would end up out of place and unable to be specifically highlighted by clients when appropriate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, i think that trying to be correct here is kinda harming the usability of this MSC so far.

One suggestion I have is to look at how sites like pronouns.page is doing it, whom define a freeform pronouns field for now, though with some guidelines/hints;

https://en.pronouns.page/pronouns

In general, I think this MSC is edging close to scope creep, the biggest benefit for today's federation I see is having a field to write down pronouns, if this is just defined as a string field ("m.pronouns.en": "they/them") for now, it'll be much more flexible to individual needs.

One thing such an arrangement will highlight (more) is that it could become a potential vector for abuse, or for LGBTQ-general harassment with people putting "joke" values in there conforming to general X/Y structures.

Copy link
Contributor Author

@Gnuxie Gnuxie Mar 22, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spilled over into chat: https://matrix.to/#/!NasysSDfxKxZBzJJoE:matrix.org/$lFSXQEpMZbIQGh5pxXfsLVfr-gy6VUTyupxmWmc6ZGc?via=matrix.org&via=libera.chat&via=element.io

To summarise, it would be nice to try a simpler free text MSC and positioning the MSC as a thing to land while we figure out extensible profiles is probably best for speed purposes, though if it can wait a while longer then it could be worth blocking on extensible profiles.

This comment was marked as abuse.

Sign in to view

This comment was marked as off-topic.

Sign in to view

}
```

### 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
Copy link

@austinhuang0131 austinhuang0131 Mar 28, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 we/us but in a specific room I may need to change it to he/him. Because my default pronouns will be public anyway (given that it is, supposedly, linked to a user), I might as well send the default pronouns we/us as something like m.profile.pronouns when I join a room, while I can override it to a room-specific one he/him with something like m.room.pronouns, such that the client displays the room one first and then the profile one in the context of a room, but the profile one in the context of a DM

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.english` field would instead be `ge.applied-langua.msc3755.pronouns.english` instead.

## Dependencies

None known.