I am interested, is it possible to change the order of answers. Newest ones to be the first, not at the bottom of
73
There does not appear to be any setting to do that currently .If the reflector builders create one, details would be posted.
Not enough Clicking on the bottom of the timeline?
I can see where Damir is coming from. I’m probably not the only one on here that pays by the byte for internet. Scrolling past all the old content implies that my machine has DOWNLOADED it as well. Yep, every time, even when I’ve seen it many times before, as in the case of really interesting threads!
73
John
Dragging the vertical slider on the right takes you rapidly to any point in the thread without having to scroll through and load all the content.
I don’t usually click the direct links to threads from SOTAwatch, as they take me to the top of the thread every time. Instead I use them just as a reminder to visit the reflector. From its index I can follow a link directly to the first reply I havn’t read in a thread.
1 Like
I have no problems with my internet. Using flat rate 100 MBits for 15 euros/month. I am just used to click on the last answer and directly jump to it.
I think I am lazy 
An issue which repeatedly crops up happens because people are reading the messages when not logged in. If you are logged in when reading then the software remembers where you have read up to in each topic. When you return to the topic later on you will be positioned at the first new message. This only happens when you are logged in and when you click on the topics from the front page of the reflector.
There is “Reflector Latest” column on SOTAwatch that shows the topics with the most recent activity with newest at the top. You can click on these to jump to the topics on the reflector. HOWEVER, there is no way when jumping from SOTAwatch to the reflector to make the reflector know who you are so that it takes you to the latest post in that that topic, it takes you to the top of the topic, the old post.
e.g. There is a topic SW-3B-QRP-CW-TRX with 89 posts so far. If I click on “SW-3B-QRP-CW-TRX” from the front page of the reflector I get taken to Jarek SP8MA’s post which is the last post made. This is correct as I have been reading the posts in that topic. If I click on “SW-3B-QRP-CW-TRX” from SOTAwatch I get taken to the first post by Guru EA2IF in November 2019.
It’s all a matter of how you access the topics as to where the software will take you. And, as Simon says, you can use the vertical scroll bar to quickly move through without downloading the intermediate posts.
1 Like
If I’m logged in on Sotawatch (sotawatch.sota.org.uk) then shouldn’t the Sota Single Sign On mean that I’m also logged in to the reflector (reflector.sota.org.uk) when I click on a “Reflector Latest” topic?
If not then is it possible to pass a token/cookie of some sort in the link to make the reflector know who I am and that I’m logged in.
No. It doesn’t use SSO.
There are limits placed on us by the hosts of the reflector software. One of them was we were hitting their API too frequently. Those limits actually do limit what is feasible.
Discourse SSO is very different to every other kind of SSO, which means it’s not straightforward to do the shift over. I have some ideas on it, but it’s not something I’m going to switch on without a lot of testing 
1 Like
Speaking as a retired software developer, that is very wise.
My modus operandi for looking at SOTA stuff is to have the Spots page in a permanently open tab, I then click on anything that looks interesting in the “Reflector latest” column of subjects to view the posts. I suspect this is a very common method for people to view the reflector. If my behaviour is coped by even 30% of the users than I think a solution to the log in transfer should be given some priority.
There’s a lot of additional complexity such that making changes that might inadvertently prevent folks (including admins) logging in is a big step. I’m not sure it’s a step that warrants more priority than it’s already getting due to the risk.
For example - the reflector uses callsigns instead of usernames as a login tool. Therefore, there has to be some secure way to tie Callsigns to SSO accounts. Discourse SSO has a way of identifying its own accounts and tying them to a different system ID, but it has to be able to be done during the transfer such that, say, the G8TMV associated SSO account doesn’t suddenly change its callsign to VK3ARR and inadvertently become an admin account on the reflector.
Also, callsigns are not a unique identifier (despite what people think), which is evidenced by the semi-regular requests to update a callsign on here as folks progress through levels or get vanity calls. So, if someone updates their callsign on here or on SSO, there has to be a mechanism to keep things in sync.
Likewise, when an SSO account is created, there’s a process to create other accounts on the various systems as required (eg, the DB). A similar set up would be required to create a reflector account, which would potentially conflict with an existing account (plenty of people create multiple accounts when they can’t remember passwords, rather than trying the forget password link or contact MT approach). If the conflict occurs, there needs to be a way of resolving that - either by exception (“I can’t login to the reflector!”), semi-automatically (an email that says “Hey, admin, fix this account”) or automatically, which brings in all the security issues from before.
Updates to the profile as well face questions - what propagates through what systems? Discourse maintains its own accounts (or at least, that’s the least complex option of their SSO) and passes auth off to the remote provider. If I change my account on the reflector, must that change propagate back to SSO? Probably, but maybe not. Likewise changes on SSO propagating to Discourse. Callsign changes should be straightforward. Other changes? 
With all that said, the fact I can rattle that off without too much hassle should tell you that I have looked at it, but there’s a bunch of other stuff that’s lagging - including some of the account cleanups Andy has mentioned, and trying to trace down that occasional load spike on the API that causes an outage - that really needs to be completed prior to tackling something like this.