@AngelCMHxD

Well, that took way longer than expected.

The docs are way more polished now! All endpoints have example responses so you know exactly what each one will return, along with a small description. HTTP endpoints that trigger a WebSocket event for any user (like friend requests, challenges, match moves, etc), mention it on their descriptions.

I also added some headers to the PGN strings, as they were previously filled with “?“s.

This mostly took this long due to a LOT of issues with the account deletion process, but it works perfectly now. When you delete your account, your user is replaced in all the matches you’ve played to @deleted_user. This is to keep the match data available even after any user deletes it. After that, your account is deleted from the DB. Due to how the DB is configured with cascade deletes, that will delete all other rows that reference the user (friendships, friend requests, pending challenges, etc.) except for matches, as they no longer reference the user that is being deleted.

I’m am quite close to the ship, which I’m kinda nervous about. I want the project to be in the best state and as polished as possible, without any bugs (well, any known bugs lol). Which is mostly the reason this project as a whole has taken soo long :/

Below is a small video showing the docs with the example data. At the end is the delete account flow, which have lot’s of confirmations as it currently doesn’t send an email. I’m thinking it probably should send one lol

See you in the next (and probably last) devlog!

(I fixed my OBS settings, the video should look a bit better than the previous ones :P)

ELO system! let’s go!!

At the end, I did add an ELO system. Well, it’s not really ELO, it’s Glicko.

I used the glicko2-lite library, which is stateless unlike other glicko implementations I found. I wanted a stateless one because I’m saving the data on the DB anyways, so making it stateful would only make it use more resources (primarly RAM).

You start with a rating of 1500. After every match your rating will go up/down depending on whether you win or lose. How much you win or lose depends on how many matches you have played (the first one are worth a bit more to get you to the optimal points), and depending on the rating of your oponent.

If you win against someone with a bigger rating than yours, you’ll gain way more points than if you win agains someone around your rating or less.

I also added a settings page so you can change your name and username, along with a page to change your password.

Below is a small video showing how the ELO Glicko system works:

What remains is just to also add the name/username change for bots and improve the docs.

I also made a Stockfish bot which you can try to play against. (Keyword: try, because it’s probably almost impossible)

User page done!

You can now see all of the matches and friends of other people, along with a small list of stats.

I’m thinking about implementing the ELO system. While I previously said that I wouldn’t be able to moderate people artificially inflating it (by selfbotting), having it without a leaderboard wouldn’t really make it that enticing to abuse. And personally, if there isn’t a leaderboard, I don’t think moderating it would be that important, what would the user gain more than having a bigger number on their profile? Still thinking about it though

I’m not sure about adding custom profile pictures or really any other user generated content. It would be nice to have, but it also involves moderation in order to prevent anything inappropriate from being uploaded (i mean, we all know how the internet works :/)

Below is a small video showing the user page, along with the bot auto accepting any new friend requests :P

Well, the web client is done!!

I used react-chessboard and it’s a pretty good library. I didn’t add click-to-move pieces as it makes the logic a LOT more complex, so I didn’t want to do it for now

I also used the API package from before, so we can use the websocket connection and listen for any changes. I also added it onto the matches page so any updates on the boards are reflected in real-time (which would probably look amazing if you have multiple automated matches running lol), and any new matches are added to the list without needing to refresh the page. I also want to add it onto the friends page, so it also updates in real-time

I had to change the icons on the discord bot as I realized they were Chess.com’s icons, and they aren’t free to use, so I removed them and replaced them with a pack named Caliente, which look amazing. It’s the same one I use on the web client

I think I should add a popup once the match is over as the current result feels quite plain. I also gotta add another page where you can spectate the match of other people, as the current one has too many logic already I prefer to duplicate it and remove the need of handling input and what not.

I also haven’t added a profiles page yet, so that’s still on the TODO list hahah

Below is a small video of me playing a match against a bot.

Two disclaimers:

• I used AI to fix some issues I had with the CSS on the page, though it didn’t change anything other than fix some class names, and the whole logic was made by me.
• I played horribly against the bot, as the difficulty is set quite low lol
• Additional disclaimer: Ignore the -55s duration on one of the matches, it was an old bug but I’ve gotten lazy and haven’t fixed the match on the DB yet .-.

