MSC4175: Profile field for user time zone

[clokep]

Rendered

Signed-off-by: Patrick Cloke [email protected]

---

Implementations:

• Element Web: Add timezone to user profile element-hq/matrix-react-sdk#20
• gomuks: Add timezones and pronouns tulir/gomuks#574

---

SCT:

FCP tickyboxes

MSC checklist

[Half-Shot]

matrix-org/matrix-react-sdk#12967 is an implementation of this.

[girlbossceo]

conduwuit server-side partial implementation: girlbossceo/conduwuit@f163ebf#diff-6f6ce4833edde4b67f9f5c950adce5338f3e3a19b6d287c33ff4e9d290b94fa1

ruwuma (our ruma fork) partial implementation for conduwuit:

• girlbossceo/ruwuma@bf93f9c
• girlbossceo/ruwuma@0aa4cc4
• girlbossceo/ruwuma@83a9bf7

The partial implementation only supports GET/PUT/DELETE for just the us.cloke.msc4175.tz field. More thought into supporting "generic" K-V fields is being done, but at least gets a basic implementation through the door that can be usable in any future clients that implement the timezone field (which seems likely soon 😇).

[clokep]

Judging by this having an implementation I think this isn't really a draft anymore.

[tcpipuk]

This is also implemented in gomuks: tulir/gomuks#574

[clokep]

This has a couple of implementations and has proven useful already.

I think it is reasonable and doesn't have too much room for abuse.

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Concerns:

• checklist incomplete

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[turt2live]

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

Checklist:

• Are appropriate implementation(s)
  specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example,
    modifying the set of redacted fields changes how event IDs are calculated,
    thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with
    the appendices?
• An introduction exists and clearly outlines the problem being solved.
  Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present,
  the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail
  any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.".
  See RFC3552 for things to think about,
  but in particular pay attention to the OWASP Top Ten.

[turt2live]

@mscbot concern checklist incomplete

[clokep]

I finished the couple missing bits in the checklist. Thank you for remembering to post!