[Feature Request] Separate sorting for replies

[ggtylerr]

Checklist

• I am running the latest version. Installing Isso from GitHub from the master branch does not fix my issue
• I have checked the troubleshooting guide
• I have searched the open issues, but my issue has not already been reported

What is not working?

When using the new sorting system introduced in #1005, replies are sorted the exact same as regular comments. If comments are sorted by newest first, the replies to said comments will also be sorted as such. This can potentially confuse the reader, as the reading order for threads is usually always oldest first. Here's an example of what it looks like now:

Note how the thread starts with the oldest post (the OP), then immediately after that, the newest post (the reply.)

How can one reproduce this issue?

On the client-side configuration, set data-isso-sorting to newest. (This is possibly also visible in upvotes too, but haven't tested yet.) Then, post a comment, and reply to it at least twice.

[ix5]

My personal preference would also be to list child comments chronologically (oldest first), that's how it is done on most platforms I know which only allow for 1 level of nesting.

[Pjbelser]

Hello cal is not working for Invidious Piped Beatbump Hyperpipe

[ggtylerr]

Hello cal is not working for Invidious Piped Beatbump Hyperpipe

You're on the repo for the commenting system, not in the comment section...

[ggtylerr]

Looking at this a second time, I noticed this has the "needs-decision" tag. I don't know the internal discussion, but IMO it's down to two choices:

1. Make replies always sort by oldest first.
   • This would be the most sensible option, and IMO my preferred pick. Most people using this are for people like myself, running a blog or some kind of small site that just needs a comment section. With that, and with how the comment system is designed, it's pretty much natural to have replies sort by oldest first.
   • This will also be the easiest to implement out of the two.
2. Sort by oldest first by default, but have a separate client config option to sort by newest or most upvotes.
   • This will allow for hosters using unconventional setups (possibly a reddit clone or Q&A site) to choose the sorting system best fit for their use case.
   • This will also be the hardest to implement as it involves putting in an extra config value, handling it, and documentation.

If both are to be considered, you can have the first come in on v0.13.1, and the second come in v0.14.

[ix5]

Since no one else has weighed in on this issue so far, I'm making the decision to go with option 1.
@ggtylerr it would be great of you to implement the change in a PR.

Edit: Please don't forget to also change the documentation to mention that as of 0.13.1 (?), reply sorting reverts back to oldest.

[ggtylerr]

Sure, I'll try my hand at an implementation in a few.