The TUI is 100% done! (I think…)

There is no longer any mock data and it works with the actual API. You can send and receive challenges and friend requests, and you can see/play your running matches.

I think that, for the account management, I’ll remove email signups and only allow social OAuth2 (currently Google and Discord). As with email/password signups I need to handle email verification and password reset, and while Resend (what I use right now) is REALLY good and it’s free tier is great (3000 mails a month, 100 daily), if someone tries to spam the endpoints, it’s gonna eat up the limit. Though I might just put a rate limiter in place, and with Cloudflare Turnstile I already combat at least some botting, still thinking about it…

I’ll probably start with the web client for now, which might be the last thing to do

Below is a little video showing the TUI in action, while playing a match: (I took quite a bit of time thinking about the move I should make till I remembered I was just recording a test video lol)

And… This devlog is just to show the web dashboard, which I have forgotten to do a devlog for it all this time, which is why the logged time is so low lol

I used the Next.js framework to build the web dashboard (well, the whole dashboard + welcome page and just the whole web thing). I also used the shadcn/ui components library, as I’m not that good making frontend stuff, so that helped a lot. The dashboard layout is actually a template you can find on the shadcn site, I love the huge amount of things they have

I didn’t know what else to put as a welcome to the dashboard, so I left a little welcome message as seen at the beginning of the video

And I also forgot to show (mostly because there wasn’t any) the notifications button, where you can find any incoming challenges and friend requests.

The whole bot creation process works, at the end it gives you a token that you can use as if it were a user auth token, but you have all the scopes by default, so you can do anything you want with the account

What remains to do on this web part is to be able to see the profile of other users, along with their recent matches. And also a web client so you can play without downloading the TUI client or needing to use the discord bot

Edit: I realized right after posting this devlog: 100 hours! This has taken me more time than what I expected and gone quite big at this point hahah

Welp, the bots are done, and now I’ve tested the Discord integration.

I made the bots using the js-chess-engine package. Why that instead of something like stockfish? it simply was way easier to do as it’s a full js/ts engine lol

Though, that doesn’t mean that the stockfish engine wouldn’t be posible to integrate! as anyone can create bots, that also means that anyone could create a stockfish bot if they wanted to.

In case you don’t know what Stockfish is: It’s a really powerful and popular chess engine written in C++. Also, while writing this devlog, I found this package, which could be used to make a stockfish bot really easily. Though the ELO of the stockfish bot is really high, so I don’t really regret choosing js-chess-engine as a simpler engine means people can at least win against it lol

Here is a small video showing a match running on the discord bot. There are some small coordinates on the image so writing the SAN/LAN notation is easier, though it’s quire hard to see them on the video due to compression.

While it has support for everything (friend requests, send challenges, accept challenges, etc), I kinda forgot to record the rest :P

Well, making the TUI has gone quite well.

While I initially thought that Vue seemed weird for doing TUIs, it’s actually not that bad. No wonder Ink is so popular. (Though I’m liking Vue more than I like React, and Ink felt kinda clunky at times when I first tried it)

If you want to do TUIs with TypeScript/JavaScript, I’d recommend you give Vue TermUI a try. It also supports the Vue Router, so it’s easy to make a lot of pages and then navigate through them.

The data show in the video is just mock data. So it still doesn’t use the actual API, though progress have gone quite well without many hiccups.

The send friend request button, and the accept/reject challenge buttons do use the actual API, but they just throw an error because it tries to accept/reject a challenge that doesn’t actually exist, as it’s just mock data.

The app doesn’t crash on error though, it displays the error message right below the button, that way the user can see what went wrong without having the whole app crash or any other unexpected behavior.

What remains now is making some bots, that way I can make the whole “Playing a game” page, as having mock data for the WHOLE game state is not very… easy? I mean, I’ll have to do some bots anyway, so why not do them now instead of creating some weird mock functions hahah

I also think that the icons on the authorization page feel weird. I dont know if maybe they are too big or if I should just change them to other ones. I also have to change the card after approval or denial instead of just showing the toast at the bottom, as it doesnt give feedback to the user

