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 1 commit
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
77 changes: 77 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,77 @@
# 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/blob/matthew/msc1769/proposals/1769-extensible-profiles-as-rooms.md)
turt2live marked this conversation as resolved.
Show resolved Hide resolved
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/blob/matthew/msc1769/proposals/1769-extensible-profiles-as-rooms.md)
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 event with a new field: `ge.applied-langua.ge.pronouns.english`.

`ge.applied-langua.ge.pronouns.english` is a list of pronouns in order of user precedence.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

The pronouns each have the required fields `ge.applied-langua.ge.pronouns.english.subject`
& `ge.applied-langua.ge.pronouns.english.object`
as well as the optional fields `ge.applied-langua.ge.pronouns.english.possessive`,
`ge.applied-langua.ge.pronouns.english.possessive-determiner`,
`ge.applied-langua.ge.pronouns.english.reflexive` and `ge.applied-langua.ge.pronouns.english.singular`

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

```
{
"ge.applied-langua.ge.pronouns.english":[
{
"ge.applied-langua.ge.pronouns.english.subject":"they",
"ge.applied-langua.ge.pronouns.english.object":"them",
"ge.applied-langua.ge.pronouns.english.possessive":"theirs",
"ge.applied-langua.ge.pronouns.english.possessive-determiner":"their",
"ge.applied-langua.ge.pronouns.english.reflexive":"themselves",
"ge.applied-langua.ge.pronouns.english.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}

?

]
}
```

### 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 someone's pronouns that are used
only in certain contexts and out them. Unsure if this has been fixed yet.

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.


## Alternatives

* An extensible state event combined with [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc1769/proposals/1769-extensible-profiles-as-rooms.md).


## Security considerations

No considertion taken so far.

## Unstable prefix

*If a proposal is implemented before it is included in the spec, then implementers must ensure that the
implementation is compatible with the final version that lands in the spec. This generally means that
experimental implementations should use `/unstable` endpoints, and use vendor prefixes where necessary.
For more information, see [MSC2324](https://github.com/matrix-org/matrix-doc/pull/2324). This section
should be used to document things such as what endpoints and names are being used while the feature is
in development, the name of the unstable feature flag to use to detect support for the feature, or what
migration steps are needed to switch to newer versions of the proposal.*

## Dependencies

None known.