-
-
Notifications
You must be signed in to change notification settings - Fork 97
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.
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
Better description of the mainline of a PL event. #1107
Conversation
``iteratively descending through the `m.room.power_levels` events in the `auth_events`-starting at *e*.`` was also unclear to me. Unfortunately this is now more symbol-dense and I'm not sure if it's a net improvement.
I'm not as convinced by e2d8cfc. I'll leave the reviewer to judge. |
descending through the `m.room.power_levels` events in the `auth_events` | ||
starting at *e*. If no mainline event is encountered when iteratively | ||
descending through the `m.room.power_levels` events, then the closest | ||
Given another event *e* = *e<sub>0</sub>* we can compute a similar list of |
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.
The old definition didn't seem to allow for e
(e_0
) itself to be the closest mainline event to e, but the new one seems to allow it. Is this correct?
Also, is e
meant to be an arbitrary event here or another m.room.power_levels
event?
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.
Not sure, I'll consider this more carefully.
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.
The old definition didn't seem to allow for
e
(e_0
) itself to be the closest mainline event to e, but the new one seems to allow it. Is this correct?
I think there is some leeway here. What matters is that part (1) of the mainline ordering is unchanged (we don't use this notion of closest mainline event anywhere else AFAICS).
Also, is
e
meant to be an arbitrary event here or anotherm.room.power_levels
event?
I think e
is arbitrary, including the possibility that e
is another m.room.power_levels
event.
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 think there is some leeway here. What matters is that part (1) of the mainline ordering is unchanged (we don't use this notion of closest mainline event anywhere else AFAICS).
The idea I had was: what if e
is a m.room.power_levels
event itself and it has no m.room.power_levels
in its auth_events
? Then e
would be the closest mainline event to e
according to the new definition, but not according to the old one.
In any case, looks to me like you fixed the concern in the new version 👍🏻
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.
Then
e
would be the closest mainline event toe
according to the new definition, but not according to the old one.
Agreed. And I think that change would be a mistake. My rough sense of this is that we're trying to see where e
fits into the history of power level events, so that "older" events are ordered first.
Co-authored-by: Denis Kasak <[email protected]>
This has undergone a fairly large rework, so needs careful inspection.
looks better in Firefox. I am sad to be writing a poor man's TeX though.
I have rewritten things more dramatically; this needs careful interrogation, https://pr1107--matrix-spec-previews.netlify.app/rooms/v9/#definitions for the rendered view. |
I can't request reviewers, but I'd also appreciate @erikjohnston here |
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.
Left some minor suggestions, but overall this reads much more clearly to me and is a definite improvement over the current situation. I also believe it is a correct translation of the original text, but I'd love Erik to see it too.
event in its `auth_events`. | ||
The *mainline of P*<sub>0</sub> is the list of events | ||
[*P*<sub>n</sub> , ... , *P*<sub>1</sub>, *P*<sub>0</sub>], | ||
ordered from oldest to newest. |
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.
The implicit reference to time in the form of "oldest and newest" is throwing me here a bit. Perhaps this?
ordered from oldest to newest. | |
ordered such that the indices are descending, so that the event we started with is last. |
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.
For what it's worth: each prev_events
edges, or "older" as determined by origin_server_ts
or even received_ts
. So I agree that "older" is more trouble than it's worth.
However: now that we have explicit indices that the text later refers to, I'd be tempted to just write it out starting with
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 think this comment thread is outdated. The current wording includes explicit indexes and is clear for me.
Co-authored-by: Denis Kasak <[email protected]>
Co-authored-by: Denis Kasak <[email protected]>
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.
much improved for sure! Some minor suggestions
Co-authored-by: Travis Ralston <[email protected]>
Co-authored-by: Richard van der Hoff <[email protected]>
Co-authored-by: Richard van der Hoff <[email protected]>
Co-authored-by: Richard van der Hoff <[email protected]>
Co-authored-by: Richard van der Hoff <[email protected]>
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.
lgtm!
Resolves #1106.
Preview: https://pr1107--matrix-spec-previews.netlify.app