Below is a small video of the TUI in action: (Disclaimer: Some AI was used, primarily to create the mock data so I could focus on the TUI itself)

Welp, designing how to do the TUI was kinda… complex.

I mostly know JS/TS, so I wanted to use that. And that made everything way more complex, as there aren’t so many options as you might have with something like how good Bubble Tea is on Go.

So these were the options I considered:

• Ink: Which didn’t have mouse support and uses React, which I’ve felt kinda clunky while doing the webpage, so I wanted try something else.
• Rezi: Which, at first, was AMAZING. But it had some bugs where focus didn’t work at all and I couldn’t interact with the TUI, or just started getting weird.
• OpenTUI: tbf, I didn’t test it out that much, couldn’t really understand it’s TS bindings

So what I ended up going with? Something not listed above: I ended up going with Vue TermUI (for now). Why? Well, I’ve wanted to try out Vue for some time now, and it uses OpenTUI under the hood, so it’s backend is probably pretty stable, or so I think, i don’t really know.

It does handles mouse input and focus management, making it quite easy to use.

Will I stay with Vue TermUI? I don’t really know yet. I’m just beginning to try it out, and I’m curious to see how it ends up. Especially because Vue for TUI sounds pretty weird lol

I actually really liked Rezi and you should check it out, as the issues I had were probably because I was doing something wrong hahah

Welp, I’ve been working for quite a while and this is quite a long devlog. If this seems interesting to you, leave a comment with suggestions! Maybe I could do some of them depending on their difficulty

I now have a pretty good API structure. It has normal HTTP endpoints and also a subscription system using WebSockets so you can get event-based messages, all of it working already. I also did a JS/TS package so it’s easier to implement it on your proyects. (Still not published to npm)

I currently have the following systems working: Account, Friends, Challenges, Matches, Bot management and Device auth (the thing where the app can show you an 8 character code to login). I also did a scopes system, that way you can know exactly what data the app will have access to and what actions it’d be able to do on your behalf

I made the backend using Elysia, while the whole storage is a PostgreSQL database that I interface with using Drizzle. The doc pages were done using Fumadocs, I love the way they look :D

A secondary DB, using Redis (or Redis-compatible DB) is also optional, quite useful as some thing like board movements might be done by players quite fast on low timers (like 1 min) and should be replied to as fast as possible to prevent the DB write speeds and reply time from counting against a player’s timer or affecting the match playability, though I still haven’t implemented timers lol

If the secondary Redis DB isn’t setup, then that data will be stored on RAM in order to keep it fast. Things like match status is kept there until the match ends, that means if the API server restarts, the matches that are currently being played are restarted too. I thought this isn’t as bad of a tradeoff in order to have a fast API reply, especially because you can solve it by setting up the Redis DB, and then you can restart the API server without worry, as the data is stored on the Redis server.

While the whole API is done, the account dashboard still requires some work to do, and I’m planning to do some integrations to make it easy to test, like a Discord bot (which is already done), a TUI, or maybe a web interface, though frontend interactivity isn’t something I’m really good at, and still haven’t gotten used to doing things “the React way” :P

I also added some bot management endpoints. That way someone can create a bot account under their user and be able to create any “bot opponent” to play against, something that I also want to do so anyone trying out the API or implementations can test it without requiring another available opponent

Don’t know if I should make an ELO/Leaderboard system, as those could be easily cheated and can’t really moderate them, and doing skill based match making wouldn’t work with a small user base.

This is Chess Now! An open-source (soon!) API to control chess games. The idea is for anyone to be able to create and integrate their apps and be able to control the games from there. This also means that you could be playing on App1 while your opponent can be playing on App2, as the server-side is shared between them.

I’ve added the whole auth flow and database integration. Better Auth really helped a lot in this regard, the docs were awesome.

I used some templates for the hero and login/signup flow as I don’t have almost any experience with frontend development (and a side-goal for me is to not use AI for codegen while making this project), though I’ve been learning a LOT about frontend doing this.

I’ll begin planning the whole API structure, I still don’t know where to begin hahah