Merge a9bc573268
into d6edcbd946
commit
5c93e2e9a1
@ -0,0 +1,115 @@
|
||||
# MSC3825: Obvious relation fallback location
|
||||
|
||||
[MSC3440](https://github.com/matrix-org/matrix-spec-proposals/pull/3440) defines
|
||||
a way to use replies as a fallback for threads. For that it adds an
|
||||
`is_falling_back` key. Alternatively other relations could be marked as a
|
||||
fallback in the future if we get multiple relations or other advanced features.
|
||||
Here are 2 examples, decide which one marks the reply as being a fallback and
|
||||
which one marks the thread as being a fallback:
|
||||
|
||||
```jsonc
|
||||
"m.relates_to": {
|
||||
"rel_type": "m.thread",
|
||||
"event_id": "ev1",
|
||||
"is_falling_back": true,
|
||||
"m.in_reply_to": {
|
||||
"event_id": "last_event_id_in_thread",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```jsonc
|
||||
"m.relates_to": {
|
||||
"rel_type": "m.thread",
|
||||
"event_id": "ev1",
|
||||
"m.in_reply_to": {
|
||||
"event_id": "last_event_id_in_thread",
|
||||
"is_falling_back": true,
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
You probably have read 3440 so you know that the first option is marking the
|
||||
reply in the thread relation as being a fallback. It is however not very
|
||||
logical. The second option is much clearer. It also allows generic handling of
|
||||
fallbacks in tools processing only the relations of the event like when handling
|
||||
[pushrules for relations](https://github.com/matrix-org/matrix-spec-proposals/pull/3664).
|
||||
|
||||
## Proposal
|
||||
|
||||
Move the `is_falling_back` key into the relation it applies to. This means for
|
||||
replies:
|
||||
|
||||
```jsonc
|
||||
"m.in_reply_to": {
|
||||
"event_id": "last_event_id_in_thread",
|
||||
"is_falling_back": true,
|
||||
}
|
||||
```
|
||||
|
||||
And for other relations:
|
||||
|
||||
|
||||
```jsonc
|
||||
"m.relates_to": {
|
||||
"rel_type": "my.custom.relation",
|
||||
"event_id": "ev1",
|
||||
"is_falling_back": true,
|
||||
}
|
||||
```
|
||||
|
||||
For the transition period clients might still accept the old location for
|
||||
threads until the ecosystem has been migrated.
|
||||
|
||||
The goal is to merge this change immediately before threads land in the specification.
|
||||
|
||||
## Potential issues
|
||||
|
||||
This is a breaking change to an already merged feature. This means it will break
|
||||
events already sent into rooms and make them render incorrectly. This "should be
|
||||
fine" for several reasons:
|
||||
|
||||
- The breakage means old events might show a reply relation when they should
|
||||
not. This is annoying and not pretty, but not the end of the world.
|
||||
- Clients can mitigate by hardcoding a specific `origin_server_ts` to apply the
|
||||
old rules to events. While it is strongly recommended to drop this at some
|
||||
point for maintainability reasons, it should be fairly low overhead. Once
|
||||
relations become editable, we could also fixup those events for other
|
||||
clients.
|
||||
- Thread (as of writing) are not part of a released spec version. They are
|
||||
marked as beta and users expect some things to not work optimally. As such
|
||||
minor breakage should be acceptable. They will become part of the spec in
|
||||
presumably end of Q3 2022. If we want to fix it, now is probably a better
|
||||
time than later.
|
||||
|
||||
## Alternatives
|
||||
|
||||
1. Just accept that threads are weird and never make `is_falling_back` a generic
|
||||
field. `is_falling_back` is a nice name and has otherwise clear semantics. I
|
||||
would prefer to not take that route.
|
||||
2. Fix it later. Fixing this issue later is possible by introducing a new field
|
||||
and deprecating the old one. The breakage would probably be greater.
|
||||
3. Special-case threads to have their field in that location. Not a pretty
|
||||
solution and prevents multiple relations to ever fall back to threads without
|
||||
introducing a different format.
|
||||
|
||||
## Security considerations
|
||||
|
||||
This introduces some ambiguities, so in theory it could be used to confuse
|
||||
users. Impact should be fairly limited.
|
||||
|
||||
## Unstable prefix
|
||||
|
||||
Until this MSC has finished FCP, implementations should use
|
||||
`im.nheko.msc3825.is_falling_back` as the fieldname instead.
|
||||
|
||||
## Dependencies
|
||||
|
||||
This MSC depends on threads (MSC3440), which is already merged.
|
||||
|
||||
It improves functionality in preparation of
|
||||
- Pushrules for relations,
|
||||
[MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664)
|
||||
- Multiple relations or other MSCs building on top of relations that could
|
||||
benefit from fallback semantics like
|
||||
[MSC3051](https://github.com/matrix-org/matrix-spec-proposals/pull/3051)
|
Loading…
Reference in New Issue