To change it, go to https://discord.com/developers/applications/<client_id>/oauth2/general and update CUSTOM URL under Default Authorization Link with the appropriate link, as shown below.

In addition to managing a user's rating range roles, Liro should also hand out "Team YouTube" and "Team Twitch" roles on Discord. This gives users access to private channel based on which team they are part of.

Barebones proposal

The most basic system could just be to read from Lichess which team the user is part of, and give him a role based on that.

• No OAuth scope increase, as we don't need extra permissions to read what teams a user is part of.

This has a few limitations:

• The user needs to manually join the team on lichess.
• There is no limitation in lichess about how many teams you can join at any point.
  • This being said, lichess will force users to "choose" a team when the tournament starts, so sandbagging isn't very likely (and we have a good community)
  • This means a single user could have both roles, and end up with access to both channels.

While this isn't the cleanest implementation, it's simple and easy to do, and neither myself nor @CBrocks294 see any major issue with this simple solution.

Bells and whistles

This would require quite a bit more setup and work, however this would give us more control.

• When people link their lichess account with Liro, increase the permissions we request to also allow us to manage their teams
  • Extra OAuth scope required: team:write.
  • Store the credentials with the user so we can make requests on their behalf.
• Implement a command to join either team YT or team TTV.
  • When a team is picked:
    • Give them a role
    • Send a join request on their behalf to the correct team
    • Approve the join request through the Lichess API (this requires #9 to be implemented, and for Liro to be an admin for the teams)

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3. series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.

Potential segfault in localtime_r invocations

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

It doesn't look like Discord is changing its mind when it comes to application commands, so they probably need to be implemented at some point. This is the task I'm currently working on.

I've tried playing around with Poise, but I wasn't a fan of how opinionated it is. That's not meant as a diss or anything, it's just that I'm opinionated as well, and our opinions don't really match. I'm sure that if I had started off building liro using Poise, I would be very happy with it.

I'm taking the overly verbose and declarative route that is currently available in Serenity. I'll see if I get around to publishing a branch with my current WIP, although it may not be super interesting. The main part that I'm trying to figure out is restructuring the existing commands and making that mesh with the application commands, so that I don't need to have two parallel implementations of each command.

At the moment we're using a mostly unauthenticated API client when talking to lichess. One minor optimisation we could do is use an authenticated client, which would give us better API rates.

We're not anywhere near the limit of API limits with our current usage, but that kind of thing has a nasty habit of sneaking up on you.

It would be great to be able to support chesscom in addition to lichess.

From an API perspective, chesscom is a bit more limited, however it's not unmanageable:

• There's no OAuth support, however one common technique is that as a challenge/response system, we give the user a token they should put in the Location field of their profile. Once they validate, we fetch the profile and verify the token is there. It requires a bit more manual work on the user's part, however it does prove account ownership.
• chesscom has an API that we can access to fetch ratings and such. It's by far not the sexiest of APIs to work with, but it will get the job done.

Questions:

• how do we handle people with both a lichess and a chesscom account? Do we average the ratings? Do we show the highest? Should we handle both accounts at all?
• How do we show the difference in ratings? Do we need to show the difference at all? We could have one role that says "Liro Lichess" or "Liro ChessCom", so that we don't need to duplicate all the roles again (this only works with the single-account-linked approach).

It would be great for Liro to be able to create the roles in an automated fashion. One proposal is to have a command like:

/setup 800 2400 100 rapid classical

Breakdown:

• 800: minimum rating, so this would be turned into U800
• 2400: maximum rating, this would become 2400+
• 100: increment between two ratings. This would mean that we would end up with 800-899, 900-999, 1000-1099, etc.
• rapid classical the formats for which the roles should be created.

This to take into account:

• existing roles that match the format should be removed prior to creating the new ones.
• I'm not sure messing with colour schemes is a good idea. Every Discord has their own colour scheme, and us coming in and forcing our own could mess things up. Maybe it would be better to have an option that when a role has its colour changed, we pick up on that modification and update the ratings in the other formats to match the colour?

The discord link to invite liro to your server which is in the readme redirects to the "You have successfully invited Liro to your sever" page even if you decline the permissions and click cancel.

it redirects to this page which shows the success animation