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.

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

Merged
merged 15 commits into from
Jun 15, 2022
Merged

Better description of the mainline of a PL event. #1107

merged 15 commits into from
Jun 15, 2022

Conversation

DMRobertson
Copy link
Contributor

@DMRobertson DMRobertson commented Jun 1, 2022

David Robertson added 3 commits June 1, 2022 15:25
``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.
@DMRobertson
Copy link
Contributor Author

I'm not as convinced by e2d8cfc. I'll leave the reviewer to judge.

@DMRobertson DMRobertson marked this pull request as ready for review June 1, 2022 14:59
@DMRobertson DMRobertson requested a review from a team as a code owner June 1, 2022 14:59
@turt2live turt2live self-requested a review June 1, 2022 15:34
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
Copy link
Member

@dkasak dkasak Jun 2, 2022

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

@DMRobertson DMRobertson Jun 6, 2022

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 another m.room.power_levels event?

I think e is arbitrary, including the possibility that e is another m.room.power_levels event.

Copy link
Member

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 👍🏻

Copy link
Contributor Author

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 to e 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.

content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
@DMRobertson DMRobertson marked this pull request as draft June 5, 2022 23:39
DMRobertson and others added 3 commits June 6, 2022 12:50
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
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.
@DMRobertson
Copy link
Contributor Author

I have rewritten things more dramatically; this needs careful interrogation,

https://pr1107--matrix-spec-previews.netlify.app/rooms/v9/#definitions for the rendered view.

@DMRobertson
Copy link
Contributor Author

I can't request reviewers, but I'd also appreciate @erikjohnston here

@DMRobertson DMRobertson marked this pull request as ready for review June 6, 2022 13:27
@DMRobertson DMRobertson requested a review from dkasak June 6, 2022 13:27
Copy link
Member

@dkasak dkasak left a 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.
Copy link
Member

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?

Suggested change
ordered from oldest to newest.
ordered such that the indices are descending, so that the event we started with is last.

Copy link
Contributor Author

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 $P_i$ cites $P_{i+1}$ as an auth event. So the latter is "older" in some sense... but it's not necessarily "older" in the sense implied by the 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 $P_0$ and let indices increase.

Copy link
Member

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.

content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
Copy link
Member

@richvdh richvdh left a 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

content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
DMRobertson and others added 4 commits June 14, 2022 17:19
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
@DMRobertson DMRobertson requested a review from richvdh June 14, 2022 17:17
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
content/rooms/fragments/v2-state-res.md Outdated Show resolved Hide resolved
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
@turt2live turt2live dismissed their stale review June 14, 2022 17:40

addressed

@DMRobertson DMRobertson requested a review from richvdh June 15, 2022 14:55
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

lgtm!

@richvdh richvdh merged commit 2ee2172 into matrix-org:main Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The description of a power-levels event's mainline is unclear
4 participants