|
901
|
Kern by @AntKru | Stardance
|
AntKru
|
3
|
153.98
|
2739
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-20T16:46:53Z", "hours": 65.0, "multiplier": 19.56, "payout": 1269, "blessing": "neutral", "text": "I have released the next version of my own kernel! The biggest feature I added is multitasking. While it doesn’t look that special, it was actually very difficult to make my kernel switch between different tasks! Here are some notes on how to try the project: If you don’t want/can’t run it, you can look at the video in the readme. If you want to run it on macOS with UTM, you have to force a PS/2 controller: https://docs.getutm.app/settings-qemu/qemu/#force-ps2-controller", "repo": "https://gitlab.com/AntKru/kern", "demo": "https://gitlab.com/AntKru/kern/-/releases/"}, {"ship_num": 2, "ts": "2026-07-24T06:30:43Z", "hours": 48.0, "multiplier": 19.83, "payout": 961, "blessing": "neutral", "text": "I added a CLI the kernel, which was possible, because I finally have a keyboard driver! It only took so long, because it was actually difficult to write it: I thought I have to program the PIC, but it was already disabled so I had to learn the more complicated APIC. There is a demo video in the README if you don’t want to run the kernel. If you want to run it on macOS with UTM, you have to force a PS/2 controller: https://docs.getutm.app/settings-qemu/qemu/#force-ps2-controller", "repo": "https://gitlab.com/AntKru/kern", "demo": "https://gitlab.com/AntKru/kern/-/releases/"}, {"ship_num": 3, "ts": "2026-06-20T14:34:14Z", "hours": 30.0, "multiplier": 17.21, "payout": 509, "blessing": "neutral", "text": "I made an x86_64 kernel using the limine boot protocol. I don’t know what the most difficult thing was, as even most basic things are very complicated for me as a beginner in osdev. I still have to learn much and the kernel will be improved, but I thing it kind of works now. I have a video demo in the readme, if you don’t have qemu . When building, remember to clone the submodules ( git submodule init && git submodule update ). You need xorriso to build the ISO. Sorry for mixing meson and make , but in the README is a guide. Please use clang, gcc is very complicated.", "repo": "https://gitlab.com/AntKru/kern", "demo": "https://gitlab.com/AntKru/kern/-/releases/"}]...
|
[{"post_id": 79283, "ts": "202 [{"post_id": 79283, "ts": "2026-10-13T09:56:47Z", "hours": 4.6628, "text": "Memory management problems… It seems like there was a critical bug sleeping inside my memory manager. It appeared since I started using the PMM in my AHCI driver, but I think the problem is in the virtual memory manager. For this reason I am working currently on the memory manager instead of the AHCI driver. Roadmap As soon as I fix the MM, I will continue on the AHCI driver. It probably won’t be finished until the end of stardance."}, {"post_id": 76791, "ts": "2026-10-04T16:08:54Z", "hours": 2.6242, "text": "AHCI! (SATA) I am jumping a little bit fast form PCI to AHCI, but I think the PCI driver is as good as I need it right now, and if I learn that it isn’t, I will fix it. Anyway, I am starting to work on AHCI! This is really cool, as this allows me to communicate to storage devices! At the moment the kernel just lists connected devices, but that’s just the beginning! Roadmap The AHCI driver is in a very early stage, and it will take me a lot of time to finish, as AHCI is relatively complicated and the documentation isn’t written for beginners like me ;-)"}, {"post_id": 74920, "ts": "2026-09-28T16:27:51Z", "hours": 3.6928, "text": "PCI! I am starting to write a PCI driver, which opens a new world to me! As you can see, the kernel is already able to print some information on boot about connected PCI devices. I also added a function that can search for a specific PCI device by it’s class, which will help me to implement drivers for specific PCI devices. Roadmap The real reason I am implementing PCI is that I need it to find the AHCI controller. The AHCI controller can be used to access connected storage devices, which is my long-term goal."}, {"post_id": 71311, "ts": "2026-09-20T16:38:40Z", "hours": 1.3486, "text": "Release 0.3.0 I finished the release, including the new borders command! The visible bugs that I found are also fixed, please report them if you find some! Roadmap The kernel isn’t finished yet, I will continue to improve it and see how far I will get."}, {"post_id": 70750, "ts": "2026-09-19T18:15:14Z", "hours": 4.075, "text": "Final improvements before the next release Status bar I moved the status bar from the bottom to the top and removed the borders, in my opinion it looks better this way. Framebuffer borders I am already working on a new command which will make it possible to see the borders of the framebuffer in QEMU. This will be useful for debugging while keeping the UI simple. Bugs There are still some obvious bugs: My printf() implementation seems to break with invalid format strings and I have a bug in my memory manager which prevents me from merging the command showing the screen borders into main. Roadmap I will try to fix the bugs, but the features are now complete. I want to release the new version tomorrow."}, {"post_id": 68765, "ts": "2026-09-15T18:23:31Z", "hours": 7.8061, "text": "printf compatability I improved the printf() compatability, so that I can pad numbers with or 0 . This is very useful, for example I now can use it to display time and date properly. Roadmap I don’t know yet what’s the next thing to do, maybe I will ship soon."}, {"post_id": 63678, "ts": "2026-09-07T16:41:58Z", "hours": 4.1103, "text": "Status bar! I added a status bar which show the current time. It is very basic, but makes the OS look way more friendlier in my opinion. Sorry for the weird messages in the main window, I am currently debugging my printf implementation. Roadmap I still have a problem with printing dates: The year 2006 would be printed as 206 , because the RTC has seperate registers for year and century, so if century is 20 and year is 6 it prints 206."}, {"post_id": 58325, "ts": "2026-08-30T18:21:09Z", "hours": 2.6081, "text": "“Windows” I am making it possible to split the framebuffer into multiple views. This should make it more easy to have a more advanced UI than a CLI already inside the kernel. Hopefully there will be user processes at some point, but I want to have a nice looking OS before that. Roadmap I still have to fix some things (as visible on the screenshot). After that, I can try to make use of it and add a status bar or a separate command window."}, {"post_id": 55470, "ts": "2026-08-27T10:27:14Z", "hours": 4.5317, "text": "RTC The kernel can now read the current time from the Computer’s RTC! At the moment, you can’t select the time zone, so the time is probably in UTC, depending on how the computer is configured. Roadmap I am planning to improve the use experience, for example by using multiple “windows”, to maybe even have a status bar."}, {"post_id": 52423, "ts": "2026-08-22T15:29:50Z", "hours": 4.2389, "text": "GCC support I added GCC support, which should (hopefully) make debugging easier for me. I can’t show it really on the screenshot, trust me, it is compiled with gcc! Roadmap I have still bugs in my multitasking system. Currently I get a page fault when compiling with optimization > -O2 with clang, the next step is to test it with GCC."}, {"post_id": 47914, "ts": "2026-08-16T05:50:20Z", "hours": 2.6892, "text": "Mutexes I implemented a simple mutex (which isn’t perfect yet, but it works). As visible on the screenshot, I used it to make it impossible for the test tasks to print at the same time. One problem with it is that it currently runs hlt after releasing a mutex so that a different task has a chance to acquire it, which doesn’t seem like the best solution to me. Roadmap I am making the terminal position atomic, so that I don’t need mutexes for output, which I can not use in interrupt handlers"}, {"post_id": 46418, "ts": "2026-08-13T16:41:17Z", "hours": 5.8897, "text": "Multitasking! I fixed the last bug (that I could find) and multitasking works now! On the screenshot you can see two tasks trying to print the numbers 0-19 at the same time. The CLI even waits until the tasks are finished! Road map The output is still a little bit broken, so I want to implement output buffering and mutexes, so that multiple threads can’t print at the same time."}, {"post_id": 44770, "ts": "2026-08-10T19:26:17Z", "hours": 6.2656, "text": "Multitasking… I am still working on multitasking, but I am stuck currently. I am trying to modify the stack frame so that asm_switch_task is called after iretq , but it doesn’t work. As you can see on the screenshot, I get a page fault as soon as it tries to switch tasks (in the debugging process I had it switch 2-3 times before it crashes, which is not really better) Road map My highest priority is to get task switching to work consistently. After that, I will see what I can polish."}, {"post_id": 43900, "ts": "2026-08-09T10:50:40Z", "hours": 2.4128, "text": "SSE register state switching! The kernel will now switch the SSE register state lazily, but I still have two problems: The Part for the registers in the TCB must be 16 byte aligned, which it currently not guaranteed The interrupt handlers are not allowed to use SSE instructions, but I have no way of verifying this Road map I think it is time to write a version of malloc() which can guarantee a specified alignment. After that, I can try to actually switch tasks automatically with a simple scheduler! I will probably use the PIT interrupt to switch to the next task in a list."}, {"post_id": 42570, "ts": "2026-08-07T11:56:52Z", "hours": 4.5606, "text": "It probably doesn’t sound special, but it is as important as everything else: SSE support SSE is an extension of the CPU which has 16 128-bit registers, but is rarely used. This means, that saving all of these registers every time a task switch occurs would cost some performance. For this reason, the CPU has a bit that can be set to indicate that a task switch occurred. In most cases, nothing happens and the registers are kept in their original state. But if a task needs to use SSE instructions, the CPU generates an interrupt, which manually saves the SSE registers. This is what I am working on currently. Custom ISR wrapper All interrupt handlers use now my custom wrappers, which made possible that I can work on SSE support."}, {"post_id": 40940, "ts": "2026-08-04T19:52:16Z", "hours": 5.0347, "text": "Array optimization (Screenshot 1) I now actually optimized the dynamic array type, which means that it allocates memory in bigger chunks instead of every time an element is added / removed. In the process I added some debug logging, so typing is now very difficult if you don’t know how it works with log level LOG_DEBUG . Custom ISR wrapper (Screenshot 2) I finally decided to implement my own wrapper for ISRs instead of relying on __attribute__((interrupt)) . This should allow me to use floating point math with the FPU in the future. Also, I can now read more registers on interrupt (screenshot). Road map I am currently working on making all ISRs compatible with my wrapper. Then I will continue trying to get multitasking to work."}, {"post_id": 38897, "ts": "2026-08-01T14:03:43Z", "hours": 6.4275, "text": "Multitasking (Screenshot 1) I decided to try to implement multitasking! The kernel can now switch tasks, but only one time. This is the first step in direction of real multitasking, but I still have much to do. It is interesting to see, How I realize how bad my implementations I did earlier are, because I don’t fully understand them. But now I can improve them! Dynamic arrays (Screenshot 2) I made a quick implementation of dynamic arrays for the keyboard driver, but as I realized that I need them to store a list of tasks, I decided to implement one optimized implementation I can use everywhere. I have implemented a very simple version and use it in the keyboard driver, but it isn’t optimized yet. In fact, it’s even worse than the one I had earlier in the keyboard driver, because every modification now requires a reallocation. Road map I am going to optimize dynamic arrays, and then continue with multitasking."}, {"post_id": 36558, "ts": "2026-07-28T19:08:32Z", "hours": 2.8569, "text": "PIT I quickly wrote a simple PIT (Programmable Interval Timer) driver, so that I have a basic sleep function. It isn’t really useful at the moment and not thread safe, but as it was very simple I thought why not? APIC I realized that MADT I/O APIC overrides also override the flags of entries, so I am using these now unless it’s overridden by the user. Road map As I have now a simple keyboard driver, I want to work on something new. Some things I am considering: Multitasking Filesystems ELF loading PCI USB All of this topics are completely new to me, so I will pick the one that looks the most simple and probably fail anyway."}, {"post_id": 33535, "ts": "2026-07-23T15:58:35Z", "hours": 2.3419, "text": "I am shipping soon! Some little improvements in messages I improved some messages, so that the kernel looks more polished to new users. v0.2.0 I released a new version, which is what I am shipping soon (if nothing goes wrong). It includes an interactive CLI, which was made possible with the new keyboard driver. I improved the scrolling performance a lot, which I personally really enjoy! Finally, I fixed a bug when printing numbers, so the printed memory map now has (mostly) correct addresses."}, {"post_id": 32511, "ts": "2026-07-21T18:56:41Z", "hours": 3.1614, "text": "The kernel is now interactive! Demo CLI I added a demo CLI (you can see it on the screenshot) where you can exit properly, run tests or view the old demo! Keyboard driver I had to fix some bugs with the keyboard driver, but now I think it works okay enough that the CLI is stable (previously, it kept parts from the old buffer when reading it again) Road map I want to add more features to the CLI, such as setting the log level. As you can see on the screenshot, the debug output disturbs the CLI."}, {"post_id": 31826, "ts": "2026-07-20T14:47:46Z", "hours": 5.0328, "text": "I FINALLY get interrupts from the keyboard! PS/2 Keyboard driver The problem was, that I mistook the IRQ number for the interrupt vector when calling my own function! Now I can start expanding my keyboard driver. Currently, it already prints the pressed keys to the screen, as you can see on the screen shot. Performance improvements when scrolling After I finished the interrupt stuff, I can focus on improving the TTY in other areas, like the performance. I am using now memset() and memcpy() functions when scrolling the frame buffer, which itself is not an improvement: I optimized the two functions to use copy 8-byte blocks ad uint64_t instead of each byte individually, which made a significant difference. Scrolling with KVM acceleration is now almost instant on my PC, and without it is as fast as it was before with acceleration. Road map I want to improve the TTY with things like buffering, which should improve the performance even more. When I have a solid TTY, I can rework the demo and ship again."}, {"post_id": 30816, "ts": "2026-07-18T19:00:05Z", "hours": 6.3653, "text": "I am still far away from getting interrupts from the keyboard, but I am still learning much and making progress on other parts of the kernel! PMM I added support for mapping pages manually, which means that I can program now the APICs! While debugging this, I also improved my Page Fault handler, which you can see on the screenshot. APIC driver The APIC driver should now be able to configure IRQs on the I/O APIC to get delivered to the local APIC, but I can’t test it as I still don’t know why I can’t get interrupts from the keyboard :-( Road Map I am still working on getting interrupts from the keyboard, which is my main goal before the next ship. I currently suspect that my PS/2 driver is broken."}, {"post_id": 29069, "ts": "2026-07-15T18:32:01Z", "hours": 7.5669, "text": "I prefer this devlog format, so I will stick to it. I/O APIC As I explained earlier, I need to configure the APIC to get interrupts. I think I only need the I/O APIC and not the local APIC, if I understand the limine documentation correctly. But when trying to access it’s registers, I got a page fault. It seems like I need to manually map the registers to virtual memory, which brings me to… Physical Memory Manager I need to do what I already feared when starting to write the PMM, manually editing page tables. I am working on a function which will map pages (Including the I/O APIC registers) to virtual addresses. For this, I need to walk the complete paging structure: PML4 (from cr3) -> PDPT -> PD -> PT I can already parse it until I have the PT’s address, but when accessing the PT I get a page fault, as you can see on the screenshot. Road map I just wanted to post this update so that the next devlog is not too long. I will continue to work on the PMM, until I can access the I/O APIC’s registers."}, {"post_id": 24628, "ts": "2026-07-08T10:52:11Z", "hours": 8.3475, "text": "I did not post for some time, so this devlog will be relatively long. PS/2 driver (Screenshot 1) I wanted to get the PIC to work, but as I had no idea why it didn’t work I thought that the PS/2 Controller might not be in a functioning state. So, I wrote a PS/2 driver which initializes the Controller, and also detects connected devices! PIC -> APIC After that, I finally found out that limine already sets up the APIC, which means that the PIC is no longer functional. So I decided that my next big goal is to learn how ACPI and APIC work… ACPI (Screenshot 2) As you can see on the screenshots, I started working on an ACPI driver, which is already able to find tables like the MADT, which I need to find the APICs UEFI This does not have anything to do with the progress of my project, but I learned how to use UEFI in QEMU, so that I can debug my ACPI driver better. Road map I will have to learn now how APICs work, so that I can get interrupts from the keyboard. Then, I can improve the keyboard driver, which should make the kernel way more fun to use!"}, {"post_id": 20746, "ts": "2026-07-02T13:20:11Z", "hours": 6.0672, "text": "I have finished implementing the memory manager! free() will now call pmm_free() to free unused pages. At the moment it does not make any difference, but if I want to extend the PMM it will have saved me the work. Also, I split the demo from the main function so that it is more maintainable. Log messages with the log level DEBUG will now only appear in debug builds. This made the output much more readable, as you can see in the screenshots."}, {"post_id": 19208, "ts": "2026-06-30T14:00:38Z", "hours": 9.6128, "text": "I have added a simple memory manager to my kernel! It was only possible with the help from kmos , a project I found while voting. I didn’t know how to start writing a physical memory manager, but in that kernel I found that I have to use the limine HHDM request to have simple access to physical addresses. Then I could implement the rest completely myself. The last thing left to do until I’m satisfied with my memory manager, is to free pages in the PMM after using free()"}, {"post_id": 12539, "ts": "2026-06-20T14:12:50Z", "hours": 0.8414, "text": "Now I am actually shipping! I had a bug that occured only when compiling with optimization level 2 or higher (which I used in the release CI). As I am working now on a Debian machine, I made it also compile on Debian stable by not requiring a new objcopy version. On the screenshot you can see the bug."}, {"post_id": 11482, "ts": "2026-06-18T19:17:02Z", "hours": 4.0292, "text": "I will ship the kernel now for the first time! I added a libk (like a libc but for the kernel) and implemented some cool functions like printf(), which I could use for cool error messages with hex numbers like the one on the screenshot."}, {"post_id": 9395, "ts": "2026-06-15T18:55:28Z", "hours": 2.4939, "text": "I sadly don’t have much to say, because I did make almost no progress. I am trying to use the PIC to get interrupts from the keyboard, but it doesn’t work for some reason. Maybe I will try to use APIC instead, but it’s more complicated."}, {"post_id": 8627, "ts": "2026-06-14T10:44:21Z", "hours": 2.2619, "text": "I finally figured out how I can integrate the external library! Now I can skip instructions when an interrupt is executed and continue execution"}, {"post_id": 7621, "ts": "2026-06-12T19:00:11Z", "hours": 1.0647, "text": "I just wanted to implement an interrupt handler specific to divide error, but it turned out to be way more difficult than I thought! To continue execution after the interrupt, I have to manually increment the instruction pointer manually. But to know by which amount, I need to now the size of the whole instruction. To find it I wanted to use a library called Zydis, but I could not get it to compile, because clang generates calls to memset() and memcpy() . As I can not link with the standard library, I will have to find a solution tomorrow."}, {"post_id": 5837, "ts": "2026-06-09T19:37:29Z", "hours": 3.1153, "text": "I added a demo to show the features of my kernel. The kernel is almost ready for the first ship!"}, {"post_id": 4373, "ts": "2026-06-07T18:00:51Z", "hours": 3.2469, "text": "After giving up on the memory manager, I added logging and very basic interrupt handling. I will ship the project when I have a demo of all the features and published ISOs."}, {"post_id": 3530, "ts": "2026-06-06T14:47:32Z", "hours": 2.2575, "text": "As I have now a very basic way to interact with the kernel, I will try to move on to more complex topics. At the moment I try to understand how memory management exactly works (specifically, how to write a physical memory manager), but it’s difficult to find information about it. Until now, I have requested a memory map from limine and can display it in a table."}, {"post_id": 3364, "ts": "2026-06-06T07:57:08Z", "hours": 1.7286, "text": "I implemented enter key press detection before doing anything else, so that I can interact somehow with the kernel. I did it with IO Ports instead of interrupts for now (because I don’t know how to set up interrupts), which means it only works with PS/2 Keyboards. Luckily, qemu shows the keyboard as a PS/2 Keyboard."}, {"post_id": 2308, "ts": "2026-06-04T18:38:28Z", "hours": 2.5331, "text": "I have added a normal font which makes things way simpler. I also improved the general tty: scrolling, new lines and tabs work now!"}, {"post_id": 1458, "ts": "2026-06-03T14:42:11Z", "hours": 1.7617, "text": "I spend so much time to fix a stupid bug (taking the address of a pointer instead of the address stored in the pointer), but know I can display characters from my ugly psf2 font! At least I learned more about gdb."}, {"post_id": 957, "ts": "2026-06-02T18:43:29Z", "hours": 3.0825, "text": "I implemented a set_pixel function, so that I can set specific pixels on the framebuffer. The next step will probably be to display text, maybe with a font made with psfedit, my project for flavortown. I also published my code on GitLab, which means I will try to build ISOs with gitlab CI at some point."}, {"post_id": 294, "ts": "2026-06-01T15:23:58Z", "hours": 1.1658, "text": "I have started to work on my kernel! I just set up my project structure but it does not work as you can see on the screenshot. I will look at it tomorrow. I have already tried to write a kernel earlier this week, but it was an i686 kernel with multiboot 2. Also, I had to copy much code from the limine template, but I will go beyond that when the kernel runs. This means, that I have a weird mix of makefile and meson, as the example uses make but I prefer meson. As I do not want to set up long mode myself, my new kernel uses limine instead of multiboot. My current plan is to get it to run and then publish the source code. Later, I might try to remove make completely and only rely on meson for building the iso."}]...
|
Title: Kern by @AntKru | Stardance
Devlogs:
I hav Title: Kern by @AntKru | Stardance
Devlogs:
I have started to work on my kernel! I just set up my project structure but it does not work as you can see on the screenshot. I will look at it tomorrow. I have already tried to write a kernel earlier this week, but it was an i686 kernel with multiboot 2. Also, I had to copy much code from the limine template, but I will go beyond that when the kernel runs. This means, that I have a weird mix of makefile and meson, as the example uses make but I prefer meson. As I do not want to set up long mode myself, my new kernel uses limine instead of multiboot. My current plan is to get it to run and then publish the source code. Later, I might try to remove make completely and only rely on meson for building the iso.
I implemented a set_pixel function, so that I can set specific pixels on the framebuffer. The next step will probably be to display text, maybe with a font made with psfedit, my project for flavortown. I also published my code on GitLab, which means I will try to build ISOs with gitlab CI at some point.
I spend so much time to fix a stupid bug (taking the address of a pointer instead of the address stored in the pointer), but know I can display characters from my ugly psf2 font! At least I learned more about gdb.
I have added a normal font which makes things way simpler. I also improved the general tty: scrolling, new lines and tabs work now!
I implemented enter key press detection before doing anything else, so that I can interact somehow with the kernel. I did it with IO Ports instead of interrupts for now (because I don’t know how to set up interrupts), which means it only works with PS/2 Keyboards. Luckily, qemu shows the keyboard as a PS/2 Keyboard.
As I have now a very basic way to interact with the kernel, I will try to move on to more complex topics. At the moment I try to understand how memory management exactly works (specifically, how to write a physical memory manager), but it’s difficult to find information about it. Until now, I have requested a memory map from limine and can display it in a table.
After giving up on the memory manager, I added logging and very basic interrupt handling. I will ship the project when I have a demo of all the features and published ISOs.
I added a demo to show the features of my kernel. The kernel is almost ready for the first ship!
I just wanted to implement an interrupt handler specific to divide error, but it turned out to be way more difficult than I thought! To continue execution after the interrupt, I have to manually increment the instruction pointer manually. But to know by which amount, I need to now the size of the whole instruction. To find it I wanted to use a library called Zydis, but I could not get it to compile, because clang generates calls to memset() and memcpy() . As I can not link with the standard library, I will have to find a solution tomorrow.
I finally figured out how I can integrate the external library! Now I can skip instructions when an interrupt is executed and continue execution
I sadly don’t have much to say, because I did make almost no progress. I am trying to use the PIC to get interrupts from the keyboard, but it doesn’t work for some reason. Maybe I will try to use APIC instead, but it’s more complicated.
I will ship the kernel now for the first time! I added a libk (like a libc but for the kernel) and implemented some cool functions like printf(), which I could use for cool error messages with hex numbers like the one on the screenshot.
Now I am actually shipping! I had a bug that occured only when compiling with optimization level 2 or higher (which I used in the release CI). As I am working now on a Debian machine, I made it also compile on Debian stable by not requiring a new objcopy version. On the screenshot you can see the bug.
I have added a simple memory manager to my kernel! It was only possible with the help from kmos , a project I found while voting. I didn’t know how to start writing a physical memory manager, but in that kernel I found that I have to use the limine HHDM request to have simple access to physical addresses. Then I could implement the rest completely myself. The last thing left to do until I’m satisfied with my memory manager, is to free pages in the PMM after using free()
I have finished implementing the memory manager! free() will now call pmm_free() to free unused pages. At the moment it does not make any difference, but if I want to extend the PMM it will have saved me the work. Also, I split the demo from the main function so that it is more maintainable. Log messages with the log level DEBUG will now only appear in debug builds. This made the output much more readable, as you can see in the screenshots.
I did not post for some time, so this devlog will be relatively long. PS/2 driver (Screenshot 1) I wanted to get the PIC to work, but as I had no idea why it didn’t work I thought that the PS/2 Controller might not be in a functioning state. So, I wrote a PS/2 driver which initializes the Controller, and also detects connected devices! PIC -> APIC After that, I finally found out that limine already sets up the APIC, which means that the PIC is no longer functional. So I decided that my next big goal is to learn how ACPI and APIC work… ACPI (Screenshot 2) As you can see on the screenshots, I started working on an ACPI driver, which is already able to find tables like the MADT, which I need to find the APICs UEFI This does not have anything to do with the progress of my project, but I learned how to use UEFI in QEMU, so that I can debug my ACPI driver better. Road map I will have to learn now how APICs work, so that I can get interrupts from the keyboard. Then, I can improve the keyboard driver, which should make the kernel way more fun to use!
I prefer this devlog format, so I will stick to it. I/O APIC As I explained earlier, I need to configure the APIC to get interrupts. I think I only need the I/O APIC and not the local APIC, if I understand the limine documentation correctly. But when trying to access it’s registers, I got a page fault. It seems like I need to manually map the registers to virtual memory, which brings me to… Physical Memory Manager I need to do what I already feared when starting to write the PMM, manually editing page tables. I am working on a function which will map pages (Including the I/O APIC registers) to virtual addresses. For this, I need to walk the complete paging structure: PML4 (from cr3) -> PDPT -> PD -> PT I can already parse it until I have the PT’s address, but when accessing the PT I get a page fault, as you can see on the screenshot. Road map I just wanted to post this update so that the next devlog is not too long. I will continue to work on the PMM, until I can access the I/O APIC’s registers.
I am still far away from getting interrupts from the keyboard, but I am still learning much and making progress on other parts of the kernel! PMM I added support for mapping pages manually, which means that I can program now the APICs! While debugging this, I also improved my Page Fault handler, which you can see on the screenshot. APIC driver The APIC driver should now be able to configure IRQs on the I/O APIC to get delivered to the local APIC, but I can’t test it as I still don’t know why I can’t get interrupts from the keyboard :-( Road Map I am still working on getting interrupts from the keyboard, which is my main goal before the next ship. I currently suspect that my PS/2 driver is broken.
I FINALLY get interrupts from the keyboard! PS/2 Keyboard driver The problem was, that I mistook the IRQ number for the interrupt vector when calling my own function! Now I can start expanding my keyboard driver. Currently, it already prints the pressed keys to the screen, as you can see on the screen shot. Performance improvements when scrolling After I finished the interrupt stuff, I can focus on improving the TTY in other areas, like the performance. I am using now memset() and memcpy() functions when scrolling the frame buffer, which itself is not an improvement: I optimized the two functions to use copy 8-byte blocks ad uint64_t instead of each byte individually, which made a significant difference. Scrolling with KVM acceleration is now almost instant on my PC, and without it is as fast as it was before with acceleration. Road map I want to improve the TTY with things like buffering, which should improve the performance even more. When I have a solid TTY, I can rework the demo and ship again.
The kernel is now interactive! Demo CLI I added a demo CLI (you can see it on the screenshot) where you can exit properly, run tests or view the old demo! Keyboard driver I had to fix some bugs with the keyboard driver, but now I think it works okay enough that the CLI is stable (previously, it kept parts from the old buffer when reading it again) Road map I want to add more features to the CLI, such as setting the log level. As you can see on the screenshot, the debug output disturbs the CLI.
I am shipping soon! Some little improvements in messages I improved some messages, so that the kernel looks more polished to new users. v0.2.0 I released a new version, which is what I am shipping soon (if nothing goes wrong). It includes an interactive CLI, which was made possible with the new keyboard driver. I improved the scrolling performance a lot, which I personally really enjoy! Finally, I fixed a bug when printing numbers, so the printed memory map now has (mostly) correct addresses.
PIT I quickly wrote a simple PIT (Programmable Interval Timer) driver, so that I have a basic sleep function. It isn’t really useful at the moment and not thread safe, but as it was very simple I thought why not? APIC I realized that MADT I/O APIC overrides also override the flags of entries, so I am using these now unless it’s overridden by the user. Road map As I have now a simple keyboard driver, I want to work on something new. Some things I am considering: Multitasking Filesystems ELF loading PCI USB All of this topics are completely new to me, so I will pick the one that looks the most simple and probably fail anyway.
Multitasking (Screenshot 1) I decided to try to implement multitasking! The kernel can now switch tasks, but only one time. This is the first step in direction of real multitasking, but I still have much to do. It is interesting to see, How I realize how bad my implementations I did earlier are, because I don’t fully understand them. But now I can improve them! Dynamic arrays (Screenshot 2) I made a quick implementation of dynamic arrays for the keyboard driver, but as I realized that I need them to store a list of tasks, I decided to implement one optimized implementation I can use everywhere. I have implemented a very simple version and use it in the keyboard driver, but it isn’t optimized yet. In fact, it’s even worse than the one I had earlier in the keyboard driver, because every modification now requires a reallocation. Road map I am going to optimize dynamic arrays, and then continue with multitasking.
Array optimization (Screenshot 1) I now actually optimized the dynamic array type, which means that it allocates memory in bigger chunks instead of every time an element is added / removed. In the process I added some debug logging, so typing is now very difficult if you don’t know how it works with log level LOG_DEBUG . Custom ISR wrapper (Screenshot 2) I finally decided to implement my own wrapper for ISRs instead of relying on __attribute__((interrupt)) . This should allow me to use floating point math with the FPU in the future. Also, I can now read more registers on interrupt (screenshot). Road map I am currently working on making all ISRs compatible with my wrapper. Then I will continue trying to get multitasking to work.
It probably doesn’t sound special, but it is as important as everything else: SSE support SSE is an extension of the CPU which has 16 128-bit registers, but is rarely used. This means, that saving all of these registers every time a task switch occurs would cost some performance. For this reason, the CPU has a bit that can be set to indicate that a task switch occurred. In most cases, nothing happens and the registers are kept in their original state. But if a task needs to use SSE instructions, the CPU generates an interrupt, which manually saves the SSE registers. This is what I am working on currently. Custom ISR wrapper All interrupt handlers use now my custom wrappers, which made possible that I can work on SSE support.
SSE register state switching! The kernel will now switch the SSE register state lazily, but I still have two problems: The Part for the registers in the TCB must be 16 byte aligned, which it currently not guaranteed The interrupt handlers are not allowed to use SSE instructions, but I have no way of verifying this Road map I think it is time to write a version of malloc() which can guarantee a specified alignment. After that, I can try to actually switch tasks automatically with a simple scheduler! I will probably use the PIT interrupt to switch to the next task in a list.
Multitasking… I am still working on multitasking, but I am stuck currently. I am trying to modify the stack frame so that asm_switch_task is called after iretq , but it doesn’t work. As you can see on the screenshot, I get a page fault as soon as it tries to switch tasks (in the debugging process I had it switch 2-3 times before it crashes, which is not really better) Road map My highest priority is to get task switching to work consistently. After that, I will see what I can polish.
Multitasking! I fixed the last bug (that I could find) and multitasking works now! On the screenshot you can see two tasks trying to print the numbers 0-19 at the same time. The CLI even waits until the tasks are finished! Road map The output is still a little bit broken, so I want to implement output buffering and mutexes, so that multiple threads can’t print at the same time.
Mutexes I implemented a simple mutex (which isn’t perfect yet, but it works). As visible on the screenshot, I used it to make it impossible for the test tasks to print at the same time. One problem with it is that it currently runs hlt after releasing a mutex so that a different task has a chance to acquire it, which doesn’t seem like the best solution to me. Roadmap I am making the terminal position atomic, so that I don’t need mutexes for output, which I can not use in interrupt handlers
GCC support I added GCC support, which should (hopefully) make debugging easier for me. I can’t show it really on the screenshot, trust me, it is compiled with gcc! Roadmap I have still bugs in my multitasking system. Currently I get a page fault when compiling with optimization > -O2 with clang, the next step is to test it with GCC.
RTC The kernel can now read the current time from the Computer’s RTC! At the moment, you can’t select the time zone, so the time is probably in UTC, depending on how the computer is configured. Roadmap I am planning to improve the use experience, for example by using multiple “windows”, to maybe even have a status bar.
“Windows” I am making it possible to split the framebuffer into multiple views. This should make it more easy to have a more advanced UI than a CLI already inside the kernel. Hopefully there will be user processes at some point, but I want to have a nice looking OS before that. Roadmap I still have to fix some things (as visible on the screenshot). After that, I can try to make use of it and add a status bar or a separate command window.
Status bar! I added a status bar which show the current time. It is very basic, but makes the OS look way more friendlier in my opinion. Sorry for the weird messages in the main window, I am currently debugging my printf implementation. Roadmap I still have a problem with printing dates: The year 2006 would be printed as 206 , because the RTC has seperate registers for year and century, so if century is 20 and year is 6 it prints 206.
printf compatability I improved the printf() compatability, so that I can pad numbers with or 0 . This is very useful, for example I now can use it to display time and date properly. Roadmap I don’t know yet what’s the next thing to do, maybe I will ship soon.
Final improvements before the next release Status bar I moved the status bar from the bottom to the top and removed the borders, in my opinion it looks better this way. Framebuffer borders I am already working on a new command which will make it possible to see the borders of the framebuffer in QEMU. This will be useful for debugging while keeping the UI simple. Bugs There are still some obvious bugs: My printf() implementation seems to break with invalid format strings and I have a bug in my memory manager which prevents me from merging the command showing the screen borders into main. Roadmap I will try to fix the bugs, but the features are now complete. I want to release the new version tomorrow.
Release 0.3.0 I finished the release, including the new borders command! The visible bugs that I found are also fixed, please report them if you find some! Roadmap The kernel isn’t finished yet, I will continue to improve it and see how far I will get.
PCI! I am starting to write a PCI driver, which opens a new world to me! As you can see, the kernel is already able to print some information on boot about connected PCI devices. I also added a function that can search for a specific PCI device by it’s class, which will help me to implement drivers for specific PCI devices. Roadmap The real reason I am implementing PCI is that I need it to find the AHCI controller. The AHCI controller can be used to access connected storage devices, which is my long-term goal.
AHCI! (SATA) I am jumping a little bit fast form PCI to AHCI, but I think the PCI driver is as good as I need it right now, and if I learn that it isn’t, I will fix it. Anyway, I am starting to work on AHCI! This is really cool, as this allows me to communicate to storage devices! At the moment the kernel just lists connected devices, but that’s just the beginning! Roadmap The AHCI driver is in a very early stage, and it will take me a lot of time to finish, as AHCI is relatively complicated and the documentation isn’t written for beginners like me ;-)
Memory management problems… It seems like there was a critical bug sleeping inside my memory manager. It appeared since I started using the PMM in my AHCI driver, but I think the problem is in the virtual memory manager. For this reason I am working currently on the memory manager instead of the AHCI driver. Roadmap As soon as I fix the MM, I will continue on the AHCI driver. It probably won’t be finished until the end of stardance.
Ships:
I made an x86_64 kernel using the limine boot protocol. I don’t know what the most difficult thing was, as even most basic things are very complicated for me as a beginner in osdev. I still have to learn much and the kernel will be improved, but I thing it kind of works now. I have a video demo in the readme, if you don’t have qemu . When building, remember to clone the submodules ( git submodule init && git submodule update ). You need xorriso to build the ISO. Sorry for mixing meson and make , but in the README is a guide. Please use clang, gcc is very complicated.
I added a CLI the kernel, which was possible, because I finally have a keyboard driver! It only took so long, because it was actually difficult to write it: I thought I have to program the PIC, but it was already disabled so I had to learn the more complicated APIC. There is a demo video in the README if you don’t want to run the kernel. If you want to run it on macOS with UTM, you have to force a PS/2 controller: https://docs.getutm.app/settings-qemu/qemu/#force-ps2-controller
I have released the next version of my own kernel! The biggest feature I added is multitasking. While it doesn’t look that special, it was actually very difficult to make my kernel switch between different tasks! Here are some notes on how to try the project: If you don’t want/can’t run it, you can look at the video in the readme. If you want to run it on macOS with UTM, you have to force a PS/2 controller: https://docs.getutm.app/settings-qemu/qemu/#force-ps2-controller...
|
1792842658.7836795
|
1792929058.7836795
|
|
902
|
A game themed website by @Aditya_ | Stardance
|
Aditya_
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: A game themed website by @Aditya_ | Stardan Title: A game themed website by @Aditya_ | Stardance...
|
1792788631.2511559
|
1793393431.2511559
|
|
903
|
CyberShield Academy by @Paul | Stardance
|
Paul
|
1
|
5.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-01T21:36:17Z", "hours": 5.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built a web-based cybersecurity training platform designed to help students and young professionals build real-world digital defence skills. The platform tackles the problem of inaccessible, overly theoretical cybersecurity education by combining structured course modules, hands-on hacking labs, timed live events, and a dual-portal system — all wrapped in a sleek, professional interface. It wasn’t really easy, to compile and make everything work perfectly, but with time and concentration, I was able, it’s also true that I am not completely done with the Project, but will keep on doing changes until the project is fully developed", "repo": "https://github.com/DevNdehPaul/CyberShield-Academy", "demo": "https://cybershield-academy.onrender.com/"}]...
|
[{"post_id": 443, "ts": "2026- [{"post_id": 443, "ts": "2026-06-01T21:13:08Z", "hours": 1.1417, "text": "I just finished coding the Student’s Training Courses & Labs Page, which contains the different courses the student can enroll and learn the skills from"}, {"post_id": 391, "ts": "2026-06-01T19:17:50Z", "hours": 1.4456, "text": "I just finish coding the student and admin dashboard, where they student can track its Progress in his different enrolled courses, and the admin can monitor the system thoroughly"}, {"post_id": 298, "ts": "2026-06-01T15:28:20Z", "hours": 2.0061, "text": "I just finished adding the contact us, about us and login/signup pages to the Project, now I am planning on working on the other pages, starting with the dashboard Page"}, {"post_id": 198, "ts": "2026-06-01T07:31:06Z", "hours": 0.7375, "text": "I am currently working on a website called CyberShield Academy, which will be able to help students and young professionals learn cybersecurity and digital forensics through interactive, hands-on modules."}]...
|
Title: CyberShield Academy by @Paul | Stardance
D Title: CyberShield Academy by @Paul | Stardance
Devlogs:
I am currently working on a website called CyberShield Academy, which will be able to help students and young professionals learn cybersecurity and digital forensics through interactive, hands-on modules.
I just finished adding the contact us, about us and login/signup pages to the Project, now I am planning on working on the other pages, starting with the dashboard Page
I just finish coding the student and admin dashboard, where they student can track its Progress in his different enrolled courses, and the admin can monitor the system thoroughly
I just finished coding the Student’s Training Courses & Labs Page, which contains the different courses the student can enroll and learn the skills from
Ships:
I built a web-based cybersecurity training platform designed to help students and young professionals build real-world digital defence skills. The platform tackles the problem of inaccessible, overly theoretical cybersecurity education by combining structured course modules, hands-on hacking labs, timed live events, and a dual-portal system — all wrapped in a sleek, professional interface. It wasn’t really easy, to compile and make everything work perfectly, but with time and concentration, I was able, it’s also true that I am not completely done with the Project, but will keep on doing changes until the project is fully developed...
|
1792839220.7591815
|
1792925620.7591815
|
|
904
|
Girlfriend Simulator by @snehasish | Stardance
|
|
2
|
37.0
|
434
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-03T20:03:26Z", "hours": 9.0, "multiplier": 15.93, "payout": 148, "blessing": "neutral", "text": "Major Updates for Girlfriend Simulator Note: This is the final update (ship) and no more updates will be made in future to this project. Main Updates Girlfriend Memories: Your Girlfriend remembers every small detail you share about yourself in her chat. Persistent Relationship Profile: Your girlfriend also remembers how you treated her on your last conversation and her mood really depends on that the next time you have a conversation with her Your own Models: Your girlfriend can run on your own API key. By default uses Google Gemini 2.5 Flash (so you will need a Gemini API Key). This removes any limits to daily conversations (capped at 20 when using not-your-model. Mood Aware User Interface: Your chat colors, themes and styling changes based on your girlfriend’s mood. Helps you understand what situation you’re currently in XD", "repo": "https://github.com/snhsish/gfsim", "demo": "https://gfsim.snehasish.xyz"}, {"ship_num": 2, "ts": "2026-06-08T09:27:01Z", "hours": 28.0, "multiplier": 12.02, "payout": 286, "blessing": "neutral", "text": "I built a Girlfriend Simulator which simulates a start-to-end relationship with your personally characterized girlfriend (powered by different fine-grained AI models). Why is it different from an AI wrapper or asking ChatGPT to “pretend to be my girlfriend?”: Well, the experience here is more natural and more likely-to-be-a-real-girlfriend type xi. Problems faced: getting the model to be more natural. I had fine-tuned a Qwen model which performed pretty well and NATURAL when replying as girlfriend, but due to high costing I cannot be putting it out in the public for free usage, so I had to use a fine-grained Qwen model (system prompt) Some pages / features are still not completed, but the chat experience is working completely fine!", "repo": "https://github.com/snhsish/gfsim", "demo": "https://gfsim.snehasish.xyz"}]...
|
[{"post_id": 13566, "ts": "202 [{"post_id": 13566, "ts": "2026-06-22T06:36:28Z", "hours": 4.0833, "text": "Girlfriend Simulator : Major Update This update is all about feature improvement. What’s New Persistent Relationship Profile Previously relationship state was ephemeral, i.e. everytime you started a new chat, your relationship state was back to NORMAL. But now things have changed. A persistent relationship state has been introduced. Your behavioral rating is now taken more seriously. How you reply, how you react and how you understand her, matters now Inactivity Tracking Your latest message is now tracked by the system to set your girlfriend’s mood. If you have ghosted her for long, it must have affected her behaviour. This lets her react naturally to absences (cold, sarcastic, or confrontational depending on health/mood). Mood-aware UI The UI of the chat changes according to your girlfriend’s mood now. So you get a hint when to make her feel wanted and when to make her laugh."}, {"post_id": 11313, "ts": "2026-06-18T14:40:13Z", "hours": 3.2144, "text": "You can now configure and bring in your own API Keys Currently only Gemini API Key is supported which uses the gemini-2.5-flash model Why bring in your own keys? Well there’s a 20 message per user daily limit when using the server provided model. But you definitely might want to talk to your GF more than just 20 messages a day right :) So if you bring in your own keys, you can chat without any limits! You can view usages of your own keys from the Usage page itself ( /account/usage ) Are my keys safe? Your keys are stored in your browser’s localStorage. It’s not sent to our servers at all. (You can verify checking the opensource code anyways!) ALSO, thanks to some of you guys who tried out the simulator, tried to jailbreak and manipulate the models, it helped me understand the system a little more. ALSO, the sim is completely SFW - even if you go NSFW. LYG<3"}, {"post_id": 5578, "ts": "2026-06-09T12:56:21Z", "hours": 2.0533, "text": "Your can now view your Girlfriend’s “Memories”. Memories are basically a collection of details (birthday, job description, reminders, etc.) you mention/share about yourself in chat. It is stored, so that it can be passed as context for your girlfriend. So now she actually remembers the “small details about you”. Uses a second LLM call which analyzes your messages to check if any important “detail” about you has been sent, so your girlfriend remembers it. You can always delete the sensitive ones and recommended."}, {"post_id": 4490, "ts": "2026-06-07T20:25:51Z", "hours": 10.8542, "text": "Lot of updates: Chat persistence: Your chats with your GF are now permanently stored in cloud, so you can access the chats anytime. Chats infinite scroll: To not display all your 100k messages with your GF at once and break stuff, infinite scroll has been added to chat to load old chats on demand Add reaction to messages: You can now react to messages from your girlfriend (and there’s a chance she might get pssed off from that and reply about it). Also your girlfriend can react to your messages too now. * You can currently only react to message groups and now individual message bubble, it’ll be fixed in a future update. Added no-reply handler: SO BASICALLY you can be left ON-SEEN or ON-DELIVERED by your girlfriend if you misbehave lol Some bug fixes: add limit to user message input, GF’s side texts not being stored in DB, etc. Some UI/UX optimizations alongside system prompt optimizations for the MODEL. * I really want to optimize the system prompt even further more ’cause currently it uses almost 1k tokens per message which feels quiet unoptimized and over-usage of tokens"}, {"post_id": 3331, "ts": "2026-06-06T06:38:09Z", "hours": 6.5922, "text": "Added: Account Page: where you can update your OWN profile details like your avatar, name, description, DOB, MBTI, zodiac, etc. which will let your girlfriend know about you and your personality (from your description of you) User Welcome Screen and Navigation Tour: For better UX and understandibility, I have added a welcome screen modal with three steps explaining what the app is about and how it works + sidebar tour for explaining what each link does Signout button in account page Next:: Public Use Launch"}, {"post_id": 2181, "ts": "2026-06-04T15:13:05Z", "hours": 5.2556, "text": "made the usage page which shows tokens and messages for the past 14 days also here are some sample girlfriend responses which felt natural to me"}, {"post_id": 762, "ts": "2026-06-02T12:29:59Z", "hours": 1.7394, "text": "chats now work model: qwen the model smh replies and added multi message support"}, {"post_id": 414, "ts": "2026-06-01T20:18:42Z", "hours": 1.0042, "text": "updated message input and added attachment input (menu), emoji selector and GIF picker also implemented auto-height increment for the message input textarea and enter-is-send and shift-enter-is-not-send for the message input next: send the message and get a response (basic) via VERCEL AI SDK + Gemini Google API"}, {"post_id": 341, "ts": "2026-06-01T17:20:30Z", "hours": 2.1508, "text": "setup and designed the app interface and the chat page with beautiful starter texts to send to your AI girlfriend and get the convo started. next: design the chat input section along"}, {"post_id": 184, "ts": "2026-06-01T06:32:25Z", "hours": 0.5367, "text": "Added user authentication (login page) using Google OAuth (better-auth + supabase) setup"}]...
|
Title: Girlfriend Simulator by @snehasish | Starda Title: Girlfriend Simulator by @snehasish | Stardance
Devlogs:
Added user authentication (login page) using Google OAuth (better-auth + supabase) setup
setup and designed the app interface and the chat page with beautiful starter texts to send to your AI girlfriend and get the convo started. next: design the chat input section along
updated message input and added attachment input (menu), emoji selector and GIF picker also implemented auto-height increment for the message input textarea and enter-is-send and shift-enter-is-not-send for the message input next: send the message and get a response (basic) via VERCEL AI SDK + Gemini Google API
chats now work model: qwen the model smh replies and added multi message support
made the usage page which shows tokens and messages for the past 14 days also here are some sample girlfriend responses which felt natural to me
Added: Account Page: where you can update your OWN profile details like your avatar, name, description, DOB, MBTI, zodiac, etc. which will let your girlfriend know about you and your personality (from your description of you) User Welcome Screen and Navigation Tour: For better UX and understandibility, I have added a welcome screen modal with three steps explaining what the app is about and how it works + sidebar tour for explaining what each link does Signout button in account page Next:: Public Use Launch
Lot of updates: Chat persistence: Your chats with your GF are now permanently stored in cloud, so you can access the chats anytime. Chats infinite scroll: To not display all your 100k messages with your GF at once and break stuff, infinite scroll has been added to chat to load old chats on demand Add reaction to messages: You can now react to messages from your girlfriend (and there’s a chance she might get pssed off from that and reply about it). Also your girlfriend can react to your messages too now. * You can currently only react to message groups and now individual message bubble, it’ll be fixed in a future update. Added no-reply handler: SO BASICALLY you can be left ON-SEEN or ON-DELIVERED by your girlfriend if you misbehave lol Some bug fixes: add limit to user message input, GF’s side texts not being stored in DB, etc. Some UI/UX optimizations alongside system prompt optimizations for the MODEL. * I really want to optimize the system prompt even further more ’cause currently it uses almost 1k tokens per message which feels quiet unoptimized and over-usage of tokens
Your can now view your Girlfriend’s “Memories”. Memories are basically a collection of details (birthday, job description, reminders, etc.) you mention/share about yourself in chat. It is stored, so that it can be passed as context for your girlfriend. So now she actually remembers the “small details about you”. Uses a second LLM call which analyzes your messages to check if any important “detail” about you has been sent, so your girlfriend remembers it. You can always delete the sensitive ones and recommended.
You can now configure and bring in your own API Keys Currently only Gemini API Key is supported which uses the gemini-2.5-flash model Why bring in your own keys? Well there’s a 20 message per user daily limit when using the server provided model. But you definitely might want to talk to your GF more than just 20 messages a day right :) So if you bring in your own keys, you can chat without any limits! You can view usages of your own keys from the Usage page itself ( /account/usage ) Are my keys safe? Your keys are stored in your browser’s localStorage. It’s not sent to our servers at all. (You can verify checking the opensource code anyways!) ALSO, thanks to some of you guys who tried out the simulator, tried to jailbreak and manipulate the models, it helped me understand the system a little more. ALSO, the sim is completely SFW - even if you go NSFW. LYG<3
Girlfriend Simulator : Major Update This update is all about feature improvement. What’s New Persistent Relationship Profile Previously relationship state was ephemeral, i.e. everytime you started a new chat, your relationship state was back to NORMAL. But now things have changed. A persistent relationship state has been introduced. Your behavioral rating is now taken more seriously. How you reply, how you react and how you understand her, matters now Inactivity Tracking Your latest message is now tracked by the system to set your girlfriend’s mood. If you have ghosted her for long, it must have affected her behaviour. This lets her react naturally to absences (cold, sarcastic, or confrontational depending on health/mood). Mood-aware UI The UI of the chat changes according to your girlfriend’s mood now. So you get a hint when to make her feel wanted and when to make her laugh.
Ships:
I built a Girlfriend Simulator which simulates a start-to-end relationship with your personally characterized girlfriend (powered by different fine-grained AI models). Why is it different from an AI wrapper or asking ChatGPT to “pretend to be my girlfriend?”: Well, the experience here is more natural and more likely-to-be-a-real-girlfriend type xi. Problems faced: getting the model to be more natural. I had fine-tuned a Qwen model which performed pretty well and NATURAL when replying as girlfriend, but due to high costing I cannot be putting it out in the public for free usage, so I had to use a fine-grained Qwen model (system prompt) Some pages / features are still not completed, but the chat experience is working completely fine!
Major Updates for Girlfriend Simulator Note: This is the final update (ship) and no more updates will be made in future to this project. Main Updates Girlfriend Memories: Your Girlfriend remembers every small detail you share about yourself in her chat. Persistent Relationship Profile: Your girlfriend also remembers how you treated her on your last conversation and her mood really depends on that the next time you have a conversation with her Your own Models: Your girlfriend can run on your own API key. By default uses Google Gemini 2.5 Flash (so you will need a Gemini API Key). This removes any limits to daily conversations (capped at 20 when using not-your-model. Mood Aware User Interface: Your chat colors, themes and styling changes based on your girlfriend’s mood. Helps you understand what situation you’re currently in XD...
|
1792846336.150428
|
1792932736.150428
|
|
905
|
My first slack bot! by @Korvid_ | Stardance
|
Korvid_
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @Korvid_ | Stardance
|
1792540276.7681267
|
1793145076.7681267
|
|
906
|
the a380 websitr by @sushan_kommireddi | Stardance
|
sushan_kommireddi
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: the a380 websitr by @sushan_kommireddi | St Title: the a380 websitr by @sushan_kommireddi | Stardance...
|
1792479189.7654428
|
1793083989.7654428
|
|
907
|
My awesome macropad! by @hoangco050309 | Stardance
|
hoangco050309
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @hoangco050309 | St Title: My awesome macropad! by @hoangco050309 | Stardance...
|
1792756226.0422983
|
1793361026.0422983
|
|
908
|
My awesome macropad! by @Munnisparkle | Stardance
|
Munnisparkle
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Munnisparkle | Sta Title: My awesome macropad! by @Munnisparkle | Stardance...
|
1792583434.9012291
|
1793188234.9012291
|
|
909
|
NULL
|
NULL
|
0
|
0.0
|
0
|
[]
|
[]
|
|
1792936069.7172894
|
1793800069.7172894
|
|
910
|
Personal site by @koeg | Stardance
|
koeg
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Personal site by @koeg | Stardance
|
1792569274.3554158
|
1793174074.3554158
|
|
911
|
MagLight by @Aayan | Stardance
|
Aayan
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: MagLight by @Aayan | Stardance
|
1792745443.2115872
|
1793350243.2115872
|
|
912
|
My awesome macropad! by @inashauraazkazola | Stard My awesome macropad! by @inashauraazkazola | Stardance...
|
inashauraazkazola
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @inashauraazkazola Title: My awesome macropad! by @inashauraazkazola | Stardance...
|
1792579768.0685782
|
1793184568.0685782
|
|
913
|
ROBOTIC ARM by @goodaysarecomingsoon | Stardance
|
goodaysarecomingsoon
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: ROBOTIC ARM by @goodaysarecomingsoon | Star Title: ROBOTIC ARM by @goodaysarecomingsoon | Stardance...
|
1792493347.0786133
|
1793098147.0786133
|
|
914
|
Untitled by @inashauraazkazola | Stardance
|
inashauraazkazola
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @inashauraazkazola | Stardance
|
1792684438.7385347
|
1793289238.7385347
|
|
915
|
My awesome macropad! by @haspritarestia | Stardanc My awesome macropad! by @haspritarestia | Stardance...
|
haspritarestia
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @haspritarestia | S Title: My awesome macropad! by @haspritarestia | Stardance...
|
1792493373.4370193
|
1793098173.4370193
|
|
916
|
Website by @Accursed_Drifter | Stardance
|
Accursed_Drifter
|
1
|
4.0
|
5
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-05T17:18:46Z", "hours": 4.0, "multiplier": 1.3, "payout": 5, "blessing": "neutral", "text": "I made a tracking website in order to practice making a navagation bar and to learn about locally saving data", "repo": "https://github.com/lhair400-blip/Simple-Website", "demo": "https://easytrackingsite.netlify.app/"}]...
|
[{"post_id": 2571, "ts": "2026 [{"post_id": 2571, "ts": "2026-06-05T04:24:30Z", "hours": 2.7225, "text": "I redid the UI and made a Nav bar at the top"}, {"post_id": 1138, "ts": "2026-06-02T23:44:48Z", "hours": 1.3778, "text": "Started making my Website earlier today. I added a basic to do list and experimented with a light mode and a dark mode"}]...
|
Title: Website by @Accursed_Drifter | Stardance
D Title: Website by @Accursed_Drifter | Stardance
Devlogs:
Started making my Website earlier today. I added a basic to do list and experimented with a light mode and a dark mode
I redid the UI and made a Nav bar at the top
Ships:
I made a tracking website in order to practice making a navagation bar and to learn about locally saving data...
|
1792824846.6897635
|
1792911246.6897635
|
|
917
|
Simple python calculator in Ctk by @Thomas_Harker Simple python calculator in Ctk by @Thomas_Harker | Stardance...
|
Thomas_Harker
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Simple python calculator in Ctk by @Thomas_ Title: Simple python calculator in Ctk by @Thomas_Harker | Stardance...
|
1792608742.646674
|
1793213542.646674
|
|
918
|
Hackisskey: A Misskey server for Hack Clubbers by Hackisskey: A Misskey server for Hack Clubbers by @Korange | Stardance...
|
Korange
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Hackisskey: A Misskey server for Hack Clubb Title: Hackisskey: A Misskey server for Hack Clubbers by @Korange | Stardance...
|
1792705783.1139278
|
1793310583.1139278
|
|
919
|
A simple to do by @goodaysarecomingsoon | Stardanc A simple to do by @goodaysarecomingsoon | Stardance...
|
goodaysarecomingsoon
|
1
|
6.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-27T13:07:56Z", "hours": 6.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made Sentinel, a simple to-do list focused on deadlines. You can add tasks with a date and time, see a live countdown, tick completed tasks with a strike-through animation, and import or export tasks using JSON. The most challenging part was getting the countdown to update accurately every second and figuring out how to handle JSON since I was new to it. I’m proud that I turned a problem I actually have—missing deadline after deadline—into something useful and a little funny:)", "repo": "https://github.com/Optimus-Prime04/A-Simple-To-Do", "demo": "https://a-simple-to-do.vercel.app/"}]...
|
[{"post_id": 55523, "ts": "202 [{"post_id": 55523, "ts": "2026-08-27T13:03:16Z", "hours": 2.6192, "text": "finally completed everthing check out https://a-simple-to-do.vercel.app/"}, {"post_id": 54459, "ts": "2026-08-25T14:06:05Z", "hours": 1.9194, "text": "after a long session finally my style.css is over"}, {"post_id": 53818, "ts": "2026-08-24T14:51:53Z", "hours": 0.4514, "text": "finally mu index.css is done"}, {"post_id": 53786, "ts": "2026-08-24T14:18:37Z", "hours": 0.4303, "text": "i have completed my tasks.html after a long terminal session"}, {"post_id": 53769, "ts": "2026-08-24T13:34:42Z", "hours": 0.3425, "text": "i have created my index.html"}]...
|
Title: A simple to do by @goodaysarecomingsoon | S Title: A simple to do by @goodaysarecomingsoon | Stardance
Devlogs:
i have created my index.html
i have completed my tasks.html after a long terminal session
finally mu index.css is done
after a long session finally my style.css is over
finally completed everthing check out https://a-simple-to-do.vercel.app/
Ships:
I made Sentinel, a simple to-do list focused on deadlines. You can add tasks with a date and time, see a live countdown, tick completed tasks with a strike-through animation, and import or export tasks using JSON. The most challenging part was getting the countdown to update accurately every second and figuring out how to handle JSON since I was new to it. I’m proud that I turned a problem I actually have—missing deadline after deadline—into something useful and a little funny:)...
|
1792839110.6288881
|
1792925510.6288881
|
|
920
|
My first slack bot! by @goodaysarecomingsoon | Sta My first slack bot! by @goodaysarecomingsoon | Stardance...
|
goodaysarecomingsoon
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @goodaysarecomingsoo Title: My first slack bot! by @goodaysarecomingsoon | Stardance...
|
1792579738.6010048
|
1793184538.6010048
|
|
921
|
Huai - A way of making AI more efficient by @jam06 Huai - A way of making AI more efficient by @jam06452 | Stardance...
|
jam06452
|
0
|
5.22
|
0
|
[]
|
[{"post_id": 4099, "ts": "2026 [{"post_id": 4099, "ts": "2026-06-07T09:15:03Z", "hours": 0.6194, "text": "Claude made the CSS look nicer, Added FFMPEG for videos."}, {"post_id": 393, "ts": "2026-06-01T19:27:08Z", "hours": 1.0975, "text": "FINALLY, finished making a deployment workflow on GH Actions with a dockerfile & caching. I had so much issues with UV, snex, and python running properly with elixir. FFMPEG and avconv isnt found but that is not important since its pulled pydub for the markitdown lib. May need to fix for videos"}, {"post_id": 286, "ts": "2026-06-01T15:00:25Z", "hours": 1.1592, "text": "Added markdown & Image support. You can now input an image and markdown is returned depending on the image. This helps to further save AI Token usage."}, {"post_id": 258, "ts": "2026-06-01T13:19:34Z", "hours": 0.4103, "text": "Added a Copy button to this, this uses 5 lines of JS. I am doing as much without JS as I can via hooks with Phoenix Liveview. The real styling is yet to come"}, {"post_id": 221, "ts": "2026-06-01T10:06:24Z", "hours": 1.9289, "text": "I added a basic UI with minimal CSS, the backend is working well. I had issues making it convert it sequentially so I am having to async it with Task.start() and sending the result back the original PID. I added an upload loading bar to show how far along it will be to upload.Then a loading wheel to show that it is processing it. after it returns pure markdown. I am going to style it and make it easily copy and pastable afterwards"}]...
|
Title: Huai - A way of making AI more efficient by Title: Huai - A way of making AI more efficient by @jam06452 | Stardance
Devlogs:
I added a basic UI with minimal CSS, the backend is working well. I had issues making it convert it sequentially so I am having to async it with Task.start() and sending the result back the original PID. I added an upload loading bar to show how far along it will be to upload.Then a loading wheel to show that it is processing it. after it returns pure markdown. I am going to style it and make it easily copy and pastable afterwards
Added a Copy button to this, this uses 5 lines of JS. I am doing as much without JS as I can via hooks with Phoenix Liveview. The real styling is yet to come
Added markdown & Image support. You can now input an image and markdown is returned depending on the image. This helps to further save AI Token usage.
FINALLY, finished making a deployment workflow on GH Actions with a dockerfile & caching. I had so much issues with UV, snex, and python running properly with elixir. FFMPEG and avconv isnt found but that is not important since its pulled pydub for the markitdown lib. May need to fix for videos
Claude made the CSS look nicer, Added FFMPEG for videos....
|
1792497299.1409783
|
1793102099.1409783
|
|
922
|
JuniperDev jam game by @AloneAlex | Stardance
|
AloneAlex
|
0
|
4.18
|
0
|
[]
|
[{"post_id": 12576, "ts": "202 [{"post_id": 12576, "ts": "2026-06-20T15:17:08Z", "hours": 1.6344, "text": "Player movement is now complete, and it includes wall jumping and coyote timing! Also replaced my camera script that I slap on every project with unity’s Chinemacine camera, it makes stuff much more easy!"}, {"post_id": 12480, "ts": "2026-06-20T11:47:46Z", "hours": 1.475, "text": "I ended up scrapping the previous prototype and making a new one. Just finished making the movement properly (though I might replace the gravity for something custom for better precision and less jiserring)"}, {"post_id": 12005, "ts": "2026-06-19T16:16:38Z", "hours": 1.0672, "text": "Began prototyping ideas! First idea is: you’re controlling earth with a huge canon and try to get the planet flung outside of the solar system. I like it, but it’s quite hard to implement exactly what I want, so I might give up on this idea In the meanwhile here’s one of my tests:"}]...
|
Title: JuniperDev jam game by @AloneAlex | Stardan Title: JuniperDev jam game by @AloneAlex | Stardance
Devlogs:
Began prototyping ideas! First idea is: you’re controlling earth with a huge canon and try to get the planet flung outside of the solar system. I like it, but it’s quite hard to implement exactly what I want, so I might give up on this idea In the meanwhile here’s one of my tests:
I ended up scrapping the previous prototype and making a new one. Just finished making the movement properly (though I might replace the gravity for something custom for better precision and less jiserring)
Player movement is now complete, and it includes wall jumping and coyote timing! Also replaced my camera script that I slap on every project with unity’s Chinemacine camera, it makes stuff much more easy!...
|
1792918298.2674713
|
1793782298.2674713
|
|
923
|
A Slack Bot by @Arham_Ali | Stardance
|
Arham_Ali
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: A Slack Bot by @Arham_Ali | Stardance
|
1792777750.47269
|
1793382550.47269
|
|
924
|
My first slack bot! by @Anay | Stardance
|
Anay
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @Anay | Stardance
|
1792648055.490977
|
1793252855.490977
|
|
925
|
Snake Game by @haspritarestia | Stardance
|
haspritarestia
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Snake Game by @haspritarestia | Stardance
|
1792695144.203276
|
1793299944.203276
|
|
926
|
Spotlight by @lumiere | Stardance
|
lumiere
|
1
|
3.0
|
4
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-10T06:37:34Z", "hours": 3.0, "multiplier": 1.24, "payout": 4, "blessing": "neutral", "text": "A static html css site. I was doing the css animations for the first so they were kinda confusing. It is just a small project and i dont plan on anything further", "repo": "https://github.com/lumiere4758/spotlight", "demo": "https://lumiere4758.github.io/spotlight/"}]...
|
[{"post_id": 6066, "ts": "2026 [{"post_id": 6066, "ts": "2026-06-10T06:07:50Z", "hours": 0.5561, "text": "finsihed it, added some effects and animations, now i will deploy and submit"}, {"post_id": 6052, "ts": "2026-06-10T05:12:29Z", "hours": 0.8217, "text": "idk wat i did, but it turned out like this. have to work moreeeeeeeeeeeeeee mroe mmroe"}, {"post_id": 6025, "ts": "2026-06-10T03:18:44Z", "hours": 0.3011, "text": "More stylinggg"}, {"post_id": 6021, "ts": "2026-06-10T02:55:55Z", "hours": 0.6122, "text": "styles the carousel, im thinking of add my own touch by using some movie api to fetch latest ones"}, {"post_id": 5648, "ts": "2026-06-09T14:57:00Z", "hours": 0.4058, "text": "created and finished the header"}, {"post_id": 5621, "ts": "2026-06-09T14:28:20Z", "hours": 0.3925, "text": "base model of the webpage"}]...
|
Title: Spotlight by @lumiere | Stardance
Devlogs: Title: Spotlight by @lumiere | Stardance
Devlogs:
base model of the webpage
created and finished the header
styles the carousel, im thinking of add my own touch by using some movie api to fetch latest ones
More stylinggg
idk wat i did, but it turned out like this. have to work moreeeeeeeeeeeeeee mroe mmroe
finsihed it, added some effects and animations, now i will deploy and submit
Ships:
A static html css site. I was doing the css animations for the first so they were kinda confusing. It is just a small project and i dont plan on anything further...
|
1792828264.6372614
|
1792914664.6372614
|
|
927
|
Squirrel by @Koei | Stardance
|
Koei
|
3
|
104.0
|
1915
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-19T13:34:37Z", "hours": 29.0, "multiplier": 17.36, "payout": 598, "blessing": "neutral", "text": "v1.0.0 Squirrel is a clipboard manager for Windows and X11 Linux that is meant to be simple and intuitive. This major release overhauls the data storage schema to be more efficient, faster, and reliable. There are significant performance improvements. This release also adds configurability to Squirrel, allowing basic but much needed customization, and polishes up the overall app. Check the README for more information.", "repo": "https://github.com/Koei32/squirrel", "demo": "https://github.com/Koei32/squirrel/releases/latest"}, {"ship_num": 2, "ts": "2026-07-26T14:30:06Z", "hours": 30.0, "multiplier": 13.88, "payout": 499, "blessing": "neutral", "text": "v0.3.0 Squirrel is a clipboard manager that is meant to be simple and intuitive. 2 new features in this version, namely pinning and image support. There are performance improvements as well as slight visual tweaks. Read the README for more info.", "repo": "https://github.com/Koei32/squirrel", "demo": "https://github.com/Koei32/squirrel/releases/latest"}, {"ship_num": 3, "ts": "2026-06-23T16:48:48Z", "hours": 45.0, "multiplier": 18.23, "payout": 818, "blessing": "neutral", "text": "v0.1.0 Squirrel is a clipboard manager that is meant to be simple and intuitive. It remembers all the text you copy allowing you to paste whatever into wherever. You can also quickly search through your history. Squirrel is meant to be cross-platform, but for this release, Linux support on Wayland is very iffy (X11 is fine for the most part). I would highly recommend using Windows for testing this ship, sorry for the inconvenience. Expect potentially better support next ship.", "repo": "https://github.com/Koei32/squirrel", "demo": "https://github.com/Koei32/squirrel/releases/latest"}]...
|
[{"post_id": 63114, "ts": "202 [{"post_id": 63114, "ts": "2026-09-06T18:50:53Z", "hours": 4.0806, "text": "v1.0.0 It’s official. Squirrel is now v1. devlog time is adding logging, updating readme, fixing some small tidbits and polishing up some areas of the app. Squirrel now prints pretty logs to console when running in development mode and writes logs to a file if running in release. Project status i realistically can not get a GUI settings panel done due to me needing to divert my attention to more important life stuff. this right here is probably going to be the extent of work done on Squirrel in stardance. i definitely do plan on working on this in the long term. for example, im not entirely happy and satisfied with the current UI, and global hotkey still does not work on wayland. but right now, more pressing issues are at hand and i cannot give it my all on this project. that said, i do believe that Squirrel is in a very usable 1.0 state, which was my goal. i might push minor updates if the reviews call for fixes/improvements, but definitely no major features. thanks for reading if you made it here."}, {"post_id": 54719, "ts": "2026-08-25T19:56:34Z", "hours": 3.9647, "text": "History persistence configuration now works. setting it to false means history is not retained between sessions. comes with true as default. pinned entries always persist. attachment shows the behavior when persistence is off. Implementation i ended up deciding not to do the in memory database method for this since it was a bit too much added complexity which could be avoided by just adding an additional is_persistent column to the db. im not the happiest about how i’ve implemented this right now but im willing to take that hit right now if it means i dont have to deal with databases. Next all of the config options are now implemented. we are very close to v1.0. expect progress to be rather slow from here on out. i’ve had to divert my attention towards other things and haven’t been able to spend a lot of time working on my projects. maybe i will work on a settings panel. depends on how much work it requires. it’s a maybe. i may just ship it as it stands right now."}, {"post_id": 51853, "ts": "2026-08-21T18:35:09Z", "hours": 0.8633, "text": "Item expiry and pin-preservation expired items are now automatically deleted on program startup. an entry is considered expired when the current time is more than its expires_at value. when pinned, the expires_at attribute is nulled, meaning this entry will never expire. the “Clear all” shortcut Ctrl+Shift+Del now respects pinned entries. it clears everything but leaves pinned entries untouched. Next the ephemeral db shenanigans. also, i have decided that Squirrel needs a settings panel in the frontend for easier config modification. that may or may not happen but it is tempting to do it."}, {"post_id": 51243, "ts": "2026-08-20T19:36:27Z", "hours": 5.9658, "text": "(i genuinely have no idea what to show in the devlog attachment, nothing’s changed visually. so have this stupid ass screenshot.) Massive refactor, breaking changes now that i’ve given myself the liberty to rethink and redesign Squirrel’s data models and storage in a breaking fashion for v1, we have managed to make a good amount of improvements across the board. database schema has been modified to better suit current needs and make it possible to implement the features I desire for v1. it has been a very satisfying refactor. What’s new: use UNIX microsecond timestamp for event ids instead of relying on sqlite autoincrement. this allows us to immediately send a captured event to the frontend without having to await a db write to obtain the event id. this also eliminates the timestamp column for events since the id is also the timestamp. a dedicated BLOB column for image entries to store raw image bytes instead of b64 encoded strings. this makes images weigh about ~33% lighter. decent perf boost. new expires_at column to store when an entry expires. pinned entries have an expiry of NULL . provides the base to actually implement expiring entries. get rid of ClipboardEventNotice since we no longer do the notify frontend -> write to db -> send data to frontend dance. it is now simply send whole event to frontend -> write to db . we enjoy simplifications. (!) as it stands now, old data (if it exists) would immediately be wiped when launching Squirrel v1. i could write some migration code but we’ll see. maybe clipboard data isn’t important enough to bother with migration. Next: actually implement entry expiration: should be trivial, just delete expired entries on launch. ephemeral/persistent toggle: this one is a bit tricky, and will involve some in memory database shenanigans. more details in the devlog when i implement this."}, {"post_id": 47102, "ts": "2026-08-14T19:04:13Z", "hours": 0.8614, "text": "Ignore programs you can specify programs in which Squirrel should not listen to clipboard events. this is useful when you’re working in a program wherein you need to use copy and paste a bunch. ignoring that program would keep your Squirrel history clean. also useful to ignore a program that you regularly copy secrets from. example of notepad being ignored:"}, {"post_id": 46488, "ts": "2026-08-13T18:43:57Z", "hours": 3.6642, "text": "devlog attachment obligation: here is me pasting some files i copied a couple minutes ago after i copied stuff on top of that. that out of the way, devlog. Several things app theme is now configurable from config, so you are not stuck with the system theme if you want to change it. cleanup across the backend; comments, TODOs, error handling, and stuff of the sort. performance enhancement in the clipboard event emitter loop. bugfix in the same loop where the thread panicked if you copied something while the app was launching. merged the config branch. the remaining config options would be better to implement in their own branches. dependabot updates"}, {"post_id": 46172, "ts": "2026-08-13T06:19:26Z", "hours": 3.2672, "text": "Configuration (wip) Squirrel now has a configuration file. squirrel.toml is created in the config directory of your OS (i.e. %appdata%/Squirrel on windows and /home/username/.config/Squirrel on linux), finally allowing some amount of customization support. right now, only the types and the max_image_size config options work. types allows you to choose which kind of clipboard items are captured/ignored. max_image_size is self explanatory. attached is the full config file. the remaining options require a bit of work to implement."}, {"post_id": 44184, "ts": "2026-08-09T19:34:47Z", "hours": 0.5053, "text": "Turns out, copy and paste support for files was a one line diff. also, Squirrel is now v0.4.0, yippee. anyways, moving swiftly on. Planning for a v1.0 Squirrel is now in a state where we have most of the major features i wanted it to have: support for essential clipboard data types, pinning and search. however, it is not quite in a v1.0 state. there are a bunch of things i want to add to polish up the program and make it feel sort of “complete”, which is mainly focusing on some basic configuration ability. since sensible defaults are hard to figure out, i’d rather let the user break things instead of being stuck with my arbitrary decisions. thus, i present the current planned feature list for v1: Configuration : enabling basic behavior customization through a config file (TOML most likely) Program exceptions : dont capture clipboard data on certain programs Auto delete/never store : ability to specify a “shelf life” for items, or whether to store them persistently at all. Disable specific types : ability to pick which kind of clipboard events to capture, i.e. only text or text and images, etc. Configurable image size threshold : currently locked to 5mb, this would allow to specify a custom value. (?) Custom data storage format : still torn on this, but there may be performance to be gained by moving to a data store more geared for our purposes. this list ofcourse, might change. implementing these features would make Squirrel much more flexible, and make it v1 worthy."}, {"post_id": 43522, "ts": "2026-08-08T20:50:19Z", "hours": 5.0344, "text": "Rudimentary file support we now have the most basic kind of file support there could be. which is just storing the path to the file. we then provide a link to the file in the frontend, clicking on which reveals the file in your explorer. we also now have tiny little icons on the entries which indicate the entry type. all icons thanks to https://lucide.dev/ files ofcourse, need a bit more work. right now, you cant really do much except revealing in explorer. i will work on adding copy and paste support for files next, as well as maybe improve the overall performance a bit."}, {"post_id": 40907, "ts": "2026-08-04T18:49:27Z", "hours": 0.4922, "text": "Acting on feedback a shipwright recommended i change my banner to include a screenshot of the program. so we now have a shiny new banner that should look good everywhere on the site. this required me to figure out what dimensions the banner is shown at across the site. i’ve attached a rough template for banners. fitting everything inside the marked areas should make sure your banner isn’t cut off anywhere that matters. one reviewer rightfully couldn’t figure out how to quick paste items. this is a miss on my part because i didn’t really have a list of shortcuts anywhere and kind of just mentioned them in passing in the README. that has been rectified by adding a Shortcuts section to the readme."}, {"post_id": 35201, "ts": "2026-07-26T13:57:06Z", "hours": 0.8461, "text": "Set for ship release is made, README updated. should be good to go."}, {"post_id": 33659, "ts": "2026-07-23T19:06:47Z", "hours": 0.9039, "text": "Basic image cache we now cache the last 32 images, fetching from the backend when required and updating the cache. made the image re-rendering issue instantly better. attached is the demo video i forgot to upload in the second to last devlog showing images in action. Performance images are a difficult thing to handle, especially when dealing with the system clipboard. i’ve made Squirrel as performant as i could to the best of my abilities, which is to say, it’s not the best. it isn’t as rich as i would like it to be, so i might return to this feature to improve it in the future. one restriction i’ve put on images to control some of the chaos is limiting the size to 5 megabytes, meaning any image above 5 megs isn’t registered. i could push that to 10, which is still practically instant. but Squirrel is intended to be a quick clipboard, and not dropbox. so this is my cheaty little escape. maybe i’ll relax the limit in the future if 5mb is really restrictive. Next? i’ll probably bump the minor version and ship (i wouldn’t dare a v1.0 currently). i’d say pinning and image support is enough to warrant a second ship. beyond that though, stands file(s) support, so a lot of decision making on how i want it to work to have a good balance of performance and usefulness. a bit of a lengthy devlog this one, and i appreciate if you read all that. but i wanted to clear up some things for myself and just have a frame of reference where Squirrel stands right now after returning from a development break."}, {"post_id": 33376, "ts": "2026-07-23T08:11:18Z", "hours": 0.3458, "text": "Image branch is merged yay, yippee even. next i need to implement a frontend cache to store the last X entries’ contents, particularly for images. the way it works right now, every time the images are re-rendered (due to being filtered by search, for example), content is fetched from the backend. this ofcourse, is less than ideal. but shouldnt be a lot of trouble to fix."}, {"post_id": 32539, "ts": "2026-07-21T19:47:15Z", "hours": 4.9058, "text": "Bunch of things Image Improvements some performance enhancements with images. made the clipboard image data fetching happen in Tauri’s dedicated thread pool, effectively parallelizing the operation. this made image copying a lot faster. image support should be merged into master soon enough. Lazy loading we now have lazy loading for images. image data isn’t loaded until it is scrolled into view. makes startup quick. CI enabled Dependabot updates and optimized the lint workflows for PRs. previously, all of the project was lint+checked on PR when changing anything. now it only checks the part that’s changed (i.e. frontend or backend)"}, {"post_id": 31397, "ts": "2026-07-19T18:47:59Z", "hours": 4.4964, "text": "Progress on images we finally have some form of working image support in Squirrel. This required even more sweeping refactoring changes to the codebase, which was a bit painful and im sure the new code isn’t the best quality either and will bite me later, but we’ll deal with it when we deal with it. getting images is a bit slow however, as right now we’re storing the image as base64 encoded PNGs. i plan to use the SQLite blob type to just store the raw bytes and pass that back and forth to improve the performance a bit (maybe some sort of caching as well?). there are also other areas where that are to be improved but i wanted to get a somewhat working prototype as fast as i can. explaining the silence i’ve been distracted by some life stuff, making me neglect my projects a bit. i also got distracted by the ESP32, fun little device. that is where the 9 days went. but, expect me to work semi-regularly again. thanks for reading."}, {"post_id": 26042, "ts": "2026-07-10T16:57:23Z", "hours": 3.0411, "text": "Lots of refactoring (apologies for the uneventful devlog attachment, i have nothing interesting to show except just code) to make it a bit more manageable when adding image support, a bunch of refactoring and reorganizing has been done in the backend. like i’ve previously mentioned, the codebase leaned too hard into only supporting text events. this fixes that. today’s changes also make the internal communication a bit more efficient. there are a couple more places where performance can be improved. and we will need every bit of performance we can get when dealing with image data. Changelog (shoutout @Hridya for stardance utils, just discovered this) 5b3f285 refactor: move clipboard structures into separate file b3ab1c8 perf: only get required data from db when copying an item 69dc003 refactor: modify data types to enable addition of image support Release CI (wip) currently writing the Release workflow for Squirrel. i have to figure out how to upload the artifacts to a github release with proper versioning and all that. the strategy is to run the workflow whenever something is pushed to the release branch. that is all for today."}, {"post_id": 25496, "ts": "2026-07-09T20:07:22Z", "hours": 0.7936, "text": "Version bump and docs bumped the minor version. Squirrel is officially v0.2.0, yippi. plus, updated the README, adding more explanation about the Wayland issue. also showcased the pin feature. i’ll try to whip up a release workflow to add to my CI tomorrow. I’m debating whether i should ship v0.2.0. the only major change from 0.1.0 is the addition of pinning. i might wait until i have image support and ship later, or i might change my mind, im unsure."}, {"post_id": 24896, "ts": "2026-07-08T19:03:24Z", "hours": 1.2706, "text": "Closed 1 (one) issue moved the global launch hotkey logic from the frontend to the backend. it didn’t behave well in certain situations, failing to activate and bringing up the Squirrel window. Starting work on images we’re experimenting with images. the current functionality is very much caveman and needs a lot of attention to make it actually usable. i’ve decided to stick with clipboard_rs for now, we’ll see how that pans out."}, {"post_id": 24277, "ts": "2026-07-07T18:55:23Z", "hours": 4.1067, "text": "Sadness so i just found out that Tauri’s global shortcut plugin does not yet support Wayland, which is sad to discover this deep into development. but, there is an active PR addressing this issue , which is nice. what this means for Squirrel is that proper Wayland support will unfortunately have to wait until this is merged. the joys of using a not-yet-completely-matured framework i suppose. though it does make me feel a bit guilty for calling Squirrel “cross-platform”. in other news (changelog): Squirrel now has a --silent launch flag that makes it start with the window hidden. useful when the app is set to launch on system startup. Squirrel now makes sure there is only one instance of it running. The shortcut Ctrl+Shift+Del will clear history permanently. (i forgot about clear history functionality in the first ship even though the code for it existed, there just wasnt a button in the frontend to call it)"}, {"post_id": 22186, "ts": "2026-07-04T14:50:25Z", "hours": 4.1014, "text": "CI dipped my toes into github workflows, messed around, an got check&lint workflows working on pull requests. will make a release workflow some time later. this change however, was only a part of this devlog’s time. Bad decisions catching up turns out, using clipboard_rs might’ve been the subpar choice for interfacing with the system clipboard. while clipboard_rs provides a easy way to listen to clipboard changes and get text from it, fetching raw clipboard data is buggy and inconvenient. when i sat down to work on image support, i was immediately brick-walled by how messy it is to just get raw data first. it would’ve been simple if i was building for just one target os but considering both windows and linux, it’s less than ideal. on top of this, the documentation for the crate is very lackluster. all this to say, i am very much debating migrating my clipboard stuff to using arboard . arboard doesnt provide direct functionality to listen to clipboard changes so i will have to implement that myself. but, it does have first class support for wayland. a very enticing choice, but we will see."}, {"post_id": 18315, "ts": "2026-06-29T12:51:11Z", "hours": 2.7625, "text": "Navigation improvements slight refactoring and bugfixes for frontend navigation. the navigation was kinda wonky before this and sometimes wouldn’t highlight the entry that was actually selected in the background. most of this devlog’s work was to make it so that what you see is what you get. also, a touch of color has been added to pinned entries (tentative)."}, {"post_id": 17064, "ts": "2026-06-27T18:22:53Z", "hours": 2.5814, "text": "Pins we now have basic entry pinning support. this was a bit less difficult than i thought it was going to be. but now you can pin an item and it always stays at the top of the list (unless you’re searching). anyways, that is one item ticked off the todo list. apart from that, i had to do some minor backend refactoring and reorganizing so that it is easier to build more upon. next? image and/or file copy support. this is one monumental task. i think the way we’ll approach this is by storing the entire file if it’s smaller than, say 5mb, and if it is larger, we just store the path to the file. we dont want to store the user’s 5gb video file they just copied. for images, i think the play is to generate a low quality thumbnail of the image to display in the app. for files, if it is a text file, we can show just the first 5 or so lines with a link to the file, other wise we’ll just give a link. until now, the code i’ve written sadly relies too much on the fact that every event is a text copy as we ignore everything else. it’s going to be a rather painstaking experience refactoring the codebase. the challenge is going to be keeping Squirrel quick and responsive while supporting all of this additional functionality."}, {"post_id": 14387, "ts": "2026-06-23T14:34:01Z", "hours": 2.1467, "text": "even more bugfixes ofcourse critical bugs pop up when im trying to release. the system tray icon wouldnt show up when running the single-file executable on any platform. that is now fixed. plus a couple more things have been done to make Squirrel behave like a good cross platform app, like storing the data in the OS’s appdata directory. there are some more things i would like to do but i think the app is in a releasable state and i’ve wanted to ship it for a while. I’ve set up the GitHub release and all the relevant instructions in the README. might be last devlog before ship #1."}, {"post_id": 11396, "ts": "2026-06-18T17:34:03Z", "hours": 1.2267, "text": "more polish and minor fixes more readme refining, linux support clarity, and installation instructions. also, i completely forgot about the tray icon actually needing an image icon, so until now it was just blank. anyways, we now have an icon. next, we put out releases on github and ship, hopefully. unfortunately we have to wait until tomorrow for linux builds."}, {"post_id": 10100, "ts": "2026-06-16T18:11:51Z", "hours": 1.3953, "text": "readme and polishing preparing to ship, writing docs, recording demos and stuff. there are a couple other things i want to sort out but i might ship in a few days."}, {"post_id": 9339, "ts": "2026-06-15T17:46:59Z", "hours": 2.4394, "text": "Dark theme! just glorious there isn’t a theme toggle button yet, it just goes off of your system’s theme for now. now that the colors are roughly standardized across the ui, tweaking the contrast and palette is a much more pleasant experience."}, {"post_id": 8830, "ts": "2026-06-14T18:02:58Z", "hours": 0.6531, "text": "wip dark theme support i want squirrel to use whatever theme the system is set to. currently it’s forced light mode but dark mode is something i’d be crucified for not adding. unfortunately, I in my infinite wisdom didn’t have the foresight to have consistent colors across even the light theme itself. there’s just random #aaa , #666 , etc colors everywhere where i went with what looked good. so work needs to be done to standardize the colors with css variables. then just modify the variables for dark theme accordingly. yes, i’m aware this is standard practice."}, {"post_id": 8047, "ts": "2026-06-13T12:50:39Z", "hours": 1.6972, "text": "Ticked a couple of items off the todo list: Squirrel now loads the history on launch. doing this was easier than i expected, but it’s a very naive way to do it (literally just send all of the history on launch). we also now have a logo. im no graphic designer by any means so this is the best i could do. shows in the titlebar and when your history is empty. check the project banner for a larger version if you feel like it. i might change the logo in the future, i just wanted an icon. todo pinning items test on linux"}, {"post_id": 7571, "ts": "2026-06-12T17:36:06Z", "hours": 1.2175, "text": "nothing significant. just docs and comments and cleanup. slowly making progress planning wise into loading the history at launch. the idea is to use a custom Tauri IPC Channel for incrementally streaming data to the frontend on app start. channels are supposedly faster for this and are meant for continuous messages like this in comparison to events. from the Tauri docs: Channels are designed to be fast and deliver ordered data. They are used internally for streaming operations such as download progress, child process output and WebSocket messages. i may implement a lazy loading system if i feel like it. i have nothing interesting to show so have a squirrel again"}, {"post_id": 6978, "ts": "2026-06-11T18:27:06Z", "hours": 4.3067, "text": "Item search i’ve wanted to add this for a long time but it needed a lot of refactoring in the frontend so i put it off for later. it is now later. we have instant search. press / or any of the non shortcut keys to start searching. frontend logic has had a big refactor making navigation and other operations more predictable and less wonky. it took a bit of battling with the specifics of Svelte’s each loop and bind:this directive but it was worth it. there is still some cleanup that can be done, the code is not idiomatic by a long shot, but im happy we have a very essential feature complete. changelog: add search fix broken arrow navigation and copy/delete operations applying to wrong entries. make window size a bit bigger by default (might change later) make copy icon turn into a green checkmark so that there is some visual feedback on copying make the database file always save at the executable’s location. todo ! still need to test linux ! load history on launch app icon and branding"}, {"post_id": 6358, "ts": "2026-06-10T18:17:34Z", "hours": 5.3111, "text": "Frontend improvements we now have buttons on the clipboard entries so you can also use the mouse to perform the basic functions like copy, delete, etc. (pins wip). there have also been a bunch of UI improvements and tweaks in general. deleting feels instant. navigation is fixed (for the most part). Backend slight optimization in the pasting operation, plus a couple of fixes and doc comments."}, {"post_id": 5833, "ts": "2026-06-09T19:30:37Z", "hours": 0.4139, "text": "custom scroll bar that is it, enjoy."}, {"post_id": 5013, "ts": "2026-06-08T17:39:05Z", "hours": 2.1789, "text": "UI tweaks as i mentioned before, im in the process of simplifying the UI. i hid the native titlebar and made a custom one. also tweaked the shape of the window to feel more like a clipboard. that is all that’s changed significantly this devlog. development will probably slow down a little bit in the coming days because i have irl stuff to deal with."}, {"post_id": 4379, "ts": "2026-06-07T18:13:01Z", "hours": 4.3942, "text": "more backend there isnt any significant change in the frontend but there’s a ton of backend refactoring and bugfixes. performance should be slightly better now with large copy/pastes. changelog: associate IDs with clipboard events so that we only have to pass IDs between the frontend and backend instead of the whole content. make paste operation more efficient ignore clipboard events caused by Squirrel itself (a bit hacky to achieve this but good enough) Quit button in tray icon menu so Squirrel can actually be closed (there was no way to close it before except killing it) make the shortcut to bring up Squirrel work in almost all situations refactor AppState + some other things more cleanup and comments anyways, attached image is the tentative color palette i might implement. i have no idea how to do this and which colors to use where or if it would even look good so i might just ditch it in the future. we’ll see. todo still have to test on linux and load history on app launch. probably will work on that next."}, {"post_id": 3711, "ts": "2026-06-06T19:20:52Z", "hours": 3.0414, "text": "we got shortcuts we now have Ctrl+Shift+V as the shortcut to bring up Squirrel. (i know it’s used for “Paste as plain text” in some programs and used for “Paste in place” in photoshop but whatever). once up, you can select items from your history using arrow keys. pressing Return pastes the selected item into your last window. we’re having some issues with permissions but i’ll look into it. i’m now slowly simplifying the UI to be geared more towards improving user ergonomics and make it something that is not cluttered and easy to use. apart from this, i’ve cleaned up the code a bit removing stray debug prints and random commented code, it was getting out of hand. will write proper doc comments soon. todo i have to make the app load the user’s past clipboard history on startup lmao i totally forgot i have to start testing on linux, urgently. i feel i should make devlogs more often. even if nothing’s changed in the actual project, detailing plans helps me keep track of things personally. that’s pretty much it, stay tuned. edit: please ignore the VC_UNDEFINED keys in the input overlay in the attached video, it’s Enigo inputs not translating well."}, {"post_id": 2305, "ts": "2026-06-04T18:30:06Z", "hours": 4.1042, "text": "a bunch of backend improvements: store timestamps for copy events more efficient message passing between frontend and backend Clear History functionality system tray (!) (pls ignore the missing icon in the tray, we don’t have an icon for the app yet) slightly better UI on the topic of UI, i’m getting around to deciding a color palette for the app. i will probably work more on the UI for a bit before switching gears to add more functionality (like image support). if i decide i want to ship early, v0.1 will probably go without image support and just get a lot of polish with text only functionality."}, {"post_id": 1590, "ts": "2026-06-03T18:26:51Z", "hours": 3.9078, "text": "frontend improvements! spent some time battling css for this relatively simple UI but it’s atleast somewhat pleasant to look at. will work on either image support or making it the app run in the background next."}, {"post_id": 922, "ts": "2026-06-02T17:41:08Z", "hours": 4.1017, "text": "nothing much has changed visually, but we now have a database to store the user’s clipboard actions. plus some refactoring changes and a bunch of minor improvements here and there. i have nothing to show for it except code so instead have an image of a squirrel"}, {"post_id": 261, "ts": "2026-06-01T13:38:29Z", "hours": 2.5611, "text": "init. figuring out Tauri’s emit/invoke mechanism and capturing clipboard copy events. slow start. we’ll do the color palette and icon and all the frontend pleasantries at a later date."}]...
|
Title: Squirrel by @Koei | Stardance
Devlogs:
ini Title: Squirrel by @Koei | Stardance
Devlogs:
init. figuring out Tauri’s emit/invoke mechanism and capturing clipboard copy events. slow start. we’ll do the color palette and icon and all the frontend pleasantries at a later date.
nothing much has changed visually, but we now have a database to store the user’s clipboard actions. plus some refactoring changes and a bunch of minor improvements here and there. i have nothing to show for it except code so instead have an image of a squirrel
frontend improvements! spent some time battling css for this relatively simple UI but it’s atleast somewhat pleasant to look at. will work on either image support or making it the app run in the background next.
a bunch of backend improvements: store timestamps for copy events more efficient message passing between frontend and backend Clear History functionality system tray (!) (pls ignore the missing icon in the tray, we don’t have an icon for the app yet) slightly better UI on the topic of UI, i’m getting around to deciding a color palette for the app. i will probably work more on the UI for a bit before switching gears to add more functionality (like image support). if i decide i want to ship early, v0.1 will probably go without image support and just get a lot of polish with text only functionality.
we got shortcuts we now have Ctrl+Shift+V as the shortcut to bring up Squirrel. (i know it’s used for “Paste as plain text” in some programs and used for “Paste in place” in photoshop but whatever). once up, you can select items from your history using arrow keys. pressing Return pastes the selected item into your last window. we’re having some issues with permissions but i’ll look into it. i’m now slowly simplifying the UI to be geared more towards improving user ergonomics and make it something that is not cluttered and easy to use. apart from this, i’ve cleaned up the code a bit removing stray debug prints and random commented code, it was getting out of hand. will write proper doc comments soon. todo i have to make the app load the user’s past clipboard history on startup lmao i totally forgot i have to start testing on linux, urgently. i feel i should make devlogs more often. even if nothing’s changed in the actual project, detailing plans helps me keep track of things personally. that’s pretty much it, stay tuned. edit: please ignore the VC_UNDEFINED keys in the input overlay in the attached video, it’s Enigo inputs not translating well.
more backend there isnt any significant change in the frontend but there’s a ton of backend refactoring and bugfixes. performance should be slightly better now with large copy/pastes. changelog: associate IDs with clipboard events so that we only have to pass IDs between the frontend and backend instead of the whole content. make paste operation more efficient ignore clipboard events caused by Squirrel itself (a bit hacky to achieve this but good enough) Quit button in tray icon menu so Squirrel can actually be closed (there was no way to close it before except killing it) make the shortcut to bring up Squirrel work in almost all situations refactor AppState + some other things more cleanup and comments anyways, attached image is the tentative color palette i might implement. i have no idea how to do this and which colors to use where or if it would even look good so i might just ditch it in the future. we’ll see. todo still have to test on linux and load history on app launch. probably will work on that next.
UI tweaks as i mentioned before, im in the process of simplifying the UI. i hid the native titlebar and made a custom one. also tweaked the shape of the window to feel more like a clipboard. that is all that’s changed significantly this devlog. development will probably slow down a little bit in the coming days because i have irl stuff to deal with.
custom scroll bar that is it, enjoy.
Frontend improvements we now have buttons on the clipboard entries so you can also use the mouse to perform the basic functions like copy, delete, etc. (pins wip). there have also been a bunch of UI improvements and tweaks in general. deleting feels instant. navigation is fixed (for the most part). Backend slight optimization in the pasting operation, plus a couple of fixes and doc comments.
Item search i’ve wanted to add this for a long time but it needed a lot of refactoring in the frontend so i put it off for later. it is now later. we have instant search. press / or any of the non shortcut keys to start searching. frontend logic has had a big refactor making navigation and other operations more predictable and less wonky. it took a bit of battling with the specifics of Svelte’s each loop and bind:this directive but it was worth it. there is still some cleanup that can be done, the code is not idiomatic by a long shot, but im happy we have a very essential feature complete. changelog: add search fix broken arrow navigation and copy/delete operations applying to wrong entries. make window size a bit bigger by default (might change later) make copy icon turn into a green checkmark so that there is some visual feedback on copying make the database file always save at the executable’s location. todo ! still need to test linux ! load history on launch app icon and branding
nothing significant. just docs and comments and cleanup. slowly making progress planning wise into loading the history at launch. the idea is to use a custom Tauri IPC Channel for incrementally streaming data to the frontend on app start. channels are supposedly faster for this and are meant for continuous messages like this in comparison to events. from the Tauri docs: Channels are designed to be fast and deliver ordered data. They are used internally for streaming operations such as download progress, child process output and WebSocket messages. i may implement a lazy loading system if i feel like it. i have nothing interesting to show so have a squirrel again
Ticked a couple of items off the todo list: Squirrel now loads the history on launch. doing this was easier than i expected, but it’s a very naive way to do it (literally just send all of the history on launch). we also now have a logo. im no graphic designer by any means so this is the best i could do. shows in the titlebar and when your history is empty. check the project banner for a larger version if you feel like it. i might change the logo in the future, i just wanted an icon. todo pinning items test on linux
wip dark theme support i want squirrel to use whatever theme the system is set to. currently it’s forced light mode but dark mode is something i’d be crucified for not adding. unfortunately, I in my infinite wisdom didn’t have the foresight to have consistent colors across even the light theme itself. there’s just random #aaa , #666 , etc colors everywhere where i went with what looked good. so work needs to be done to standardize the colors with css variables. then just modify the variables for dark theme accordingly. yes, i’m aware this is standard practice.
Dark theme! just glorious there isn’t a theme toggle button yet, it just goes off of your system’s theme for now. now that the colors are roughly standardized across the ui, tweaking the contrast and palette is a much more pleasant experience.
readme and polishing preparing to ship, writing docs, recording demos and stuff. there are a couple other things i want to sort out but i might ship in a few days.
more polish and minor fixes more readme refining, linux support clarity, and installation instructions. also, i completely forgot about the tray icon actually needing an image icon, so until now it was just blank. anyways, we now have an icon. next, we put out releases on github and ship, hopefully. unfortunately we have to wait until tomorrow for linux builds.
even more bugfixes ofcourse critical bugs pop up when im trying to release. the system tray icon wouldnt show up when running the single-file executable on any platform. that is now fixed. plus a couple more things have been done to make Squirrel behave like a good cross platform app, like storing the data in the OS’s appdata directory. there are some more things i would like to do but i think the app is in a releasable state and i’ve wanted to ship it for a while. I’ve set up the GitHub release and all the relevant instructions in the README. might be last devlog before ship #1.
Pins we now have basic entry pinning support. this was a bit less difficult than i thought it was going to be. but now you can pin an item and it always stays at the top of the list (unless you’re searching). anyways, that is one item ticked off the todo list. apart from that, i had to do some minor backend refactoring and reorganizing so that it is easier to build more upon. next? image and/or file copy support. this is one monumental task. i think the way we’ll approach this is by storing the entire file if it’s smaller than, say 5mb, and if it is larger, we just store the path to the file. we dont want to store the user’s 5gb video file they just copied. for images, i think the play is to generate a low quality thumbnail of the image to display in the app. for files, if it is a text file, we can show just the first 5 or so lines with a link to the file, other wise we’ll just give a link. until now, the code i’ve written sadly relies too much on the fact that every event is a text copy as we ignore everything else. it’s going to be a rather painstaking experience refactoring the codebase. the challenge is going to be keeping Squirrel quick and responsive while supporting all of this additional functionality.
Navigation improvements slight refactoring and bugfixes for frontend navigation. the navigation was kinda wonky before this and sometimes wouldn’t highlight the entry that was actually selected in the background. most of this devlog’s work was to make it so that what you see is what you get. also, a touch of color has been added to pinned entries (tentative).
CI dipped my toes into github workflows, messed around, an got check&lint workflows working on pull requests. will make a release workflow some time later. this change however, was only a part of this devlog’s time. Bad decisions catching up turns out, using clipboard_rs might’ve been the subpar choice for interfacing with the system clipboard. while clipboard_rs provides a easy way to listen to clipboard changes and get text from it, fetching raw clipboard data is buggy and inconvenient. when i sat down to work on image support, i was immediately brick-walled by how messy it is to just get raw data first. it would’ve been simple if i was building for just one target os but considering both windows and linux, it’s less than ideal. on top of this, the documentation for the crate is very lackluster. all this to say, i am very much debating migrating my clipboard stuff to using arboard . arboard doesnt provide direct functionality to listen to clipboard changes so i will have to implement that myself. but, it does have first class support for wayland. a very enticing choice, but we will see.
Sadness so i just found out that Tauri’s global shortcut plugin does not yet support Wayland, which is sad to discover this deep into development. but, there is an active PR addressing this issue , which is nice. what this means for Squirrel is that proper Wayland support will unfortunately have to wait until this is merged. the joys of using a not-yet-completely-matured framework i suppose. though it does make me feel a bit guilty for calling Squirrel “cross-platform”. in other news (changelog): Squirrel now has a --silent launch flag that makes it start with the window hidden. useful when the app is set to launch on system startup. Squirrel now makes sure there is only one instance of it running. The shortcut Ctrl+Shift+Del will clear history permanently. (i forgot about clear history functionality in the first ship even though the code for it existed, there just wasnt a button in the frontend to call it)
Closed 1 (one) issue moved the global launch hotkey logic from the frontend to the backend. it didn’t behave well in certain situations, failing to activate and bringing up the Squirrel window. Starting work on images we’re experimenting with images. the current functionality is very much caveman and needs a lot of attention to make it actually usable. i’ve decided to stick with clipboard_rs for now, we’ll see how that pans out.
Version bump and docs bumped the minor version. Squirrel is officially v0.2.0, yippi. plus, updated the README, adding more explanation about the Wayland issue. also showcased the pin feature. i’ll try to whip up a release workflow to add to my CI tomorrow. I’m debating whether i should ship v0.2.0. the only major change from 0.1.0 is the addition of pinning. i might wait until i have image support and ship later, or i might change my mind, im unsure.
Lots of refactoring (apologies for the uneventful devlog attachment, i have nothing interesting to show except just code) to make it a bit more manageable when adding image support, a bunch of refactoring and reorganizing has been done in the backend. like i’ve previously mentioned, the codebase leaned too hard into only supporting text events. this fixes that. today’s changes also make the internal communication a bit more efficient. there are a couple more places where performance can be improved. and we will need every bit of performance we can get when dealing with image data. Changelog (shoutout @Hridya for stardance utils, just discovered this) 5b3f285 refactor: move clipboard structures into separate file b3ab1c8 perf: only get required data from db when copying an item 69dc003 refactor: modify data types to enable addition of image support Release CI (wip) currently writing the Release workflow for Squirrel. i have to figure out how to upload the artifacts to a github release with proper versioning and all that. the strategy is to run the workflow whenever something is pushed to the release branch. that is all for today.
Progress on images we finally have some form of working image support in Squirrel. This required even more sweeping refactoring changes to the codebase, which was a bit painful and im sure the new code isn’t the best quality either and will bite me later, but we’ll deal with it when we deal with it. getting images is a bit slow however, as right now we’re storing the image as base64 encoded PNGs. i plan to use the SQLite blob type to just store the raw bytes and pass that back and forth to improve the performance a bit (maybe some sort of caching as well?). there are also other areas where that are to be improved but i wanted to get a somewhat working prototype as fast as i can. explaining the silence i’ve been distracted by some life stuff, making me neglect my projects a bit. i also got distracted by the ESP32, fun little device. that is where the 9 days went. but, expect me to work semi-regularly again. thanks for reading.
Bunch of things Image Improvements some performance enhancements with images. made the clipboard image data fetching happen in Tauri’s dedicated thread pool, effectively parallelizing the operation. this made image copying a lot faster. image support should be merged into master soon enough. Lazy loading we now have lazy loading for images. image data isn’t loaded until it is scrolled into view. makes startup quick. CI enabled Dependabot updates and optimized the lint workflows for PRs. previously, all of the project was lint+checked on PR when changing anything. now it only checks the part that’s changed (i.e. frontend or backend)
Image branch is merged yay, yippee even. next i need to implement a frontend cache to store the last X entries’ contents, particularly for images. the way it works right now, every time the images are re-rendered (due to being filtered by search, for example), content is fetched from the backend. this ofcourse, is less than ideal. but shouldnt be a lot of trouble to fix.
Basic image cache we now cache the last 32 images, fetching from the backend when required and updating the cache. made the image re-rendering issue instantly better. attached is the demo video i forgot to upload in the second to last devlog showing images in action. Performance images are a difficult thing to handle, especially when dealing with the system clipboard. i’ve made Squirrel as performant as i could to the best of my abilities, which is to say, it’s not the best. it isn’t as rich as i would like it to be, so i might return to this feature to improve it in the future. one restriction i’ve put on images to control some of the chaos is limiting the size to 5 megabytes, meaning any image above 5 megs isn’t registered. i could push that to 10, which is still practically instant. but Squirrel is intended to be a quick clipboard, and not dropbox. so this is my cheaty little escape. maybe i’ll relax the limit in the future if 5mb is really restrictive. Next? i’ll probably bump the minor version and ship (i wouldn’t dare a v1.0 currently). i’d say pinning and image support is enough to warrant a second ship. beyond that though, stands file(s) support, so a lot of decision making on how i want it to work to have a good balance of performance and usefulness. a bit of a lengthy devlog this one, and i appreciate if you read all that. but i wanted to clear up some things for myself and just have a frame of reference where Squirrel stands right now after returning from a development break.
Set for ship release is made, README updated. should be good to go.
Acting on feedback a shipwright recommended i change my banner to include a screenshot of the program. so we now have a shiny new banner that should look good everywhere on the site. this required me to figure out what dimensions the banner is shown at across the site. i’ve attached a rough template for banners. fitting everything inside the marked areas should make sure your banner isn’t cut off anywhere that matters. one reviewer rightfully couldn’t figure out how to quick paste items. this is a miss on my part because i didn’t really have a list of shortcuts anywhere and kind of just mentioned them in passing in the README. that has been rectified by adding a Shortcuts section to the readme.
Rudimentary file support we now have the most basic kind of file support there could be. which is just storing the path to the file. we then provide a link to the file in the frontend, clicking on which reveals the file in your explorer. we also now have tiny little icons on the entries which indicate the entry type. all icons thanks to https://lucide.dev/ files ofcourse, need a bit more work. right now, you cant really do much except revealing in explorer. i will work on adding copy and paste support for files next, as well as maybe improve the overall performance a bit.
Turns out, copy and paste support for files was a one line diff. also, Squirrel is now v0.4.0, yippee. anyways, moving swiftly on. Planning for a v1.0 Squirrel is now in a state where we have most of the major features i wanted it to have: support for essential clipboard data types, pinning and search. however, it is not quite in a v1.0 state. there are a bunch of things i want to add to polish up the program and make it feel sort of “complete”, which is mainly focusing on some basic configuration ability. since sensible defaults are hard to figure out, i’d rather let the user break things instead of being stuck with my arbitrary decisions. thus, i present the current planned feature list for v1: Configuration : enabling basic behavior customization through a config file (TOML most likely) Program exceptions : dont capture clipboard data on certain programs Auto delete/never store : ability to specify a “shelf life” for items, or whether to store them persistently at all. Disable specific types : ability to pick which kind of clipboard events to capture, i.e. only text or text and images, etc. Configurable image size threshold : currently locked to 5mb, this would allow to specify a custom value. (?) Custom data storage format : still torn on this, but there may be performance to be gained by moving to a data store more geared for our purposes. this list ofcourse, might change. implementing these features would make Squirrel much more flexible, and make it v1 worthy.
Configuration (wip) Squirrel now has a configuration file. squirrel.toml is created in the config directory of your OS (i.e. %appdata%/Squirrel on windows and /home/username/.config/Squirrel on linux), finally allowing some amount of customization support. right now, only the types and the max_image_size config options work. types allows you to choose which kind of clipboard items are captured/ignored. max_image_size is self explanatory. attached is the full config file. the remaining options require a bit of work to implement.
devlog attachment obligation: here is me pasting some files i copied a couple minutes ago after i copied stuff on top of that. that out of the way, devlog. Several things app theme is now configurable from config, so you are not stuck with the system theme if you want to change it. cleanup across the backend; comments, TODOs, error handling, and stuff of the sort. performance enhancement in the clipboard event emitter loop. bugfix in the same loop where the thread panicked if you copied something while the app was launching. merged the config branch. the remaining config options would be better to implement in their own branches. dependabot updates
Ignore programs you can specify programs in which Squirrel should not listen to clipboard events. this is useful when you’re working in a program wherein you need to use copy and paste a bunch. ignoring that program would keep your Squirrel history clean. also useful to ignore a program that you regularly copy secrets from. example of notepad being ignored:
(i genuinely have no idea what to show in the devlog attachment, nothing’s changed visually. so have this stupid ass screenshot.) Massive refactor, breaking changes now that i’ve given myself the liberty to rethink and redesign Squirrel’s data models and storage in a breaking fashion for v1, we have managed to make a good amount of improvements across the board. database schema has been modified to better suit current needs and make it possible to implement the features I desire for v1. it has been a very satisfying refactor. What’s new: use UNIX microsecond timestamp for event ids instead of relying on sqlite autoincrement. this allows us to immediately send a captured event to the frontend without having to await a db write to obtain the event id. this also eliminates the timestamp column for events since the id is also the timestamp. a dedicated BLOB column for image entries to store raw image bytes instead of b64 encoded strings. this makes images weigh about ~33% lighter. decent perf boost. new expires_at column to store when an entry expires. pinned entries have an expiry of NULL . provides the base to actually implement expiring entries. get rid of ClipboardEventNotice since we no longer do the notify frontend -> write to db -> send data to frontend dance. it is now simply send whole event to frontend -> write to db . we enjoy simplifications. (!) as it stands now, old data (if it exists) would immediately be wiped when launching Squirrel v1. i could write some migration code but we’ll see. maybe clipboard data isn’t important enough to bother with migration. Next: actually implement entry expiration: should be trivial, just delete expired entries on launch. ephemeral/persistent toggle: this one is a bit tricky, and will involve some in memory database shenanigans. more details in the devlog when i implement this.
Item expiry and pin-preservation expired items are now automatically deleted on program startup. an entry is considered expired when the current time is more than its expires_at value. when pinned, the expires_at attribute is nulled, meaning this entry will never expire. the “Clear all” shortcut Ctrl+Shift+Del now respects pinned entries. it clears everything but leaves pinned entries untouched. Next the ephemeral db shenanigans. also, i have decided that Squirrel needs a settings panel in the frontend for easier config modification. that may or may not happen but it is tempting to do it.
History persistence configuration now works. setting it to false means history is not retained between sessions. comes with true as default. pinned entries always persist. attachment shows the behavior when persistence is off. Implementation i ended up deciding not to do the in memory database method for this since it was a bit too much added complexity which could be avoided by just adding an additional is_persistent column to the db. im not the happiest about how i’ve implemented this right now but im willing to take that hit right now if it means i dont have to deal with databases. Next all of the config options are now implemented. we are very close to v1.0. expect progress to be rather slow from here on out. i’ve had to divert my attention towards other things and haven’t been able to spend a lot of time working on my projects. maybe i will work on a settings panel. depends on how much work it requires. it’s a maybe. i may just ship it as it stands right now.
v1.0.0 It’s official. Squirrel is now v1. devlog time is adding logging, updating readme, fixing some small tidbits and polishing up some areas of the app. Squirrel now prints pretty logs to console when running in development mode and writes logs to a file if running in release. Project status i realistically can not get a GUI settings panel done due to me needing to divert my attention to more important life stuff. this right here is probably going to be the extent of work done on Squirrel in stardance. i definitely do plan on working on this in the long term. for example, im not entirely happy and satisfied with the current UI, and global hotkey still does not work on wayland. but right now, more pressing issues are at hand and i cannot give it my all on this project. that said, i do believe that Squirrel is in a very usable 1.0 state, which was my goal. i might push minor updates if the reviews call for fixes/improvements, but definitely no major features. thanks for reading if you made it here.
Ships:
v0.1.0 Squirrel is a clipboard manager that is meant to be simple and intuitive. It remembers all the text you copy allowing you to paste whatever into wherever. You can also quickly search through your history. Squirrel is meant to be cross-platform, but for this release, Linux support on Wayland is very iffy (X11 is fine for the most part). I would highly recommend using Windows for testing this ship, sorry for the inconvenience. Expect potentially better support next ship.
v0.3.0 Squirrel is a clipboard manager that is meant to be simple and intuitive. 2 new features in this version, namely pinning and image support. There are performance improvements as well as slight visual tweaks. Read the README for more info.
v1.0.0 Squirrel is a clipboard manager for Windows and X11 Linux that is meant to be simple and intuitive. This major release overhauls the data storage schema to be more efficient, faster, and reliable. There are significant performance improvements. This release also adds configurability to Squirrel, allowing basic but much needed customization, and polishes up the overall app. Check the README for more information....
|
1792835603.7713623
|
1792922003.7713623
|
|
928
|
Ian Green's Portfolio Site by @academanic | St Ian Green's Portfolio Site by @academanic | Stardance...
|
academanic
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Ian Green's Portfolio Site by @academan Title: Ian Green's Portfolio Site by @academanic | Stardance...
|
1792723806.0647194
|
1793328606.0647194
|
|
929
|
My awesome macropad! by @IKE | Stardance
|
IKE
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @IKE | Stardance
|
1792637547.9298494
|
1793242347.9298494
|
|
930
|
LayerLab by @Shreerang | Stardance
|
Shreerang
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: LayerLab by @Shreerang | Stardance
|
1792928974.0925229
|
1793792974.0925229
|
|
931
|
RISC-V 32bit CPU by @captaintriton10 | Stardance
|
captaintriton10
|
1
|
17.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-13T20:41:40Z", "hours": 17.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "This was my second attempt at making a working RISC-V CPU, I’m really happy with where the project is currently. The most difficult part so far has been trying to debug it when it isn’t working, but I’ve managed to get assembly to run on it with video output, and also keyboard input. Next, I think I want to work on adding more extensions to the base ISA and writing more complex programs for it.", "repo": "https://github.com/CaptainTriton10/risc-v_v2", "demo": ""}]...
|
[{"post_id": 8201, "ts": "2026 [{"post_id": 8201, "ts": "2026-06-13T17:18:13Z", "hours": 1.6106, "text": "Worked some more on other typical features of a VGA text mode, such as highlighted text and blinking."}, {"post_id": 7699, "ts": "2026-06-12T21:05:48Z", "hours": 5.1781, "text": "As you can see below, I got keyboard input to work, so now I can write programs that use keyboard input. New features: Character colours UART input (keyboard input) It’s pretty cool that I can also write the devlog on the CPU with the custom assembly code I wrote!"}, {"post_id": 5201, "ts": "2026-06-08T21:59:22Z", "hours": 1.5792, "text": "I finally fixed the branch logic, and proved that it works with this simple counter that uses the conditional BGE (branch if greater than or equal) instruction."}, {"post_id": 4881, "ts": "2026-06-08T13:22:18Z", "hours": 5.6975, "text": "Currently working on debugging conditional branch instructions, as the wrong branch address is being targetted. Fortunately, I managed to fix the JAL and JALR jump instructions."}, {"post_id": 2053, "ts": "2026-06-04T10:47:06Z", "hours": 2.4369, "text": "This is a project I’ve been working on already a fair bit, trying to make a half-decent RISC-V CPU for use on the icepi-zero FPGA board (that I got from the previous Flavourtown event :D). This is a testbench I’m running, currently trying to debug jump and branch instructions not working. My next step is adding keyboard input through the UART protocol (universal asynchronous receiver-transmitter)"}]...
|
Title: RISC-V 32bit CPU by @captaintriton10 | Star Title: RISC-V 32bit CPU by @captaintriton10 | Stardance
Devlogs:
This is a project I’ve been working on already a fair bit, trying to make a half-decent RISC-V CPU for use on the icepi-zero FPGA board (that I got from the previous Flavourtown event :D). This is a testbench I’m running, currently trying to debug jump and branch instructions not working. My next step is adding keyboard input through the UART protocol (universal asynchronous receiver-transmitter)
Currently working on debugging conditional branch instructions, as the wrong branch address is being targetted. Fortunately, I managed to fix the JAL and JALR jump instructions.
I finally fixed the branch logic, and proved that it works with this simple counter that uses the conditional BGE (branch if greater than or equal) instruction.
As you can see below, I got keyboard input to work, so now I can write programs that use keyboard input. New features: Character colours UART input (keyboard input) It’s pretty cool that I can also write the devlog on the CPU with the custom assembly code I wrote!
Worked some more on other typical features of a VGA text mode, such as highlighted text and blinking.
Ships:
This was my second attempt at making a working RISC-V CPU, I’m really happy with where the project is currently. The most difficult part so far has been trying to debug it when it isn’t working, but I’ve managed to get assembly to run on it with video output, and also keyboard input. Next, I think I want to work on adding more extensions to the base ISA and writing more complex programs for it....
|
1792849809.0681984
|
1792936209.0681984
|
|
932
|
Fractured by @Accursed_Drifter | Stardance
|
Accursed_Drifter
|
0
|
17.61
|
0
|
[]
|
[{"post_id": 32203, "ts": "202 [{"post_id": 32203, "ts": "2026-07-21T06:54:12Z", "hours": 0.5175, "text": "Devlog #5 It’s been a bit since my last devlog but during that time I’ve been creating a bunch of the lore for my game and I’ve also recolored / redesigned a bunch of my assets (although there is still more to go). Currently I have a base for how I want my character to look like, I did originally want to have a very detailed character but after recoloring him and it took over 4 days to do just that I’ve come to the realization that if I want to have this as a playable demo before stardance ends I’m prolly gonna have to try my best with the free resources I have access to. (I still don’t know how I feel with how the player looks against the tiles) That being said, I think next I’m gonna make a few actual levels so that I can start working on integrating lore into the game and give it life."}, {"post_id": 29336, "ts": "2026-07-16T06:48:43Z", "hours": 4.3933, "text": "Devlog #4 Since my last devlog I’ve added a few new features that I think can be really useful when I end up adding lore and purpose to everything later The first thing I worked on was changing around my animations for right now as I found an editable sprite template on itch.io that i wanted to use so that making an actual character later may be easier. The next thing i worked on was having an attack combo to give the player more than just one attack. the final feature i worked on was making levels. This was by far the hardest thing to code into my game and it isn’t even close. It took multiple tutorial videos and many hours to get all of the code correct and actually working. Now that it’s done though, i can begin experimenting with different free tile sheets to find what type of style would fit my game the best. Next i think i’m going to attempt to code what i believe will be an even harder feature than levels, save states. However if it goes how i think its gonna go i may just end up working on making a main menu system (aka a pause button that works)."}, {"post_id": 28655, "ts": "2026-07-15T01:17:54Z", "hours": 2.2544, "text": "Devlog #3 It’s been a while since my last devlog as i took a break from coding for a few days and writing the code for the enemy ai took a while. So far i’ve finished giving the enemy a basic attack and giving it the abaility to agro the player. Once the player gets close enough the enemy will try to chase then and once they get even closer the attack sequence begins. Next i’m going to work on polishing the current code I have and work on more advanced things for the player like giving him more moves."}, {"post_id": 25155, "ts": "2026-07-09T06:03:34Z", "hours": 3.0983, "text": "Devlog #2 Today was mostly spent redoing how I had the animations structured in order to add some new ones like attacks. After I got finished with the rabbit hole that is animation trees, I finally got a basic light attack finished and i was able to make a test enemy to work on the code for taking damage from the players attacks. The player can now attack anything with a specific function and deal damage to it. This test enemy in particular doesn’t do anything besides takes hits and perish Tomorrow, I think I am going to work on making the enemy have its own attacks and work on adding agro to the enemy. As this project grows I am starting to get a feel on how I want this to be and can hopefully start working on assets soon."}, {"post_id": 24563, "ts": "2026-07-08T07:09:29Z", "hours": 7.3425, "text": "Devlog #1 I am making a godot game in order to learn GS script Currently i worked on making the base for some features like; movement, double jump, wall slide + jump, basic enemies, and a npc dialogue system. Next I need to go over all the code i’ve written in order to polish some bugs and make it neater. The current assets are mostly free assets from itch.io but once i reach a certain point im gonna make whole new sprites and tile sheets."}]...
|
Title: Fractured by @Accursed_Drifter | Stardance
Title: Fractured by @Accursed_Drifter | Stardance
Devlogs:
Devlog #1 I am making a godot game in order to learn GS script Currently i worked on making the base for some features like; movement, double jump, wall slide + jump, basic enemies, and a npc dialogue system. Next I need to go over all the code i’ve written in order to polish some bugs and make it neater. The current assets are mostly free assets from itch.io but once i reach a certain point im gonna make whole new sprites and tile sheets.
Devlog #2 Today was mostly spent redoing how I had the animations structured in order to add some new ones like attacks. After I got finished with the rabbit hole that is animation trees, I finally got a basic light attack finished and i was able to make a test enemy to work on the code for taking damage from the players attacks. The player can now attack anything with a specific function and deal damage to it. This test enemy in particular doesn’t do anything besides takes hits and perish Tomorrow, I think I am going to work on making the enemy have its own attacks and work on adding agro to the enemy. As this project grows I am starting to get a feel on how I want this to be and can hopefully start working on assets soon.
Devlog #3 It’s been a while since my last devlog as i took a break from coding for a few days and writing the code for the enemy ai took a while. So far i’ve finished giving the enemy a basic attack and giving it the abaility to agro the player. Once the player gets close enough the enemy will try to chase then and once they get even closer the attack sequence begins. Next i’m going to work on polishing the current code I have and work on more advanced things for the player like giving him more moves.
Devlog #4 Since my last devlog I’ve added a few new features that I think can be really useful when I end up adding lore and purpose to everything later The first thing I worked on was changing around my animations for right now as I found an editable sprite template on itch.io that i wanted to use so that making an actual character later may be easier. The next thing i worked on was having an attack combo to give the player more than just one attack. the final feature i worked on was making levels. This was by far the hardest thing to code into my game and it isn’t even close. It took multiple tutorial videos and many hours to get all of the code correct and actually working. Now that it’s done though, i can begin experimenting with different free tile sheets to find what type of style would fit my game the best. Next i think i’m going to attempt to code what i believe will be an even harder feature than levels, save states. However if it goes how i think its gonna go i may just end up working on making a main menu system (aka a pause button that works).
Devlog #5 It’s been a bit since my last devlog but during that time I’ve been creating a bunch of the lore for my game and I’ve also recolored / redesigned a bunch of my assets (although there is still more to go). Currently I have a base for how I want my character to look like, I did originally want to have a very detailed character but after recoloring him and it took over 4 days to do just that I’ve come to the realization that if I want to have this as a playable demo before stardance ends I’m prolly gonna have to try my best with the free resources I have access to. (I still don’t know how I feel with how the player looks against the tiles) That being said, I think next I’m gonna make a few actual levels so that I can start working on integrating lore into the game and give it life....
|
1792594307.0972314
|
1793199107.0972314
|
|
933
|
My awesome macropad! by @ReanickaB | Stardance
|
ReanickaB
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @ReanickaB | Starda Title: My awesome macropad! by @ReanickaB | Stardance...
|
1792788662.2924695
|
1793393462.2924695
|
|
934
|
My awesome macropad! by @Harry_wct | Stardance
|
Harry_wct
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Harry_wct | Starda Title: My awesome macropad! by @Harry_wct | Stardance...
|
1792514948.9929707
|
1793119748.9929707
|
|
935
|
Map.fm by @ama | Stardance
|
ama
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Map.fm by @ama | Stardance
|
1792579722.552691
|
1793184522.552691
|
|
936
|
Ice Cream by @vessel | Stardance
|
vessel
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Ice Cream by @vessel | Stardance
|
1792748942.1961145
|
1793353742.1961145
|
|
937
|
My first slack bot! by @kanchankumari1992214 | Sta My first slack bot! by @kanchankumari1992214 | Stardance...
|
kanchankumari1992214
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @kanchankumari199221 Title: My first slack bot! by @kanchankumari1992214 | Stardance...
|
1792551166.7537868
|
1793155966.7537868
|
|
938
|
My awesome macropad! by @kanchankumari1992214 | St My awesome macropad! by @kanchankumari1992214 | Stardance...
|
kanchankumari1992214
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @kanchankumari19922 Title: My awesome macropad! by @kanchankumari1992214 | Stardance...
|
1792547485.432366
|
1793152285.432366
|
|
939
|
LUNAR-HAL by @INiNiDS | Stardance
|
INiNiDS
|
1
|
78.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-29T18:18:07Z", "hours": 78.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Finally shipping this! It honestly took forever and I burned out twice along the way, but I pushed through to get it over the finish line. Try out the live demo or grab the local build. Heads up: the web demo might feel super sluggish since the models are running on Heroku, so expect some delay. Also, all demo sessions share the same persistent worlds! Have Fun!", "repo": "https://github.com/ininids/lunar-hal", "demo": "https://lnhal.ininids.in.rs"}]...
|
[{"post_id": 75310, "ts": "202 [{"post_id": 75310, "ts": "2026-09-29T18:16:50Z", "hours": 5.1756, "text": "Alright, final devlog! Went all-in on bug squashing for this one—crushed a ton of issues, finally got CI completely green and stable, cleared out all the CodeQL alerts, and pushed the demo build. So yeah… I’m officially shipping now!"}, {"post_id": 68044, "ts": "2026-09-14T12:49:45Z", "hours": 12.1378, "text": "DevLog #9: Checkpoint Hardening & Stage 5 GNN Kinematics Convergence * This session was focused on a deep technical milestone: diagnosing a critical engine staging bug in LUNAR-HAL and driving the Stellar GNN-kinematics pipeline through the completion of Stage 5. 1. 🛠️ Staging Architecture & Atomic Checkpoint RCA (Rust) Diagnosed and resolved a critical issue in the --resume workflow where staging logic triggered a self-copy ( src == dst ), truncating output checkpoint weights upon restart. Implemented robust canonical path checking ( std::fs: :canonicalize ) to ensure fully atomic weight persistence across interruption signals ( SIGINT / SIGTERM ). Hardened checkpoint state serialization, eliminating filesystem race conditions during runtime hot-reloads. 2. Stage 5: GNN-Kinematics Training Executed the 200-epoch training run for the galactic velocity prediction model ($v_x, v_y, v_z$ derived from positions + photometry). Validated host telemetry: stable VRAM footprint on local NVIDIA GeForce RTX 5070 (~3.1 GB / 12 GB allocated) with optimal throughput (~30s / epoch). 3. Loss & Convergence Verification Train Loss: Decreased to ~0.7660 . Validation Loss: Reached a clean, stable quasi-stationary plateau at ~0.7694 . Physics Constraint: Invariant equilibrium maintained throughout ( phys_loss ≈ 0.7700 ), demonstrating high generalization without overfitting."}, {"post_id": 45625, "ts": "2026-08-12T07:29:27Z", "hours": 3.5756, "text": "* 🚀 DevLog #8: The Great Pivot — From Game to Technical Stellar Platform * The mission has changed. Following the deployment of the WebOS in DevLog #7, we realized that the “game” mechanics were holding back the true potential of the engine. This update marks our transition from a simulation with combat elements to a high-fidelity technical platform for stellar generation, research, and visualization. We have officially executed the transition plan, gutting the “game” and hardening the “platform.” The Great Purge: lunar-stellar-core The era of lunar-game-backend is over. We have performed a git mv on the heart of the engine to establish a strict architectural boundary. Logic Extraction: We have completely removed all traces of Enemies, Projectiles, HP, Attacks, and the “Attention Map.” The simulation no longer cares if you are “watching” a star; it only cares about the physics. The Core: The new lunar-stellar-core crate is now framework-agnostic. It handles only the technical state: camera math, sector caching, and the pipeline results. Terminology Shift: “World” is now “StarScene.” It’s no longer a level; it’s a coordinate-stable dataset. Unified Multi-Platform Deployment We’ve consolidated our frontend logic. Instead of separate builds, we now have a single Managed Frontend Service with a unified builder. Target Switching: Through the lns utility, we can now hot-swap between web , desktop , and android targets. Android Integration: The platform now supports Android NDK/SDK. We’ve replaced mouse-only logic with Pointer Events , enabling touch-based pan/zoom/selection. Runtime Config: The backend now dynamically injects the correct URL (handling the 10.0.2.2 emulator trap) based on the active platform. Sandbox 2.0: The Admin Overlay The Sandbox is no longer a separate copy of the simulation. It has evolved into a Meta-Management Shell for the real frontend. The Iframe Bridge: The Sandbox now embeds the live lunar-frontend via an iframe. Communication Protocol: We implemented a versioned postMessage protocol in lunar-structures . The Sandbox sends Admin Commands (CreateStar, SetCamera) and receives Scene Events (StarSelected). Permanent SIREN Gallery & Drag-and-Drop We’ve moved from “latest renders” to a persistent filesystem-based catalog . Atomic Persistence: Stars created via AI or manual tools are now saved as GalleryStar DTOs. Each star gets its own directory with metadata, SIREN textures, and thumbnails. True Drag-and-Drop: We’ve implemented a custom drag-session in the WebOS. You can now drag a star from the Gallery into the Sandbox to insert it into the live scene, and vice versa. Found Issues The transition hasn’t been without its casualties. Two “boss-level” bugs have appeared during the implementation of the new WebOS logic: Sandbox Handshake & OS Crash: Currently, the Sandbox is failing to “see” the Frontend service through the iframe bridge. Even worse, attempting to initialize the connection often results in a total OS-level hang , crashing the Testbench entirely. We are currently investigating if this is a circular dependency in the backend or a massive memory leak during the handshake. The “Minimize” Trap: While we implemented WindowLifecycle to keep applications alive in the background using display: none , we hit a critical logic error. Once an app is minimized, the “un-minimize” (maximize) function fails to trigger . The app remains in a state of digital limbo, perfectly preserved but completely inaccessible."}, {"post_id": 41159, "ts": "2026-08-05T06:03:25Z", "hours": 3.4289, "text": "DevLog #7: WebOS Evolution, The Black Room, and “lns” Orchestration This update marks a fundamental shift in how we interact with the simulation ecosystem. We have moved away from static dashboards to a fully dynamic WebOS environment within lunar-testbench , alongside a complete overhaul of our launching utility. Lunar-Testbench: The WebOS Overhaul The Testbench has been reimagined as a “Black Room” —a dark, immersive workspace where everything begins with three spotlights. The Spotlight Mechanic The interface features three dormant flashlights. Service Ignition: Clicking a spotlight “turns it on” and launches its corresponding backend service. Dynamic App Injection: Once a service is active, the specific applications depending on that service manifest below the spotlight. The Sandbox: Our most complex tool, the Sandbox , now requires all three services to be active simultaneously, setting the stage for deep-system integration in future updates. The Dock To manage the chaos of multiple windows, we’ve implemented a Bottom Dock . Every running application is pinned here, allowing for seamless switching between training, validation, and live simulation environments. Orchestration: From “lunar-start” to “lns” The way we boot the engine has been streamlined. We’ve stripped the heavy lifting out of the primary entry point to create a more modular startup flow. lns Utility: lunar-start has been evolved into lns —a lightweight micro-utility. Its sole purpose is to initialize the Testbench and trigger the backend. lunar-start-backend: This is a new, dedicated service that acts as the primary launcher. It monitors and manages the lifecycle of all other applications within the suite, ensuring that when you click a service in the UI, the backend is ready to deploy it."}, {"post_id": 31372, "ts": "2026-07-19T18:15:40Z", "hours": 8.1406, "text": "🚀 DevLog #6: Hyper-Optimization, Core Threat Integration, and New Swarm Archetypes ⚙️ Optimization: The Fight for Nanoseconds With the transition to a full 3D environment and manual entity manipulation, the load on the CPU and memory bus grew exponentially. So we tried to optimize as much as possible. 👾 Integration: Enemies in the Core Loop Previously, hostile entities existed only as isolated test units (testbench). Now, enemy fleets are officially hardcoded into the base simulation loop. Autonomous Background AI: Enemy behavior is no longer bound to the player’s viewport. Strategic fleets live their own lives in the background—conquering systems and harvesting resources—even if you are editing a galaxy millions of light-years away. Dynamic Pathfinding: The toughest challenge was stabilizing AI during manual manipulation. If you grab a planet and toss it in front of an enemy dreadnought, the pathfinding algorithm instantly recalculates a safe bypass vector based on the newly altered gravitational signature of that sector. 🛸 New Threat Archetypes: The Utility-Driven AI Each enemy now operates on a Utility AI system, calculating its next move based on distance, health ratios, and—most importantly—the Player’s Attention . We have categorized the hostile forces into six distinct tactical archetypes: Archetype Role Logic Highlight The Tank Heavy Juggernaut Berserk Logic: Its utility increases as its health drops. It becomes more aggressive the harder you try to kill it. The Thief Rapid Raider Attention-Aware: Only strikes stars when the player is looking away ( t_neglect > 15.0 ). High speed (20.0) allows for quick hit-and-run ops. The Invisible Stealth Saboteur Adaptive Camouflage: Maintains $0.05$ visibility. Only reveals itself when the player’s cursor “scans” over it or during brief power-grid flickers. The Scavenger Opportunistic Parasite Pack Mentality: Heavily prioritizes stars that are already under attack by other units to “steal” the resources. The Backstabber Chaos Agent Infighting: If it detects a fellow enemy with $<35 % $ HP, it will betray its own kind to secure the kill for itself. The Coward Skittish Scout Self-Preservation: Immediately generates an escape vector if the player’s “God-Hand” (cursor) gets too close or a Tank enters its vicinity. 🧠 The “Attention Map” Integration The most advanced part of this integration is how these entities interact with the Lunar-Frontend . We don’t just track positions; we track the player’s focus: d_mouse Factor: Enemies calculate their distance to your cursor. Thieves and Cowards use this to decide when to flee or stay in the shadows. t_neglect Metric: The simulation tracks how long it’s been since you last interacted with a specific star. The longer a sector is neglected, the higher the “utility” for an invasion force to move in. ⚔️ Combat Mechanics: Physical Projectiles vs. Direct Damage To keep the simulation performant while maintaining visual fidelity: Star Assaults: Enemies fire physical Projectile entities. Each has its own speed, radius, and damage value, allowing players to potentially intercept them or warp them with gravitational anomalies. Internal Infighting: When enemies like the Backstabber turn on their allies, the damage is processed via an optimized EnemyDamage buffer, bypassing heavy projectile physics for internal “swarm” calculations. Note: ISP issues and local routing to the Hack Club site still make uploading updates feel like sending signals through a dense asteroid belt."}, {"post_id": 12966, "ts": "2026-06-21T06:54:53Z", "hours": 18.7053, "text": "DevLog #5: God-Mode Editor, Crate Separation, and Stealth Features Following the development of “Mission Control,” the project has transitioned into a full 3D environment. The cosmos is no longer just being generated; it can now be manipulated in real-time. Project “Lunar-Hal”: God-Mode Editor The new 3D editor allows for direct manipulation of the simulation rather than just monitoring metrics through the TestBench. Free-Fly Mode: A fully functional in-engine 3D editor. Users can toggle Creator Mode to navigate through stellar clusters at high speeds. Real-Time Manipulation: Selecting a star allows for immediate overrides of mass, spectral class, and luminosity. The SIREN engine recalculates astrophysics on the fly, updating the frontend visuals without performance drops. Architecture: The Great Crate Separation To manage codebase complexity, the backend has undergone a significant architectural refactor. All core gameplay logic has been isolated into a dedicated, independent Rust crate. Modular Design: Rendering overhead and editor scaffolding are now separated from pure game rules, physics, and state machines. Improved Compilation: Logic changes no longer require recompiling the entire project. Crates now compile in isolation, allowing for faster iteration and cleaner incremental builds. Inventory System and Stealth Mechanics Work has begun on a functional inventory system designed to hold “Creator Tools.” This system moves beyond traditional item management into world manipulation. Drag-and-Drop Reality: Mechanics are being implemented to allow users to grab celestial bodies directly from the viewport to rearrange solar systems manually. Entity Interaction: These telekinetic mechanics are also being tested on combat entities. This allows for manual interaction with hostile fleets, such as testing physics logic by moving units into gravitational anomalies like black hole event horizons. Lunar-Frontend: Enhanced UI The UI has been updated to accommodate the new editor and inventory capabilities: Creator Widgets: The modular sidebar now includes inspection panels for editor controls and inventory management. Optimized Streaming: The frontend provides a seamless bridge between TestBench metrics and the heavy 3D viewport, maintaining high performance during active manipulation. Roadmap The next phase of development will focus on: Running heavy simulations of billions of stars in background threads while maintaining editor stability. Stabilizing enemy pathfinding during manual entity manipulation. Preparing the architecture for multiplayer synchronization. Note: DevLog updates may be sporadic due to local ISP and network routing issues affecting access to the Hack Club site. Space logistics are complex, but terrestrial routing remains a significant challenge."}, {"post_id": 7982, "ts": "2026-06-13T09:54:00Z", "hours": 10.8433, "text": "🚀 DevLog #4: The God Mode Dashboard & Stellar Genesis! If Day 3 was about plugging the matrix straight into the engine’s spine, today we built the ultimate command center around it. No more chaos, no more manual config-wrangling via terminal. We just deployed a full-scale infrastructure for total cosmic control! Here is the tactical breakdown of what just dropped in the engineering bay: ⚙️ Project “TestBench”: Total Control & Validation We got tired of guessing what’s actually happening inside our AI’s digital brains, so we built TestBench—the ultimate proving ground for complete testing, training, and validation of every single AI model in the project. Backend Fusion: The whole thing is hardwired straight into our reactive Rust backend. God-Tier UX: Now, benchmarking a dataset, checking loss curves, validating weights, or fine-tuning a model is a matter of a few clicks without ever leaving the ecosystem. Real-time telemetry monitoring. Honestly? It’s clean, it’s seamless, and it just works. 🌟 Meet SIREN: The Star Architect Our AI fleet just got a massive reinforcement. Say hello to our newest model—SIREN. Her sole, monumental objective is the procedural generation of the stars themselves. No more random glowing spheres. SIREN calculates physics, luminosity, spectral classes, and spawns unique, structured astrophysical objects. The cosmos isn’t just procedural anymore; it’s beautifully complex and scientifically backed. 🎛️ Lunar-Frontend: The Creator’s Control Panel A cosmic backend deserves a killer visual interface. We gave lunar-frontend a massive upgrade to make managing this madness an absolute breeze: The Sidebar: We coded a modular, highly responsive sidebar. All your tools, model toggles, and data streams are now neatly organized and right at your fingertips. Next Stop: Unleashing SIREN onto the global map, syncing its generation directly with TestBench metrics, and forcing the frontend to smoothly render billions of new star systems without dropping a single frame! 🚀"}, {"post_id": 4775, "ts": "2026-06-08T08:22:17Z", "hours": 9.8683, "text": "🚀 DevLog #3: The Neural Awakening & Backend Fusion! 🪐 Day 2 was chaos, but Day 3? We just plugged the matrix straight into the spine of the engine! 🧠✨ Remember that “confused toaster” from the last devlog? Yeah, well, it just evolved into a full-blown stellar intellect. The pipeline is locked, loaded, and absolutely cooking. Here is the tactical breakdown of what just dropped in the engineering bay: 🌌 The Big Brain Upgrade (Model & Data): We didn’t just tweak the model; we completely rebuilt its reality. We scraped, cleaned, and injected a massive new dataset, pushing our local parameter model to the absolute limit. No more hallucinating dead stars — lnai now actually understands the cosmic data it’s processing. 🔗 The Great Backend Fusion: The neural net is officially out of the sandbox and merged with the core Rust backend! We wired the prediction pipelines directly into our engine architecture. It’s fast, it’s memory-safe, and it operates with zero friction. Data is flowing from the neural layers to the backend loops in real-time. 🏎️ Zero Meltdown, Pure Performance: Training and running local models usually turns your rig into a literal space heater, but we optimized the living hell out of the inference pipelines. The memory footprint is clean, the tokens are flying, and your GPU can actually breathe while rendering the cosmos. The foundation is solid, the telemetry is clean, and the local universe finally has a brain that doesn’t just work — it thinks . Next stop: weaponizing this intelligence for procedural generation and forcing that flight physics engine to respect the laws of space! 🛰️🔥"}, {"post_id": 1972, "ts": "2026-06-04T07:13:17Z", "hours": 2.9592, "text": "🚀 DevLog #2: Neural Overdrive & Brainstorming LUNAR-AI! 🪐 Day 1 is in the books, and we are officially cooking! We’re pushing the boundaries of our infinite, local-first universe, and things are getting wild in the engineering bay. Here is the lowdown on what just dropped: 🧠 Project LUNAR-AI (lnai) is ALIVE: We officially laid down the first lines of code for our core AI driver! The mission? Giving your local universe a brain. No external API calls, no corporate clouds—just raw, local intelligence. 📉 Reality Check (The Results): Okay, look… right now, the results are, let’s say, highly questionable . It’s giving “confused toaster” more than “galactic supercomputer,” but hey, Rome wasn’t built in a day, and an infinite universe needs a little chaos first. 🛠️ Absolute Grind Mode: The output might be mid right now, but the workflow is at an all-time high. We are working 25/7, refactoring the neural pipelines, and optimizing the backend to make sure this local LLM integration doesn’t melt your PC. The brain is wired, the bugs are being hunted, and the grind never stops. Next stop: making lnai actually smart and finally getting that flight physics engine to behave! 🛰️✨"}, {"post_id": 717, "ts": "2026-06-02T09:35:55Z", "hours": 3.0953, "text": "🚀 DevLog #1: Ignition & Cosmic Foundations for LUNAR-HAL! 🪐 Day 0 is officially complete. We are building an infinite, AI-driven space sandbox powered completely by your local hardware, and the base is locked down: 🌌 Mission Control: Prepared the repository, set up community standards, and went full open-source under the AGPL v3 license to keep our local engine free forever. 💻 Frontend Setup: Fired up the project using Rust + Dioxus! Built the core architecture and launched the first three foundational viewports: Home, About, and Contact. 🛠️ The Manifesto: Designed a killer glassmorphic UI layout and integrated our “Broke-Tech” framework—proudly rendering procedural worlds directly on your GPU. Zero server costs, zero latency, infinite universe. Next stop: implementing the flight physics and interactive star canvas! 🛰️✨"}]...
|
Title: LUNAR-HAL by @INiNiDS | Stardance
Devlogs: Title: LUNAR-HAL by @INiNiDS | Stardance
Devlogs:
🚀 DevLog #1: Ignition & Cosmic Foundations for LUNAR-HAL! 🪐 Day 0 is officially complete. We are building an infinite, AI-driven space sandbox powered completely by your local hardware, and the base is locked down: 🌌 Mission Control: Prepared the repository, set up community standards, and went full open-source under the AGPL v3 license to keep our local engine free forever. 💻 Frontend Setup: Fired up the project using Rust + Dioxus! Built the core architecture and launched the first three foundational viewports: Home, About, and Contact. 🛠️ The Manifesto: Designed a killer glassmorphic UI layout and integrated our “Broke-Tech” framework—proudly rendering procedural worlds directly on your GPU. Zero server costs, zero latency, infinite universe. Next stop: implementing the flight physics and interactive star canvas! 🛰️✨
🚀 DevLog #2: Neural Overdrive & Brainstorming LUNAR-AI! 🪐 Day 1 is in the books, and we are officially cooking! We’re pushing the boundaries of our infinite, local-first universe, and things are getting wild in the engineering bay. Here is the lowdown on what just dropped: 🧠 Project LUNAR-AI (lnai) is ALIVE: We officially laid down the first lines of code for our core AI driver! The mission? Giving your local universe a brain. No external API calls, no corporate clouds—just raw, local intelligence. 📉 Reality Check (The Results): Okay, look… right now, the results are, let’s say, highly questionable . It’s giving “confused toaster” more than “galactic supercomputer,” but hey, Rome wasn’t built in a day, and an infinite universe needs a little chaos first. 🛠️ Absolute Grind Mode: The output might be mid right now, but the workflow is at an all-time high. We are working 25/7, refactoring the neural pipelines, and optimizing the backend to make sure this local LLM integration doesn’t melt your PC. The brain is wired, the bugs are being hunted, and the grind never stops. Next stop: making lnai actually smart and finally getting that flight physics engine to behave! 🛰️✨
🚀 DevLog #3: The Neural Awakening & Backend Fusion! 🪐 Day 2 was chaos, but Day 3? We just plugged the matrix straight into the spine of the engine! 🧠✨ Remember that “confused toaster” from the last devlog? Yeah, well, it just evolved into a full-blown stellar intellect. The pipeline is locked, loaded, and absolutely cooking. Here is the tactical breakdown of what just dropped in the engineering bay: 🌌 The Big Brain Upgrade (Model & Data): We didn’t just tweak the model; we completely rebuilt its reality. We scraped, cleaned, and injected a massive new dataset, pushing our local parameter model to the absolute limit. No more hallucinating dead stars — lnai now actually understands the cosmic data it’s processing. 🔗 The Great Backend Fusion: The neural net is officially out of the sandbox and merged with the core Rust backend! We wired the prediction pipelines directly into our engine architecture. It’s fast, it’s memory-safe, and it operates with zero friction. Data is flowing from the neural layers to the backend loops in real-time. 🏎️ Zero Meltdown, Pure Performance: Training and running local models usually turns your rig into a literal space heater, but we optimized the living hell out of the inference pipelines. The memory footprint is clean, the tokens are flying, and your GPU can actually breathe while rendering the cosmos. The foundation is solid, the telemetry is clean, and the local universe finally has a brain that doesn’t just work — it thinks . Next stop: weaponizing this intelligence for procedural generation and forcing that flight physics engine to respect the laws of space! 🛰️🔥
🚀 DevLog #4: The God Mode Dashboard & Stellar Genesis! If Day 3 was about plugging the matrix straight into the engine’s spine, today we built the ultimate command center around it. No more chaos, no more manual config-wrangling via terminal. We just deployed a full-scale infrastructure for total cosmic control! Here is the tactical breakdown of what just dropped in the engineering bay: ⚙️ Project “TestBench”: Total Control & Validation We got tired of guessing what’s actually happening inside our AI’s digital brains, so we built TestBench—the ultimate proving ground for complete testing, training, and validation of every single AI model in the project. Backend Fusion: The whole thing is hardwired straight into our reactive Rust backend. God-Tier UX: Now, benchmarking a dataset, checking loss curves, validating weights, or fine-tuning a model is a matter of a few clicks without ever leaving the ecosystem. Real-time telemetry monitoring. Honestly? It’s clean, it’s seamless, and it just works. 🌟 Meet SIREN: The Star Architect Our AI fleet just got a massive reinforcement. Say hello to our newest model—SIREN. Her sole, monumental objective is the procedural generation of the stars themselves. No more random glowing spheres. SIREN calculates physics, luminosity, spectral classes, and spawns unique, structured astrophysical objects. The cosmos isn’t just procedural anymore; it’s beautifully complex and scientifically backed. 🎛️ Lunar-Frontend: The Creator’s Control Panel A cosmic backend deserves a killer visual interface. We gave lunar-frontend a massive upgrade to make managing this madness an absolute breeze: The Sidebar: We coded a modular, highly responsive sidebar. All your tools, model toggles, and data streams are now neatly organized and right at your fingertips. Next Stop: Unleashing SIREN onto the global map, syncing its generation directly with TestBench metrics, and forcing the frontend to smoothly render billions of new star systems without dropping a single frame! 🚀
DevLog #5: God-Mode Editor, Crate Separation, and Stealth Features Following the development of “Mission Control,” the project has transitioned into a full 3D environment. The cosmos is no longer just being generated; it can now be manipulated in real-time. Project “Lunar-Hal”: God-Mode Editor The new 3D editor allows for direct manipulation of the simulation rather than just monitoring metrics through the TestBench. Free-Fly Mode: A fully functional in-engine 3D editor. Users can toggle Creator Mode to navigate through stellar clusters at high speeds. Real-Time Manipulation: Selecting a star allows for immediate overrides of mass, spectral class, and luminosity. The SIREN engine recalculates astrophysics on the fly, updating the frontend visuals without performance drops. Architecture: The Great Crate Separation To manage codebase complexity, the backend has undergone a significant architectural refactor. All core gameplay logic has been isolated into a dedicated, independent Rust crate. Modular Design: Rendering overhead and editor scaffolding are now separated from pure game rules, physics, and state machines. Improved Compilation: Logic changes no longer require recompiling the entire project. Crates now compile in isolation, allowing for faster iteration and cleaner incremental builds. Inventory System and Stealth Mechanics Work has begun on a functional inventory system designed to hold “Creator Tools.” This system moves beyond traditional item management into world manipulation. Drag-and-Drop Reality: Mechanics are being implemented to allow users to grab celestial bodies directly from the viewport to rearrange solar systems manually. Entity Interaction: These telekinetic mechanics are also being tested on combat entities. This allows for manual interaction with hostile fleets, such as testing physics logic by moving units into gravitational anomalies like black hole event horizons. Lunar-Frontend: Enhanced UI The UI has been updated to accommodate the new editor and inventory capabilities: Creator Widgets: The modular sidebar now includes inspection panels for editor controls and inventory management. Optimized Streaming: The frontend provides a seamless bridge between TestBench metrics and the heavy 3D viewport, maintaining high performance during active manipulation. Roadmap The next phase of development will focus on: Running heavy simulations of billions of stars in background threads while maintaining editor stability. Stabilizing enemy pathfinding during manual entity manipulation. Preparing the architecture for multiplayer synchronization. Note: DevLog updates may be sporadic due to local ISP and network routing issues affecting access to the Hack Club site. Space logistics are complex, but terrestrial routing remains a significant challenge.
🚀 DevLog #6: Hyper-Optimization, Core Threat Integration, and New Swarm Archetypes ⚙️ Optimization: The Fight for Nanoseconds With the transition to a full 3D environment and manual entity manipulation, the load on the CPU and memory bus grew exponentially. So we tried to optimize as much as possible. 👾 Integration: Enemies in the Core Loop Previously, hostile entities existed only as isolated test units (testbench). Now, enemy fleets are officially hardcoded into the base simulation loop. Autonomous Background AI: Enemy behavior is no longer bound to the player’s viewport. Strategic fleets live their own lives in the background—conquering systems and harvesting resources—even if you are editing a galaxy millions of light-years away. Dynamic Pathfinding: The toughest challenge was stabilizing AI during manual manipulation. If you grab a planet and toss it in front of an enemy dreadnought, the pathfinding algorithm instantly recalculates a safe bypass vector based on the newly altered gravitational signature of that sector. 🛸 New Threat Archetypes: The Utility-Driven AI Each enemy now operates on a Utility AI system, calculating its next move based on distance, health ratios, and—most importantly—the Player’s Attention . We have categorized the hostile forces into six distinct tactical archetypes: Archetype Role Logic Highlight The Tank Heavy Juggernaut Berserk Logic: Its utility increases as its health drops. It becomes more aggressive the harder you try to kill it. The Thief Rapid Raider Attention-Aware: Only strikes stars when the player is looking away ( t_neglect > 15.0 ). High speed (20.0) allows for quick hit-and-run ops. The Invisible Stealth Saboteur Adaptive Camouflage: Maintains $0.05$ visibility. Only reveals itself when the player’s cursor “scans” over it or during brief power-grid flickers. The Scavenger Opportunistic Parasite Pack Mentality: Heavily prioritizes stars that are already under attack by other units to “steal” the resources. The Backstabber Chaos Agent Infighting: If it detects a fellow enemy with $<35 % $ HP, it will betray its own kind to secure the kill for itself. The Coward Skittish Scout Self-Preservation: Immediately generates an escape vector if the player’s “God-Hand” (cursor) gets too close or a Tank enters its vicinity. 🧠 The “Attention Map” Integration The most advanced part of this integration is how these entities interact with the Lunar-Frontend . We don’t just track positions; we track the player’s focus: d_mouse Factor: Enemies calculate their distance to your cursor. Thieves and Cowards use this to decide when to flee or stay in the shadows. t_neglect Metric: The simulation tracks how long it’s been since you last interacted with a specific star. The longer a sector is neglected, the higher the “utility” for an invasion force to move in. ⚔️ Combat Mechanics: Physical Projectiles vs. Direct Damage To keep the simulation performant while maintaining visual fidelity: Star Assaults: Enemies fire physical Projectile entities. Each has its own speed, radius, and damage value, allowing players to potentially intercept them or warp them with gravitational anomalies. Internal Infighting: When enemies like the Backstabber turn on their allies, the damage is processed via an optimized EnemyDamage buffer, bypassing heavy projectile physics for internal “swarm” calculations. Note: ISP issues and local routing to the Hack Club site still make uploading updates feel like sending signals through a dense asteroid belt.
DevLog #7: WebOS Evolution, The Black Room, and “lns” Orchestration This update marks a fundamental shift in how we interact with the simulation ecosystem. We have moved away from static dashboards to a fully dynamic WebOS environment within lunar-testbench , alongside a complete overhaul of our launching utility. Lunar-Testbench: The WebOS Overhaul The Testbench has been reimagined as a “Black Room” —a dark, immersive workspace where everything begins with three spotlights. The Spotlight Mechanic The interface features three dormant flashlights. Service Ignition: Clicking a spotlight “turns it on” and launches its corresponding backend service. Dynamic App Injection: Once a service is active, the specific applications depending on that service manifest below the spotlight. The Sandbox: Our most complex tool, the Sandbox , now requires all three services to be active simultaneously, setting the stage for deep-system integration in future updates. The Dock To manage the chaos of multiple windows, we’ve implemented a Bottom Dock . Every running application is pinned here, allowing for seamless switching between training, validation, and live simulation environments. Orchestration: From “lunar-start” to “lns” The way we boot the engine has been streamlined. We’ve stripped the heavy lifting out of the primary entry point to create a more modular startup flow. lns Utility: lunar-start has been evolved into lns —a lightweight micro-utility. Its sole purpose is to initialize the Testbench and trigger the backend. lunar-start-backend: This is a new, dedicated service that acts as the primary launcher. It monitors and manages the lifecycle of all other applications within the suite, ensuring that when you click a service in the UI, the backend is ready to deploy it.
* 🚀 DevLog #8: The Great Pivot — From Game to Technical Stellar Platform * The mission has changed. Following the deployment of the WebOS in DevLog #7, we realized that the “game” mechanics were holding back the true potential of the engine. This update marks our transition from a simulation with combat elements to a high-fidelity technical platform for stellar generation, research, and visualization. We have officially executed the transition plan, gutting the “game” and hardening the “platform.” The Great Purge: lunar-stellar-core The era of lunar-game-backend is over. We have performed a git mv on the heart of the engine to establish a strict architectural boundary. Logic Extraction: We have completely removed all traces of Enemies, Projectiles, HP, Attacks, and the “Attention Map.” The simulation no longer cares if you are “watching” a star; it only cares about the physics. The Core: The new lunar-stellar-core crate is now framework-agnostic. It handles only the technical state: camera math, sector caching, and the pipeline results. Terminology Shift: “World” is now “StarScene.” It’s no longer a level; it’s a coordinate-stable dataset. Unified Multi-Platform Deployment We’ve consolidated our frontend logic. Instead of separate builds, we now have a single Managed Frontend Service with a unified builder. Target Switching: Through the lns utility, we can now hot-swap between web , desktop , and android targets. Android Integration: The platform now supports Android NDK/SDK. We’ve replaced mouse-only logic with Pointer Events , enabling touch-based pan/zoom/selection. Runtime Config: The backend now dynamically injects the correct URL (handling the 10.0.2.2 emulator trap) based on the active platform. Sandbox 2.0: The Admin Overlay The Sandbox is no longer a separate copy of the simulation. It has evolved into a Meta-Management Shell for the real frontend. The Iframe Bridge: The Sandbox now embeds the live lunar-frontend via an iframe. Communication Protocol: We implemented a versioned postMessage protocol in lunar-structures . The Sandbox sends Admin Commands (CreateStar, SetCamera) and receives Scene Events (StarSelected). Permanent SIREN Gallery & Drag-and-Drop We’ve moved from “latest renders” to a persistent filesystem-based catalog . Atomic Persistence: Stars created via AI or manual tools are now saved as GalleryStar DTOs. Each star gets its own directory with metadata, SIREN textures, and thumbnails. True Drag-and-Drop: We’ve implemented a custom drag-session in the WebOS. You can now drag a star from the Gallery into the Sandbox to insert it into the live scene, and vice versa. Found Issues The transition hasn’t been without its casualties. Two “boss-level” bugs have appeared during the implementation of the new WebOS logic: Sandbox Handshake & OS Crash: Currently, the Sandbox is failing to “see” the Frontend service through the iframe bridge. Even worse, attempting to initialize the connection often results in a total OS-level hang , crashing the Testbench entirely. We are currently investigating if this is a circular dependency in the backend or a massive memory leak during the handshake. The “Minimize” Trap: While we implemented WindowLifecycle to keep applications alive in the background using display: none , we hit a critical logic error. Once an app is minimized, the “un-minimize” (maximize) function fails to trigger . The app remains in a state of digital limbo, perfectly preserved but completely inaccessible.
DevLog #9: Checkpoint Hardening & Stage 5 GNN Kinematics Convergence * This session was focused on a deep technical milestone: diagnosing a critical engine staging bug in LUNAR-HAL and driving the Stellar GNN-kinematics pipeline through the completion of Stage 5. 1. 🛠️ Staging Architecture & Atomic Checkpoint RCA (Rust) Diagnosed and resolved a critical issue in the --resume workflow where staging logic triggered a self-copy ( src == dst ), truncating output checkpoint weights upon restart. Implemented robust canonical path checking ( std::fs: :canonicalize ) to ensure fully atomic weight persistence across interruption signals ( SIGINT / SIGTERM ). Hardened checkpoint state serialization, eliminating filesystem race conditions during runtime hot-reloads. 2. Stage 5: GNN-Kinematics Training Executed the 200-epoch training run for the galactic velocity prediction model ($v_x, v_y, v_z$ derived from positions + photometry). Validated host telemetry: stable VRAM footprint on local NVIDIA GeForce RTX 5070 (~3.1 GB / 12 GB allocated) with optimal throughput (~30s / epoch). 3. Loss & Convergence Verification Train Loss: Decreased to ~0.7660 . Validation Loss: Reached a clean, stable quasi-stationary plateau at ~0.7694 . Physics Constraint: Invariant equilibrium maintained throughout ( phys_loss ≈ 0.7700 ), demonstrating high generalization without overfitting.
Alright, final devlog! Went all-in on bug squashing for this one—crushed a ton of issues, finally got CI completely green and stable, cleared out all the CodeQL alerts, and pushed the demo build. So yeah… I’m officially shipping now!
Ships:
Finally shipping this! It honestly took forever and I burned out twice along the way, but I pushed through to get it over the finish line. Try out the live demo or grab the local build. Heads up: the web demo might feel super sluggish since the models are running on Heroku, so expect some delay. Also, all demo sessions share the same persistent worlds! Have Fun!...
|
1792853807.213252
|
1792940207.213252
|
|
940
|
Spacetex by @stemdood44 | Stardance
|
stemdood44
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Spacetex by @stemdood44 | Stardance
|
1792788639.4259224
|
1793393439.4259224
|
|
941
|
Untitled project by @Ila | Stardance
|
Ila
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @Ila | Stardance
|
1792486115.5311885
|
1793090915.5311885
|
|
942
|
Munni and prism by @Munnisparkle | Stardance
|
Munnisparkle
|
0
|
0.35
|
0
|
[]
|
[{"post_id": 208, "ts": "2026- [{"post_id": 208, "ts": "2026-06-01T08:32:11Z", "hours": 0.3517, "text": "Started setting up the project folder and files for Munni and Prism in VS Code! Created index.html, style.css and game.js. now wrote little bit of html i know thats the conversation blw the characters in the game"}]...
|
Title: Munni and prism by @Munnisparkle | Stardanc Title: Munni and prism by @Munnisparkle | Stardance
Devlogs:
Started setting up the project folder and files for Munni and Prism in VS Code! Created index.html, style.css and game.js. now wrote little bit of html i know thats the conversation blw the characters in the game...
|
1792670068.659922
|
1793274868.659922
|
|
943
|
Project See The Voices Nepal's website by @Pas Project See The Voices Nepal's website by @Pasta | Stardance...
|
Pasta
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Project See The Voices Nepal's website Title: Project See The Voices Nepal's website by @Pasta | Stardance...
|
1792630457.32414
|
1793235257.32414
|
|
944
|
Timer! by @TAP | Stardance
|
TAP
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Timer! by @TAP | Stardance
|
1792803031.500145
|
1793407831.500145
|
|
945
|
StudyQuest by @BlackShell | Stardance
|
BlackShell
|
0
|
5.81
|
0
|
[]
|
[{"post_id": 77724, "ts": "202 [{"post_id": 77724, "ts": "2026-10-08T03:02:24Z", "hours": 2.9167, "text": "I developing on mac"}, {"post_id": 2568, "ts": "2026-06-05T04:19:09Z", "hours": 0.9864, "text": "StudyQuest progress Implemented the core progression system: • XP system • Level system • Level up at 100 XP • XP progress bar • Study session tracking • Study time tracking The app now tracks study sessions and study time while rewarding progress with XP and levels. Built with Flutter."}, {"post_id": 2162, "ts": "2026-06-04T14:35:48Z", "hours": 0.8278, "text": "StudyQuest now runs on iOS 📱 Current features: XP system Level system Level up at 100 XP Next features: XP progress bar Study timer Streak tracking Built with Flutter."}, {"post_id": 1951, "ts": "2026-06-04T06:18:37Z", "hours": 1.0806, "text": "Started development on StudyQuest, a gamified study tracker built with Flutter. Today I: Created the Flutter project structure Set up GitHub and pushed the initial code Built the first home screen Added placeholders for XP, levels, study time, and streaks Learned more about Flutter widgets and layout structure Next, I plan to add a study timer and an XP system."}]...
|
Title: StudyQuest by @BlackShell | Stardance
Devl Title: StudyQuest by @BlackShell | Stardance
Devlogs:
Started development on StudyQuest, a gamified study tracker built with Flutter. Today I: Created the Flutter project structure Set up GitHub and pushed the initial code Built the first home screen Added placeholders for XP, levels, study time, and streaks Learned more about Flutter widgets and layout structure Next, I plan to add a study timer and an XP system.
StudyQuest now runs on iOS 📱 Current features: XP system Level system Level up at 100 XP Next features: XP progress bar Study timer Streak tracking Built with Flutter.
StudyQuest progress Implemented the core progression system: • XP system • Level system • Level up at 100 XP • XP progress bar • Study session tracking • Study time tracking The app now tracks study sessions and study time while rewarding progress with XP and levels. Built with Flutter.
I developing on mac...
|
1792569278.6678202
|
1793174078.6678202
|
|
946
|
MacroPad V4 by @TAP | Stardance
|
TAP
|
0
|
0.73
|
0
|
[]
|
[{"post_id": 25162, "ts": "202 [{"post_id": 25162, "ts": "2026-07-09T06:36:22Z", "hours": 0.7272, "text": "MADE THE SCHEMATIC! This is probably one of the most cutest schematic I have ever made! Its a pretty simple plan tho! This has 3x3 switch matrix, 9 sk6812 mini-e in a daisy chain and an 0.91” OLED"}]...
|
Title: MacroPad V4 by @TAP | Stardance
Devlogs:
M Title: MacroPad V4 by @TAP | Stardance
Devlogs:
MADE THE SCHEMATIC! This is probably one of the most cutest schematic I have ever made! Its a pretty simple plan tho! This has 3x3 switch matrix, 9 sk6812 mini-e in a daisy chain and an 0.91” OLED...
|
1792939933.6606238
|
1793803933.6606238
|
|
947
|
BlackShell Golf by @BlackShell | Stardance
|
BlackShell
|
0
|
7.94
|
0
|
[]
|
[{"post_id": 77965, "ts": "202 [{"post_id": 77965, "ts": "2026-10-09T01:20:22Z", "hours": 2.4283, "text": "Build watch App!!"}, {"post_id": 77722, "ts": "2026-10-08T02:55:39Z", "hours": 5.1039, "text": "Liquid Glass update!!!"}, {"post_id": 212, "ts": "2026-06-01T08:45:03Z", "hours": 0.4108, "text": "Today I prepared BlackShell Golf for Stardance and published the project on GitHub. BlackShell Golf is a Flutter app for live multiplayer golf scoring. Players can create a room, join a room, and track golf rounds together. Today I connected the project repository, organized the codebase, and tested the app in the browser. Next, I plan to improve score saving, round history, and the overall user experience. Screenshot attached."}]...
|
Title: BlackShell Golf by @BlackShell | Stardance
Title: BlackShell Golf by @BlackShell | Stardance
Devlogs:
Today I prepared BlackShell Golf for Stardance and published the project on GitHub. BlackShell Golf is a Flutter app for live multiplayer golf scoring. Players can create a room, join a room, and track golf rounds together. Today I connected the project repository, organized the codebase, and tested the app in the browser. Next, I plan to improve score saving, round history, and the overall user experience. Screenshot attached.
Liquid Glass update!!!
Build watch App!!...
|
1792558507.209931
|
1793163307.209931
|
|
948
|
My awesome macropad! by @Kanata | Stardance
|
Kanata
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Kanata | Stardance
|
1792778036.074678
|
1793382836.074678
|
|
949
|
Untitled project by @Kanata | Stardance
|
Kanata
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @Kanata | Stardance
|
1792734584.5063086
|
1793339384.5063086
|
|
950
|
Volvo API playground by @Kl | Stardance
|
Kl
|
1
|
130.69
|
2165
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-06T20:19:02Z", "hours": 113.0, "multiplier": 19.09, "payout": 2165, "blessing": "neutral", "text": "A Milestone Welcome everybody to the first ship of this project. What is this project? This project simulates how the Volvo API works. Why was this project created in the first place? So it’s easier to create and test your app that uses the Volvo API without using ready-made libraries. I can’t find the features you mentioned in the devlog? Check the scope branch or the upcoming dev branch. What I’m proud of: I learned a lot of things (this is my first big public project): Tailwind Python stuff (I started with C++) Writing documentation (Markdown) I also learned the basics of OAuth2 and how APIs work. Making a project with all the features needed to get started. I created an additional document for you, Stardancers: Stardance PATH What is still on the TODO list? More APIs Scopes docker image See the roadmap . What to see? error logger recreated endpoints dashboard web socket realtime changes internal endpints interactivity of the car", "repo": "https://github.com/klswar0/Volvo-API-playground", "demo": "https://playground.kls.hackclub.app/"}]...
|
[{"post_id": 79861, "ts": "202 [{"post_id": 79861, "ts": "2026-10-15T17:17:04Z", "hours": 7.1881, "text": "Devlog A very long time no see. I have made a lot of progress on adding an SQL database. Testing on MySQL The backup server provider gives me access to one. SQL changes A lot of BIG changes. The reason why I haven’t posted for so long is that I didn’t want to post about something that doesn’t work. Created new classes to intercept data changes, both in case of direct dict changes and when going through the SQL model library. (I didn’t change much in the code, just imported it under the same name as the old database.) And it works! At the start, only reading data worked, but now it can send data back to the database. Added a regen function to make sure built-in API keys are always the same after a restart. Fixed the car creation function (but when I started storing the additional data in SQL, it broke AGAIN). Added configuration attributes. At first, just the database type, but then all the information needed to connect to a MySQL database. Fixed the scenario readconfig (wasn’t it updated in the past?). A really small number of things I added? Yes, but the amount of debugging and changing built-in functions in classes took me so long. (Could be because of school and not having time to do everything in one sitting.) But I learned how to make a dummy dict with a class, as I called it in the commit: proxy . Problems The SQL database can’t create new cars. Need to check all internal endpoints to make sure they work. Still haven’t merged the DEV branch (TODO). All information is stored in one column as JSON. It works, buuuut I don’t like it that way. Need to clean up the proxy classes. updating docs What failed this time? The second photo attached shows it. Have a look before reading more. _contains__ If you see it, congrats! But if you have a screen full of code, it’s harder to spot. It should be __contains__ , and I spent, I think, two days debugging why all in statements just didn’t work. I was so happy when I finally found it! XAMPP and Apple Silicon The manager app doesn’t open after a restart, so after consulting Google and AI, I found a command that I use: sudo /Applications/XAMPP/xamppfiles/xampp start xampp If someone is asking why I didn’t use the server provided one it just wasn’t practical for now."}, {"post_id": 73730, "ts": "2026-09-25T19:56:38Z", "hours": 4.9217, "text": "Devlog A lot of breaking changes later and getting closer to PR and going to 2 ship Token lifetime WORKS made time when token is expired is rounded to int endpoint for invalidating token possibility for enabling expiring token for a specific token when it’s disabled for all in config file misc pytest for location and energy API fix the url for the enrgy API (it started with connectivity url not wi the energy api) cleanup import created new files to make the code more readable dashboard added location values added capabilities and values auto token generation and expiration in dashboard"}, {"post_id": 69307, "ts": "2026-09-16T19:32:57Z", "hours": 5.58, "text": "Read till the end PLEASE 🥺 Devlog A lot of changes from the last devlog only 5 hrs Mostly bc I add stuff on top of but I will suffer in the future (See dev branch for these changes) Change all connectivity API to start with /connected-vehicle/v2/ to make room for different APIs After that I fixed pytest to reflect that I added a location API with a ONE endpoint There were few iterations Added scopes for this API location:read If I remember correctly Unique error responses (because location error look like old (v1) connectivity API Fixed that operationID could be a constant Added a config option to use longer API keys About here I Fixed the url for location api because it used the connectivity scheme Started working on energy API I added all data from it to this project In short one endpoints says what this car is capable of And the other says the values TODO: add its unique error its half done Scopes corresponding to energy API Fixed that some values and capabilities had the same name (bc of that some bool values where number so a it was important) WIP Oauth2 update: JWT tokens for access tokens WIP token can expire! what are JWT token? There consist of three parts header payload and signature The two first is important for my project the 3 isn’t . They store info about issuer, when token is active, scopes… A lot of useless data for this project or useful? We will see Life Bc of school I didn’t have a lot of time to write devlog (and write code) but I try to do my best before the end of stardance The next ship is planned for 28 September BIRTHDAY TODAY (16 September) Im celebrating my birthday 😄 If you write me a few good words It would be motivating for me."}, {"post_id": 63130, "ts": "2026-09-06T19:20:58Z", "hours": 1.6042, "text": "Devlog MAIN added a startup baner fixed snapshots not saving if website was used scope If you didn’t follow from start this branch contains the experimental scope support which is mostly done but I can guarantee stability that’s why it isn’t pushed to main in fist ship made the scope page work added a back button added button to scope on main page fixed snapshots loading/saving"}, {"post_id": 61052, "ts": "2026-09-03T19:22:00Z", "hours": 2.8836, "text": "Long time no see… The school started aaand I didn’t have time I had low motivation The only thing to do before first ship is docs but I could find time to finish them. Buut I back now. AND I promise to ship it before 7 of September. If you are voting on this project PLEASE do not skip. I have my birthday coming and if the shipwrights doesn’t have a long list it could mean this project payout could be my birthday gift. If I ofc ship it 😅 devlog Small marketing changes everywhere to say that this project doesn’t have any ready code to use Added info about error logger on the landing page Scopes A long way from last devlog Fixed pytest ( A second time) TEMPORARY FIX added so the scope error doesn’t - throw just internal error FIXed the Oauth2 endpoint at least 3 times Added a WIP endpoint to edit scope data from API Fixed how cars are created so they work with both - Oauth and scopes stuff Only looking dashboard page for scopes compare I think I forgot to say something in last devlog config file if you would like to use different instance Toml oillevel to oilLever AI disclaimer that I used this project to learn tailwind Make the doors have different statuses in mean time Untracked WIKI Redo the home page Started working on stardance path A lot of misc that I don’t remember other I created a small modified volvo example app to show that my app works like the real one"}, {"post_id": 55226, "ts": "2026-08-26T20:27:11Z", "hours": 4.2503, "text": "Devlog Error logger added colors to the terminal print out using: \\033[31m \\033[0m Good to know that it is so easy to add colors to text added timestamps to log file and - between errors Changes how it reads body once again and fixed url encoded requests logging My additional information I put in detail in the json response (the real API can send it like that buttty I didn’t see it. info from docs ) additional changes: New scenarios mostly about service warnings You can add notes to the website thru config files Scopes I started working on scopes. What are they? They are really permissions (you can know them from discord bots or if you login thru GitHub etc.) I don’t want to put them in this first ship but I needed to work on something (while I work on wiki) and I CAN’T guarantee every thing works after adding them. You can see it in the scopes branch. what is done: I have made preparation so the additional database (dict) I use for OAuth can store more data have updated website func to work with changes and also pytest added all possible conve (connectivity API) scopes WIKI when I add everything to them I will finally try making a ship added the error logger page updated the sidebar scenario and snapshots page a lot of misc Bonus photos from vacation on baltic sea"}, {"post_id": 49931, "ts": "2026-08-18T21:59:53Z", "hours": 3.1292, "text": "Devlog There was a small (or big) problem in my playground. If an error was returned in the response, you could only see it if your app handled it or by printing the response. That’s why I added an error logger. It can show errors in two ways: Terminal Log file How it works There were two ways of doing it (from what I learned): Middleware that captures all responses (this could be helpful in the future). Exception handlers (this is what I chose). I use two handlers: @app.exception_handler(RequestValidationError) @app.exception_handler(HTTPException) It was a horrible time searching for why it didn’t work. At first, I worked in a separate file, but I couldn’t get the (fastapi) app variable into those functions. So I copied them into main file to make them work first. I had to change some JSON responses to HTTPException to make the second handler work. After I captured the first request and printed it, I worked on one function that writes a log and another that prints to the terminal. I also created a class to store useful data. It works like this: Exception handler-> ->Put data into class -> ->Create response -> ->Return response ->Create a background task that logs the error I create a background task so the response doesn’t wait or even worse fails In the end I found that I can wrap these func with this simple func to make them work in different file def setup_error_logging(app: FastAPI): Added a config option: To disable it completely. To disable only the log file. It also bypasses all internal endpoints to make the logs more readable. The best fail… 😅 I returned an exception instead of raising it. I spent a good 15 minutes wondering why the response had status code 200 with a JSON body saying status code 400 . response changes I also checked how the authorization errors look and added two new ones: Missing Authorization header. Invalid vcc-api-key header. WIKI (not counted) I focus on making a GitHub wiki (new docs) After ending them and the error logger. Its time for the first ship !!!!!!! Nest instability: I made a backup server : https://frog01-21185.wykr.es/ Its not ideal one, bc some asian countries are blocked but its shouldn’t have any downtime (I hope so) If an Admin read it why I must copy enter from different text input 😭"}, {"post_id": 48444, "ts": "2026-08-16T19:51:20Z", "hours": 2.4822, "text": "Devlog SITE changes I found that some number inputs didn’t use the utility classes. I gave them inputText because they are really the same; the only difference is the HTML type . I also forgot to update the reloadable fuel section. It now uses the shorter utility class. Made sure that all text in the header is the same size (they weren’t). I copied all changes back to the main branch. config changes Then I added a config file using the configparser library. also added an option to disable the FastAPI docs. I started working on Wiki: reworking docs.md into a GitHub Wiki with up to date information. Error logger, so you can see what’s wrong without printing the API response in your code. I had some problems with catching the fastapi automatic response but I will leave it for next devlog"}, {"post_id": 46236, "ts": "2026-08-13T10:31:45Z", "hours": 4.6175, "text": "Devlog I forgot to add that I worked on the tests in the test branch, not the main one. OAuth2 PKCE testing. Helped me find an error where, if the code was used (it was reset to \"\" ), it was accepted as \"\" . Now it correctly returns an error. OAuth2 flow testing. Warnings and diagnostics now have some simple checks too. And I merged it into main . Then I started cleaning up the Tailwind CSS. NOTE: they are in new branch dashboard/cleanup Why? Because I used the Play CDN in the past, so I couldn’t create utility classes in a CSS file. Soooo I didn’t. Andddd there were a lot of Tailwind classes that didn’t fit on my screen. Now that I started precompiling it, I could add them. I added 5 unique utility classes. All of them combined are used around ~120 times across all HTMLs. The longest one: @utility inputSelection { @apply w-full px-4 py-2 .5 bg-zinc-950 border border-zinc-800 rounded-xl text-zinc-100 focus : outline-none focus : ring-2 focus : ring-blue-300 focus : border-transparent transition-all appearance-none text-center [ text-align-last : center ] cursor-pointer ; } I also minified the CSS file. If I understand it, it removes anything the browser doesn’t need to understand the CSS (new lines, unnecessary spaces…). It’s better because those characters are still sent over the network, and fewer bytes mean less traffic. While using the new utility classes, I tried to preserve the layout, so everything should look the same as before."}, {"post_id": 44802, "ts": "2026-08-10T20:28:29Z", "hours": 3.7639, "text": "Devlog Working hard on pytest tests. I learn how assert works and how to name . I never used or created test in any language so I think they aren’t perfect (not like they should),but they work😄. I looked like AI made few and how other people and read some stuff online Tests created for these endpoints Around 25 of them List cars About car Engine info Engine start/stop Climate start/stop Windows Doors Lock/Unlock Reduced Guard Lock Flash, Honk, and Combination Tyres Statistics Fuel Odometer Engine diagnostics Brakes Command accessibility Still to do Warnings and diagnostics Commands More changes The tests helped me find and clean up several issues: Documentation updates. The honk endpoint was ../horn but should be /honk . Some values ( odometer , fuel ) are int , just like in the OpenAPI specification, not as described in the official docs. Fixed spelling mistakes: - oillevel to oilLevel - coolantLever to coolantLevel Want to help and has access to volvo with active VOC I need to test engine and climate endpoints but I don’t have an access to a car with it. Soooo if you can contact me on slack"}, {"post_id": 42512, "ts": "2026-08-07T09:41:54Z", "hours": 4.2411, "text": "Devlog Tracking headers implemented : There are two vcc-api-operationId - UUID traceparent - W3C traceparent (for now only sends it back) dashboard should look good on small screen (its very long but I don’t want to redesign it now) This is the reason why I there is much time in this devlog. It was a lot of try and error before something looked good both on mobile and desktop and I liked it . But at least it works know 🙃. some small cleanup of comments I worked again on internal updates endpoint (hopefully works now) started working on pytests (but I will talk about in next devlog (I gave my self 2 days for it) I really want to get the first ship out, so it isn’t going to be perfect. I still have a lot of features and improvements I’d like to add."}, {"post_id": 40711, "ts": "2026-08-04T12:41:43Z", "hours": 4.4231, "text": "Devlog I had a problem when I wanted to rewrite the scenario system. It only changed the local version of the Car (It means it really didn’t update anything). I wanted to update a backup version first, and only if everything was correct, replace the original with the backup. In the end, I used an already created function to first test and then apply to the car . Main PKCE misspelling fixed. Added a landing page with an option to disable it and redirect directly to the login screen (like in the last devlog I have photos of making it). Worked on the lights section. Fixed the docs URLs. Dashboard and WebSocket toggles now work. Rewrote and enabled the updates endpoint. Validation now catches values that can’t be converted to int . Scenario loading into a car instance should now be more consistent with the other functions. Improved mobile responsiveness (and then fixed the desktop one). Some elements were outside the screen on mobile (nothing important, but it didn’t look good). NOTE: the dashboard with car attributes still needs to be adapted. Added windows (because I forgot to 😅) to the dashboard and organised the lighting section. OAuth2 and Snapshots buttons should now always be centred. TODO Debug and tracing headers (from the real API). Additional instructions. Then I think it’s finally ready for the first ship. There are still a lot of things I want to add, but I can’t work indefinitely. Compare The compare app now has the Content-Type fix enabled (like the official API). Compiled the Tailwind CSS for the compare app. NOTE: I will add here more screenshots as link later Also thinking about adding it frictionless mission but I’m not sure."}, {"post_id": 39642, "ts": "2026-08-02T19:24:37Z", "hours": 3.62, "text": "Devlog Snapshots loading page (screenshots while I worked. I had more but the limit was 4). As suggested by the Tailwind CSS tools, changed some classes to more canonical ones. You can now delete cars through both the API and the dashboard. Snapshot corruption (when the app is force quit) should be fixed. Started working on the landing page, but I’ll leave it for the next devlog (mostly because I have on my other laptop). Fixes to do Sometimes the new OAuth2 and Snapshots buttons are off-center. Compare app needs fixing (need to enable the Content-Type fix from the official API). PKCE spelling in the internal API."}, {"post_id": 37827, "ts": "2026-07-30T19:39:54Z", "hours": 4.1028, "text": "Devlog The Content-Type problem is SOLVED …… What was the problem? (My reading skills? ) there are two headers with application/json : Content-Type (POST) Accept (GET) The Accept header isn’t required ( can be */* , application/* or application/json ). So the Content-Type mystery is mostly FIXED but I still need to check with a real Volvo car if Content-Type is actually required. (I’ll do it tomorrow.) Changes: Accept is now handled by my API like in the official API. Added Content-Type checks (like the docs say, meaning it’s required). While proofreading the docs, I found that PKCE is written as PCKE in one internal endpoint. (Not fixed yet.) Small README update (I try to keep it up to date). Scenario page: You can now load a scenario using the GUI. Recompiled the Tailwind CSS. I attached screenshots showing it (you can also see snapshot button but its not implemented YET)"}, {"post_id": 36608, "ts": "2026-07-28T20:31:07Z", "hours": 0.5122, "text": "The comparison app is now online! Comparison app: https://compareplay.kls.hackclub.app/ I also updated the main app with the new dashboard design: https://playground.kls.hackclub.app/internal/welcome devlog Tailwind CSS is no longer loaded from the CDN. I think its now precompiled. Note to others: Remember to update your banner to feature your app (see #stardance on Slack). Otherwise, your ship will be rejected. EDIT: A lot of bots try to connect to my apps do you think I should make a honeypot?"}, {"post_id": 36297, "ts": "2026-07-28T09:47:40Z", "hours": 3.2881, "text": "Devlog I found another way to hide the fuel stat when it isn’t useful for a particular type of car: the HTML hidden attribute. At first, I thought I should add or remove the element hidden, but that turned out to be more complicated than I expected. I think using hidden is still a cleaner solution but I still using templates files. While working on the dashboard, I wanted to add units like km , L , and % to some values. Instead of handling that in Python, I added another div with some margins and, in a few places, used flex so everything stays on the same line without adding more backend logic. Added more page changes thru HTMX (nearly all pages use it). Creating a new car now refreshes the page. when an error occurs, I use HX-Reswap and the HX-Retarget response header (when creating new car as proof of concept). Added HTMX transitions to the OAuth2 settings page.(all pages have transitions) What to do before the first release (Mostly a checklist for myself 😅) Content-Type checks. Scenario and snapshot system support in the dashboard. Main showcase page. Finish the remaining documentation. Two READMEs: one for the main repository and one for the companion app repository. I’m thinking about having one technical README and another one that’s easier to understand for people who don’t code. Better error handling in the dashboard. Right now, most errors are just displayed as plain text instead of being part of the page. deploy updated version on nest I wanted to add a video but MacOS made me a half gig and I don’t think stardance would handle"}, {"post_id": 35043, "ts": "2026-07-26T06:29:01Z", "hours": 5.5947, "text": "Devlog Most of my time was spent working on the dashboard with Tailwind CSS. It took a lot of experimenting to find a design I actually like. I also changed how HTMX updates the dashboard through WebSockets. Before: A dedicated template was rendered every time to update that part of the dashboard. Now: Only the text containing the updated value is replaced. That said, in the future it won’t always be just text. For example, if the fuel type changes from hybrid to electric , the fuel level should disappear from the dashboard instead of just changing its value. While working on this, I found a bug caused by HTMX sending boolean values as strings. This caused climate settings to be marked as invalid. I need to distinguish between an invalid value and an invalid attribute instead of always treating the entire attribute as invalid. Note to myself Add transitions. Make all HTML pages use the same CSS file from now on. Update the version on nest server and make a public companion instance Aaand that’s all. Making websites is painfully slow."}, {"post_id": 33472, "ts": "2026-07-23T13:34:25Z", "hours": 4.2786, "text": "Devlog I don’t know if I mentioned it before, but for now the Content-Type checks are disabled. I need to learn more about them and implement better validation. Created an updated OAuth2 settings page and a car selection screen (with Tailwind CSS, of course). Started experimenting with a new dashboard. It’s still a work in progress, but it will most likely become the main design. I’m also thinking about adding a second dashboard style, although I’m not sure if I’ll do that before the first release. I definitely want to clean up the HTML/Tailwind code by moving repeated styles into reusable classes or something similar. I’m also thinking about using more HTMX so that more pages can update data without needing a full page reload. Wrote more documentation. I still need to verify the fuel endpoint because I don’t remember whether it handles different engine types correctly. ( The new OAuth2 settings page and the car selection screen. For next develop I think I will make a video of how everything works)"}, {"post_id": 32303, "ts": "2026-07-21T11:58:32Z", "hours": 2.6278, "text": "Devlog Companion app I said it was finished for now, but I forgot to add one more thing (the one on the left in the screenshots): a dashboard redirect. Main app I’m still investigating the Content-Type problem. I verified that the official Volvo API behaves correctly, so I’m working on matching that behavior. Added work-in-progress Content-Type checks. Started reworking the CSS using Tailwind CSS. It’s still mixed with some plain CSS for now. Enabled support for the reduced guard lock command. You have to manually mark it as supported, and for now it behaves the same as the normal lock command. Let me know which design you like more: the new one (center) or the old one (right)."}, {"post_id": 31979, "ts": "2026-07-20T20:18:13Z", "hours": 3.7667, "text": "Devlog I’m mainly focused on finishing the companion app. I started working on the CSS. Most of my time was spent learning Tailwind CSS (so I didn’t track it). I think it’s a better fit for me than writing plain CSS. Added Tailwind CSS to all pages of the companion app. (I think I need to redo the main app now. 😅) Added a small README with information about the main app. I think it done now but I will come back to it before first ship Main app While working on the companion app, I found another issue. The Content-Type: application/json behavior doesn’t match the official API. I verified that the official API works as expected, checks for it mine doesn’t (I think)"}, {"post_id": 30890, "ts": "2026-07-18T21:12:58Z", "hours": 3.2169, "text": "Devlog Companion app Added manual mode for comparison. Engine start/stop now works in normal mode. Before pushing, I forgot to fix one thing: { \"error\" : \"Failed to retrieve data from unofficial API.\" , \"detail\" :{ \"detail\" :[{ \"type\" : \"dict_type\" , \"loc\" :[ \"body\" ], \"msg\" : \"Input should be a valid dictionary\" , \"input\" : \"{ \\\" runtimeMinutes \\\" : 10}\" }]}} The fix was simple: I forgot to use json.loads() . I pushed a quick fix commit right after. The photo shows the manual comparison page. I’m still working on the comparison logic, which is why it doesn’t have any CSS yet. Sorry for not adding Volvo API keys so you can see the differences between both APIs, but that would have taken too much time today. Its also the reason why Im creating this app Main app Worked on the documentation. The notifier now supports more than one updated attribute at the same time. It’s not the best implementation, but I’ll improve it after the first ship. Fixed snapshot loading and added exception handling. Scenario loading now reports malformed JSON files. Fixed a dashboard bug where tire information was shown three times. I think I planned to add more data there… and then forgot. I should probably test everything before making a devlog or committing, but I also don’t want my devlogs to have to much time."}, {"post_id": 29435, "ts": "2026-07-16T11:46:44Z", "hours": 0.5936, "text": "A public online demo!!!!! The project is finally available online! https://playground.kls.hackclub.app/internal/welcome Please don’t be the bad guy and fight with other people over access. ❤️ That’s all I wanted to say because this is a really big milestone for me. There will also be another commit today to make sure everyone can run their own instance of the project. I found a few issues that only appeared outside of my local environment: Some WebSocket features break when using HTTPS. The dashboard had problems when the instance wasn’t running on the same computer. Those should be fixed in today’s commit. If you find any errors please comment or contact me on slack Also thanks to nest hackclub for hosting"}, {"post_id": 29164, "ts": "2026-07-15T21:37:24Z", "hours": 2.8483, "text": "Devlog Authorization was my mistake. It should have been accessToken , not Authorization . Why I thought that? I have no idea. No it was good before I was sleepy I think when I did that The snapshots system now works. Why it didn’t work as expected: I forgot to use copy(deep=True) . One of the small dictionaries was written incorrectly. Added saving and loading snapshots from a file. The scenarios system now works and has been tested. Difference between snapshots and scenarios Snapshots copy all data about a car. They are persistent and can be saved to a file. Scenarios only change selected attributes. They are designed to be created and edited manually in a JSON file. Main app The main app is mostly ready. Before the first release, I still need to: Finish the documentation. Add a roadmap with future updates. Verify error responses against the real API. Finish the comparison feature in the companion app. Add more ready-to-use scenarios and API keys. Companion app Manual login now works, so only the comparison logic is left. I found a bug where api_key_p was None because one endpoint redirected using api_key instead. Started working on the comparison feature. PS: A photo of why the api_key_p was none"}, {"post_id": 27883, "ts": "2026-07-13T19:57:06Z", "hours": 3.8994, "text": "Devlog Writing documentation is a good way to check whether the code you wrote actually works. I already found four bugs while documenting the project. For example, I forgot to pass the redirect URI in a function in main.py , even though it was already implemented in internal.py . I also fixed a bug where notifications could sometimes contain an older value. The dashboard has been moved into a separate file. Snapshots currently have a problem. They are very similar to the Car class, so I’ll debug it and explain what the issue was in the next devlog. Companion app The companion app is meant to showcase the differences between my implementation and the official Volvo Demo Car Sandbox. It also makes testing easier, since you don’t have to write your own application just to try the API. I had a problem with the built-in LibreSSL because one of the dependencies didn’t support it. I had to reinstall Python so that uv would detect the new OpenSSL installation. After that, I was finally able to start the app and get it working. Auto-login and automatic creation of a test car are now working. There’s is no css but I will do it after logic works One more thing: the reason the devlogs have been quieter recently is that I’ve been dealing with some administrative paperwork. I’ll get back to posting them more regularly once that’s sorted out."}, {"post_id": 25868, "ts": "2026-07-10T10:58:56Z", "hours": 4.3936, "text": "Devlog How I don’t like web development… did I already say that? I’ll say it again. I’m working on the OAuth2 settings, and I had a problem where one of the query parameters wasn’t reaching the backend. I still don’t know what actually fixed it. Then I had another problem. I have a function that changes values in the backend, but only one button worked while everything else didn’t. It turned out to be because I debugged the first problem with AI. Always trust your own mind before trusting AI. The problem was hx-trigger . I also had problems applying CSS through HTMX. In the end, I solved it by using hx-redirect . But in the end everything works (you can see it one the phtoto) I also worked on the scenario system, which loads scenarios from a JSON file. It isn’t tested yet, and I still need to work on state snapshots. The idea is that you’ll be able to save a moment in time and restore it later, so you can test the same scenario as many times as you want without setting up all the data again. I also started working on a companion app to showcase the differences between my implementation and the official demo car sandbox. I’ll write more about it in the next devlog."}, {"post_id": 24338, "ts": "2026-07-07T20:58:43Z", "hours": 3.7069, "text": "Devlog A small error from the last devlog: it’s PKCE , not PCKE . I had to rename a lot of variables because of that. More customizable data Gearbox Model year More diagnostic data for lights (hazard, fog, brake, high beam, low beam, and more) Other additions Added a new default API key with 3 cars, each having different values. Wrote more docs. Started working on scenarios (templates for new or existing cars to make setup faster). I’m thinking about loading them from a file so users can create their own. Started working on setting up OAuth2 through the dashboard. Fixed most command responses because when I first created them, I forgot to wrap everything inside { \"data\": {} } . Added light options to the dashboard. Working: PKCE How does it work? The application generates a random secret. Before redirecting the user to the login page, it sends only a hashed version of that secret. After the user logs in, the application receives an authorization code. When exchanging the code for tokens, it sends the original secret. The server checks whether it matches the previously received hash. If it does, the tokens are issued. It normally protects from having the tokens stolen New promoting picture I made in canva have a look"}, {"post_id": 23100, "ts": "2026-07-05T20:54:08Z", "hours": 3.3289, "text": "Devlog Small additions to the new documentation. changes how the api handles errors BIG ADDITION OAuth2 without PKCE. I started working on PKCE, but I thought I should write a devlog before adding it. Added a login website (I know I mentioned it last time). Added a way to enable and disable OAuth2. Authentication now checks whether OAuth2 is enabled. If it is, requests are authenticated using OAuth2. Tokens don’t expire yet, but that will be added soon. Added endpoints for refreshing tokens and exchanging an authorization code for tokens. How does OAuth2 work? The app redirects the user to a login page. After logging in, the website redirects the user back to the callback URL provided by the app. The app receives an authorization code, which it exchanges for two tokens: a long-lived refresh token and a short-lived access token. When the access token expires, the app can use the refresh endpoint to obtain a new access token. What is PKCE? I’ll write more about it once it’s added to the project. In short, PKCE protects the authorization flow by ensuring that only the application that started the login process can exchange the authorization code for tokens. The application first generates a random secret (called a code verifier). Before the login request is sent, a hashed version of that secret (the code challenge) is sent to the server. Later, when exchanging the authorization code for tokens, the application sends the original secret. The server verifies that it matches the previously received hash before issuing any tokens. I’ll explain the complete flow in the next devlog."}, {"post_id": 20221, "ts": "2026-07-01T19:28:27Z", "hours": 5.3022, "text": "Devlog This devlog will be a short one because I’ve been focusing on implementing OAuth 2.0. I’ll cover that in more detail in the next update but I will add photo of a “login” screen that I created for it (it looks bad on purpose). What’s new The terminal now works with more than one static car. The dashboard can (once again) create new cars. The codebase has been split into multiple files instead of a single large file: main still contains the public API endpoints. internal contains the dashboard logic and internal API endpoints. database will contain multiple predefined car scenarios. I also started writing a new manual that documents the quirks of the Volvo API and my implementation ( and edge cases). I will write more about in next 2 devlogs What’s left before the first ship An example application demonstrating the differences between the official Volvo Sandbox and this project. OAuth 2.0 with PKCE (it would be great to have before the first ship). Documentation. A major code cleanup and refactoring."}, {"post_id": 17924, "ts": "2026-06-28T21:18:15Z", "hours": 2.7358, "text": "Devlog I added two static (for now) endpoints: statistics and warning . The statistics endpoint mostly returns data, so there isn’t much to test. The warning endpoint has a very large response that would require a lot of new code, and for now I don’t want to implement all of it. I started working on adding cars through the dashboard (you could already see part of it in the last devlog), but I found out it doesn’t work, so I need to fix it before the next devlog. Climate and engine STOP commands now respond correctly. In the last invoice update, they incorrectly returned RUNNING . Added checks for the new command endpoints to verify whether the car supports a given command. Added a small terminal page that outputs changes. In the future, you’ll be able to choose whether to display only Volvo changes, all changes, or all information (for example, if you checked whether the windows status). I also used it to verify that the normal WebSocket status works. Added the foundations for disabling WebSockets on startup. Only a configuration file is left to implement. Added UNAVAILABLE reason invoice logic mostly something like this: If the reason is NO_INTERNET , the invoice becomes CONNECTION_FAILURE . If the reason is POWER_SAVING_MODE , the invoice becomes VEHICLE_IN_SLEEP . Made some improvements to the dashboard’s appearance."}, {"post_id": 15774, "ts": "2026-06-25T17:19:10Z", "hours": 7.1422, "text": "Devlog A funny story: I built the invoice system but didn’t always assign values correctly, so the values got mixed up. I spent a long time debugging before realizing that was the cause. { \"error\" : { \"message\" : \"VALUE_ERROR\" , \"description\" : \" \\\" Car \\\" object has no field \\\" 123 \\\" \" } } I also spent a lot of time on CSS. Most of that time went into learning: classes IDs box shadows CSS Grid The reason it took so long since the last devlog is CSS. As I said before, I don’t really like web development, so my motivation was pretty low. I used some AI, but I worked hard to remove most of the generated code. At this point, most of the site’s design looks the way I want it to and will probably stay that way until the end of the project. Made invoices have some logic instead of always sending the same value. That means: If no invoice status is set, it sends COMPLETED or RUNNING depending on whether the engine or climate is running. Loc like actions can’t have a RUNNING invoice status. Added a distinction between successful and failed invoices. PS: Always remember to stop the server with Ctrl+C , not Ctrl+Z , because Ctrl+Z can leave the process running and keep the port blocked."}, {"post_id": 14241, "ts": "2026-06-23T07:56:55Z", "hours": 6.0522, "text": "Devlog It has been a long time since my last devlog, but I was more focused on learning than adding new stuff. Right now, I am focusing on learning HTML, htmx, and Jinja. The welcome page logic is mostly working. I had some problems with it because I used htmx to add new code, but the JavaScript from the is not reloaded with that. Now, I use the HX-Redirect response. I also learned how WebSockets work with FastAPI and htmx. I also designed how the dashboard will look (I attached my drawings. Good luck reading them!)."}, {"post_id": 11274, "ts": "2026-06-18T13:16:22Z", "hours": 3.5742, "text": "Devlog centralLock is called carLocked in the docs. The docs seem to be outdated. I think the OpenAPI specification is more accurate and contains fewer errors. I added a way to validate data using class functions. Implemented timestamps. Using datetime function from python Added tyre endpoints. Added a way to generate new API keys and create new cars (I used python secrets). (getting ready to make first public running version) Roadmap.md file with status of this project What is next to do Start using the updated method for changing data. Update the dashboard to reflect and modify the new data. Add WebSocket support. Add the remaining 2 vehicle and warning endpoints. Create an example app for testers. Redesign dashboard. It looks awful I had a 2 days off because I was on school trip but I back. Next thing on my list is an updated dashboard"}, {"post_id": 9202, "ts": "2026-06-15T13:28:28Z", "hours": 1.9225, "text": "Devlog You can edit data through the dashboard now. It’s not the best solution, and I want to change how it works (probably start from scratch), but not now. Diagnostics endpoints. I had a very good time with them today. Why? Because of the “/diagnostics” docs. I attached a screenshot showing an example from the official website and data from a real car (left: real API, right: docs). If you look at them, you can see two errors and one very small issue that you would only notice if you read the whole documentation: In serviceWarning, you can see the value is NORMAL, but NORMAL is not a valid value for it. It should be NO_WARNING. This is the small one. In engineHoursToService, the API response contains a unit, but the docs don’t mention it at all. And the worst one (and the only real error): there is no information about washerFluidLevelWarning in the docs, but it appears in the data from the car. What do you think I should do? Should I write to them about it? I think you can comment on the post, so let me know what you think."}, {"post_id": 8961, "ts": "2026-06-14T22:15:21Z", "hours": 1.7606, "text": "Devlog Added odometer and fuel endpoints. Funny thing is that Volvo sends in what unit the data is, but the docs say that only metric units are valid, so it really sends always the same unit. Most likely they wanted to add imperial later, or they left it like this for simplicity. Added first version of dashboard. For now, it’s using polling every 5 seconds (I have planned to change it to WebSocket). It only displays some information and can’t edit anything. Also, I wrote some HTML and JavaScript. I never liked web development, so I don’t know a lot (I’m learning while I code 😅). It could be that it will look very rough till the end because I don’t have any patience for HTML and CSS. I “will” do it when I have a very good day, or AI will do it? I would like not to use AI in this way, but I will see. Edit: Forgot to push the updated version to GitHub I will do it tomorrow because it’s late (it’s tomorrow )"}, {"post_id": 8322, "ts": "2026-06-13T20:45:50Z", "hours": 2.8264, "text": "Devlog Added a command accessibility endpoint (it tells if the car can receive commands). I refactored duplicate code in the climate endpoint. Added engine endpoints (they aren’t perfect, but this isn’t the final code). It was also a frustrating day because I repeatedly forgot to save my code before testing (my bad). A photo of the error that cost me way too much time today. (I changed it to “/vehicles/{VIN}/engine-status”, but I didn’t save the file.)"}, {"post_id": 7410, "ts": "2026-06-12T10:41:57Z", "hours": 0.9136, "text": "I setup my codespace and started working on first few endpoints. Additionally I looked how most of Volvos apis looks that gave me direction to go. That was all time I had today. Also I could add screenshot here because of macOS :("}]...
|
Title: Volvo API playground by @Kl | Stardance
De Title: Volvo API playground by @Kl | Stardance
Devlogs:
I setup my codespace and started working on first few endpoints. Additionally I looked how most of Volvos apis looks that gave me direction to go. That was all time I had today. Also I could add screenshot here because of macOS :(
Devlog Added a command accessibility endpoint (it tells if the car can receive commands). I refactored duplicate code in the climate endpoint. Added engine endpoints (they aren’t perfect, but this isn’t the final code). It was also a frustrating day because I repeatedly forgot to save my code before testing (my bad). A photo of the error that cost me way too much time today. (I changed it to “/vehicles/{VIN}/engine-status”, but I didn’t save the file.)
Devlog Added odometer and fuel endpoints. Funny thing is that Volvo sends in what unit the data is, but the docs say that only metric units are valid, so it really sends always the same unit. Most likely they wanted to add imperial later, or they left it like this for simplicity. Added first version of dashboard. For now, it’s using polling every 5 seconds (I have planned to change it to WebSocket). It only displays some information and can’t edit anything. Also, I wrote some HTML and JavaScript. I never liked web development, so I don’t know a lot (I’m learning while I code 😅). It could be that it will look very rough till the end because I don’t have any patience for HTML and CSS. I “will” do it when I have a very good day, or AI will do it? I would like not to use AI in this way, but I will see. Edit: Forgot to push the updated version to GitHub I will do it tomorrow because it’s late (it’s tomorrow )
Devlog You can edit data through the dashboard now. It’s not the best solution, and I want to change how it works (probably start from scratch), but not now. Diagnostics endpoints. I had a very good time with them today. Why? Because of the “/diagnostics” docs. I attached a screenshot showing an example from the official website and data from a real car (left: real API, right: docs). If you look at them, you can see two errors and one very small issue that you would only notice if you read the whole documentation: In serviceWarning, you can see the value is NORMAL, but NORMAL is not a valid value for it. It should be NO_WARNING. This is the small one. In engineHoursToService, the API response contains a unit, but the docs don’t mention it at all. And the worst one (and the only real error): there is no information about washerFluidLevelWarning in the docs, but it appears in the data from the car. What do you think I should do? Should I write to them about it? I think you can comment on the post, so let me know what you think.
Devlog centralLock is called carLocked in the docs. The docs seem to be outdated. I think the OpenAPI specification is more accurate and contains fewer errors. I added a way to validate data using class functions. Implemented timestamps. Using datetime function from python Added tyre endpoints. Added a way to generate new API keys and create new cars (I used python secrets). (getting ready to make first public running version) Roadmap.md file with status of this project What is next to do Start using the updated method for changing data. Update the dashboard to reflect and modify the new data. Add WebSocket support. Add the remaining 2 vehicle and warning endpoints. Create an example app for testers. Redesign dashboard. It looks awful I had a 2 days off because I was on school trip but I back. Next thing on my list is an updated dashboard
Devlog It has been a long time since my last devlog, but I was more focused on learning than adding new stuff. Right now, I am focusing on learning HTML, htmx, and Jinja. The welcome page logic is mostly working. I had some problems with it because I used htmx to add new code, but the JavaScript from the is not reloaded with that. Now, I use the HX-Redirect response. I also learned how WebSockets work with FastAPI and htmx. I also designed how the dashboard will look (I attached my drawings. Good luck reading them!).
Devlog A funny story: I built the invoice system but didn’t always assign values correctly, so the values got mixed up. I spent a long time debugging before realizing that was the cause. { "error" : { "message" : "VALUE_ERROR" , "description" : " \" Car \" object has no field \" 123 \" " } } I also spent a lot of time on CSS. Most of that time went into learning: classes IDs box shadows CSS Grid The reason it took so long since the last devlog is CSS. As I said before, I don’t really like web development, so my motivation was pretty low. I used some AI, but I worked hard to remove most of the generated code. At this point, most of the site’s design looks the way I want it to and will probably stay that way until the end of the project. Made invoices have some logic instead of always sending the same value. That means: If no invoice status is set, it sends COMPLETED or RUNNING depending on whether the engine or climate is running. Loc like actions can’t have a RUNNING invoice status. Added a distinction between successful and failed invoices. PS: Always remember to stop the server with Ctrl+C , not Ctrl+Z , because Ctrl+Z can leave the process running and keep the port blocked.
Devlog I added two static (for now) endpoints: statistics and warning . The statistics endpoint mostly returns data, so there isn’t much to test. The warning endpoint has a very large response that would require a lot of new code, and for now I don’t want to implement all of it. I started working on adding cars through the dashboard (you could already see part of it in the last devlog), but I found out it doesn’t work, so I need to fix it before the next devlog. Climate and engine STOP commands now respond correctly. In the last invoice update, they incorrectly returned RUNNING . Added checks for the new command endpoints to verify whether the car supports a given command. Added a small terminal page that outputs changes. In the future, you’ll be able to choose whether to display only Volvo changes, all changes, or all information (for example, if you checked whether the windows status). I also used it to verify that the normal WebSocket status works. Added the foundations for disabling WebSockets on startup. Only a configuration file is left to implement. Added UNAVAILABLE reason invoice logic mostly something like this: If the reason is NO_INTERNET , the invoice becomes CONNECTION_FAILURE . If the reason is POWER_SAVING_MODE , the invoice becomes VEHICLE_IN_SLEEP . Made some improvements to the dashboard’s appearance.
Devlog This devlog will be a short one because I’ve been focusing on implementing OAuth 2.0. I’ll cover that in more detail in the next update but I will add photo of a “login” screen that I created for it (it looks bad on purpose). What’s new The terminal now works with more than one static car. The dashboard can (once again) create new cars. The codebase has been split into multiple files instead of a single large file: main still contains the public API endpoints. internal contains the dashboard logic and internal API endpoints. database will contain multiple predefined car scenarios. I also started writing a new manual that documents the quirks of the Volvo API and my implementation ( and edge cases). I will write more about in next 2 devlogs What’s left before the first ship An example application demonstrating the differences between the official Volvo Sandbox and this project. OAuth 2.0 with PKCE (it would be great to have before the first ship). Documentation. A major code cleanup and refactoring.
Devlog Small additions to the new documentation. changes how the api handles errors BIG ADDITION OAuth2 without PKCE. I started working on PKCE, but I thought I should write a devlog before adding it. Added a login website (I know I mentioned it last time). Added a way to enable and disable OAuth2. Authentication now checks whether OAuth2 is enabled. If it is, requests are authenticated using OAuth2. Tokens don’t expire yet, but that will be added soon. Added endpoints for refreshing tokens and exchanging an authorization code for tokens. How does OAuth2 work? The app redirects the user to a login page. After logging in, the website redirects the user back to the callback URL provided by the app. The app receives an authorization code, which it exchanges for two tokens: a long-lived refresh token and a short-lived access token. When the access token expires, the app can use the refresh endpoint to obtain a new access token. What is PKCE? I’ll write more about it once it’s added to the project. In short, PKCE protects the authorization flow by ensuring that only the application that started the login process can exchange the authorization code for tokens. The application first generates a random secret (called a code verifier). Before the login request is sent, a hashed version of that secret (the code challenge) is sent to the server. Later, when exchanging the authorization code for tokens, the application sends the original secret. The server verifies that it matches the previously received hash before issuing any tokens. I’ll explain the complete flow in the next devlog.
Devlog A small error from the last devlog: it’s PKCE , not PCKE . I had to rename a lot of variables because of that. More customizable data Gearbox Model year More diagnostic data for lights (hazard, fog, brake, high beam, low beam, and more) Other additions Added a new default API key with 3 cars, each having different values. Wrote more docs. Started working on scenarios (templates for new or existing cars to make setup faster). I’m thinking about loading them from a file so users can create their own. Started working on setting up OAuth2 through the dashboard. Fixed most command responses because when I first created them, I forgot to wrap everything inside { "data": {} } . Added light options to the dashboard. Working: PKCE How does it work? The application generates a random secret. Before redirecting the user to the login page, it sends only a hashed version of that secret. After the user logs in, the application receives an authorization code. When exchanging the code for tokens, it sends the original secret. The server checks whether it matches the previously received hash. If it does, the tokens are issued. It normally protects from having the tokens stolen New promoting picture I made in canva have a look
Devlog How I don’t like web development… did I already say that? I’ll say it again. I’m working on the OAuth2 settings, and I had a problem where one of the query parameters wasn’t reaching the backend. I still don’t know what actually fixed it. Then I had another problem. I have a function that changes values in the backend, but only one button worked while everything else didn’t. It turned out to be because I debugged the first problem with AI. Always trust your own mind before trusting AI. The problem was hx-trigger . I also had problems applying CSS through HTMX. In the end, I solved it by using hx-redirect . But in the end everything works (you can see it one the phtoto) I also worked on the scenario system, which loads scenarios from a JSON file. It isn’t tested yet, and I still need to work on state snapshots. The idea is that you’ll be able to save a moment in time and restore it later, so you can test the same scenario as many times as you want without setting up all the data again. I also started working on a companion app to showcase the differences between my implementation and the official demo car sandbox. I’ll write more about it in the next devlog.
Devlog Writing documentation is a good way to check whether the code you wrote actually works. I already found four bugs while documenting the project. For example, I forgot to pass the redirect URI in a function in main.py , even though it was already implemented in internal.py . I also fixed a bug where notifications could sometimes contain an older value. The dashboard has been moved into a separate file. Snapshots currently have a problem. They are very similar to the Car class, so I’ll debug it and explain what the issue was in the next devlog. Companion app The companion app is meant to showcase the differences between my implementation and the official Volvo Demo Car Sandbox. It also makes testing easier, since you don’t have to write your own application just to try the API. I had a problem with the built-in LibreSSL because one of the dependencies didn’t support it. I had to reinstall Python so that uv would detect the new OpenSSL installation. After that, I was finally able to start the app and get it working. Auto-login and automatic creation of a test car are now working. There’s is no css but I will do it after logic works One more thing: the reason the devlogs have been quieter recently is that I’ve been dealing with some administrative paperwork. I’ll get back to posting them more regularly once that’s sorted out.
Devlog Authorization was my mistake. It should have been accessToken , not Authorization . Why I thought that? I have no idea. No it was good before I was sleepy I think when I did that The snapshots system now works. Why it didn’t work as expected: I forgot to use copy(deep=True) . One of the small dictionaries was written incorrectly. Added saving and loading snapshots from a file. The scenarios system now works and has been tested. Difference between snapshots and scenarios Snapshots copy all data about a car. They are persistent and can be saved to a file. Scenarios only change selected attributes. They are designed to be created and edited manually in a JSON file. Main app The main app is mostly ready. Before the first release, I still need to: Finish the documentation. Add a roadmap with future updates. Verify error responses against the real API. Finish the comparison feature in the companion app. Add more ready-to-use scenarios and API keys. Companion app Manual login now works, so only the comparison logic is left. I found a bug where api_key_p was None because one endpoint redirected using api_key instead. Started working on the comparison feature. PS: A photo of why the api_key_p was none
A public online demo!!!!! The project is finally available online! https://playground.kls.hackclub.app/internal/welcome Please don’t be the bad guy and fight with other people over access. ❤️ That’s all I wanted to say because this is a really big milestone for me. There will also be another commit today to make sure everyone can run their own instance of the project. I found a few issues that only appeared outside of my local environment: Some WebSocket features break when using HTTPS. The dashboard had problems when the instance wasn’t running on the same computer. Those should be fixed in today’s commit. If you find any errors please comment or contact me on slack Also thanks to nest hackclub for hosting
Devlog Companion app Added manual mode for comparison. Engine start/stop now works in normal mode. Before pushing, I forgot to fix one thing: { "error" : "Failed to retrieve data from unofficial API." , "detail" :{ "detail" :[{ "type" : "dict_type" , "loc" :[ "body" ], "msg" : "Input should be a valid dictionary" , "input" : "{ \" runtimeMinutes \" : 10}" }]}} The fix was simple: I forgot to use json.loads() . I pushed a quick fix commit right after. The photo shows the manual comparison page. I’m still working on the comparison logic, which is why it doesn’t have any CSS yet. Sorry for not adding Volvo API keys so you can see the differences between both APIs, but that would have taken too much time today. Its also the reason why Im creating this app Main app Worked on the documentation. The notifier now supports more than one updated attribute at the same time. It’s not the best implementation, but I’ll improve it after the first ship. Fixed snapshot loading and added exception handling. Scenario loading now reports malformed JSON files. Fixed a dashboard bug where tire information was shown three times. I think I planned to add more data there… and then forgot. I should probably test everything before making a devlog or committing, but I also don’t want my devlogs to have to much time.
Devlog I’m mainly focused on finishing the companion app. I started working on the CSS. Most of my time was spent learning Tailwind CSS (so I didn’t track it). I think it’s a better fit for me than writing plain CSS. Added Tailwind CSS to all pages of the companion app. (I think I need to redo the main app now. 😅) Added a small README with information about the main app. I think it done now but I will come back to it before first ship Main app While working on the companion app, I found another issue. The Content-Type: application/json behavior doesn’t match the official API. I verified that the official API works as expected, checks for it mine doesn’t (I think)
Devlog Companion app I said it was finished for now, but I forgot to add one more thing (the one on the left in the screenshots): a dashboard redirect. Main app I’m still investigating the Content-Type problem. I verified that the official Volvo API behaves correctly, so I’m working on matching that behavior. Added work-in-progress Content-Type checks. Started reworking the CSS using Tailwind CSS. It’s still mixed with some plain CSS for now. Enabled support for the reduced guard lock command. You have to manually mark it as supported, and for now it behaves the same as the normal lock command. Let me know which design you like more: the new one (center) or the old one (right).
Devlog I don’t know if I mentioned it before, but for now the Content-Type checks are disabled. I need to learn more about them and implement better validation. Created an updated OAuth2 settings page and a car selection screen (with Tailwind CSS, of course). Started experimenting with a new dashboard. It’s still a work in progress, but it will most likely become the main design. I’m also thinking about adding a second dashboard style, although I’m not sure if I’ll do that before the first release. I definitely want to clean up the HTML/Tailwind code by moving repeated styles into reusable classes or something similar. I’m also thinking about using more HTMX so that more pages can update data without needing a full page reload. Wrote more documentation. I still need to verify the fuel endpoint because I don’t remember whether it handles different engine types correctly. ( The new OAuth2 settings page and the car selection screen. For next develop I think I will make a video of how everything works)
Devlog Most of my time was spent working on the dashboard with Tailwind CSS. It took a lot of experimenting to find a design I actually like. I also changed how HTMX updates the dashboard through WebSockets. Before: A dedicated template was rendered every time to update that part of the dashboard. Now: Only the text containing the updated value is replaced. That said, in the future it won’t always be just text. For example, if the fuel type changes from hybrid to electric , the fuel level should disappear from the dashboard instead of just changing its value. While working on this, I found a bug caused by HTMX sending boolean values as strings. This caused climate settings to be marked as invalid. I need to distinguish between an invalid value and an invalid attribute instead of always treating the entire attribute as invalid. Note to myself Add transitions. Make all HTML pages use the same CSS file from now on. Update the version on nest server and make a public companion instance Aaand that’s all. Making websites is painfully slow.
Devlog I found another way to hide the fuel stat when it isn’t useful for a particular type of car: the HTML hidden attribute. At first, I thought I should add or remove the element hidden, but that turned out to be more complicated than I expected. I think using hidden is still a cleaner solution but I still using templates files. While working on the dashboard, I wanted to add units like km , L , and % to some values. Instead of handling that in Python, I added another div with some margins and, in a few places, used flex so everything stays on the same line without adding more backend logic. Added more page changes thru HTMX (nearly all pages use it). Creating a new car now refreshes the page. when an error occurs, I use HX-Reswap and the HX-Retarget response header (when creating new car as proof of concept). Added HTMX transitions to the OAuth2 settings page.(all pages have transitions) What to do before the first release (Mostly a checklist for myself 😅) Content-Type checks. Scenario and snapshot system support in the dashboard. Main showcase page. Finish the remaining documentation. Two READMEs: one for the main repository and one for the companion app repository. I’m thinking about having one technical README and another one that’s easier to understand for people who don’t code. Better error handling in the dashboard. Right now, most errors are just displayed as plain text instead of being part of the page. deploy updated version on nest I wanted to add a video but MacOS made me a half gig and I don’t think stardance would handle
The comparison app is now online! Comparison app: https://compareplay.kls.hackclub.app/ I also updated the main app with the new dashboard design: https://playground.kls.hackclub.app/internal/welcome devlog Tailwind CSS is no longer loaded from the CDN. I think its now precompiled. Note to others: Remember to update your banner to feature your app (see #stardance on Slack). Otherwise, your ship will be rejected. EDIT: A lot of bots try to connect to my apps do you think I should make a honeypot?
Devlog The Content-Type problem is SOLVED …… What was the problem? (My reading skills? ) there are two headers with application/json : Content-Type (POST) Accept (GET) The Accept header isn’t required ( can be */* , application/* or application/json ). So the Content-Type mystery is mostly FIXED but I still need to check with a real Volvo car if Content-Type is actually required. (I’ll do it tomorrow.) Changes: Accept is now handled by my API like in the official API. Added Content-Type checks (like the docs say, meaning it’s required). While proofreading the docs, I found that PKCE is written as PCKE in one internal endpoint. (Not fixed yet.) Small README update (I try to keep it up to date). Scenario page: You can now load a scenario using the GUI. Recompiled the Tailwind CSS. I attached screenshots showing it (you can also see snapshot button but its not implemented YET)
Devlog Snapshots loading page (screenshots while I worked. I had more but the limit was 4). As suggested by the Tailwind CSS tools, changed some classes to more canonical ones. You can now delete cars through both the API and the dashboard. Snapshot corruption (when the app is force quit) should be fixed. Started working on the landing page, but I’ll leave it for the next devlog (mostly because I have on my other laptop). Fixes to do Sometimes the new OAuth2 and Snapshots buttons are off-center. Compare app needs fixing (need to enable the Content-Type fix from the official API). PKCE spelling in the internal API.
Devlog I had a problem when I wanted to rewrite the scenario system. It only changed the local version of the Car (It means it really didn’t update anything). I wanted to update a backup version first, and only if everything was correct, replace the original with the backup. In the end, I used an already created function to first test and then apply to the car . Main PKCE misspelling fixed. Added a landing page with an option to disable it and redirect directly to the login screen (like in the last devlog I have photos of making it). Worked on the lights section. Fixed the docs URLs. Dashboard and WebSocket toggles now work. Rewrote and enabled the updates endpoint. Validation now catches values that can’t be converted to int . Scenario loading into a car instance should now be more consistent with the other functions. Improved mobile responsiveness (and then fixed the desktop one). Some elements were outside the screen on mobile (nothing important, but it didn’t look good). NOTE: the dashboard with car attributes still needs to be adapted. Added windows (because I forgot to 😅) to the dashboard and organised the lighting section. OAuth2 and Snapshots buttons should now always be centred. TODO Debug and tracing headers (from the real API). Additional instructions. Then I think it’s finally ready for the first ship. There are still a lot of things I want to add, but I can’t work indefinitely. Compare The compare app now has the Content-Type fix enabled (like the official API). Compiled the Tailwind CSS for the compare app. NOTE: I will add here more screenshots as link later Also thinking about adding it frictionless mission but I’m not sure.
Devlog Tracking headers implemented : There are two vcc-api-operationId - UUID traceparent - W3C traceparent (for now only sends it back) dashboard should look good on small screen (its very long but I don’t want to redesign it now) This is the reason why I there is much time in this devlog. It was a lot of try and error before something looked good both on mobile and desktop and I liked it . But at least it works know 🙃. some small cleanup of comments I worked again on internal updates endpoint (hopefully works now) started working on pytests (but I will talk about in next devlog (I gave my self 2 days for it) I really want to get the first ship out, so it isn’t going to be perfect. I still have a lot of features and improvements I’d like to add.
Devlog Working hard on pytest tests. I learn how assert works and how to name . I never used or created test in any language so I think they aren’t perfect (not like they should),but they work😄. I looked like AI made few and how other people and read some stuff online Tests created for these endpoints Around 25 of them List cars About car Engine info Engine start/stop Climate start/stop Windows Doors Lock/Unlock Reduced Guard Lock Flash, Honk, and Combination Tyres Statistics Fuel Odometer Engine diagnostics Brakes Command accessibility Still to do Warnings and diagnostics Commands More changes The tests helped me find and clean up several issues: Documentation updates. The honk endpoint was ../horn but should be /honk . Some values ( odometer , fuel ) are int , just like in the OpenAPI specification, not as described in the official docs. Fixed spelling mistakes: - oillevel to oilLevel - coolantLever to coolantLevel Want to help and has access to volvo with active VOC I need to test engine and climate endpoints but I don’t have an access to a car with it. Soooo if you can contact me on slack
Devlog I forgot to add that I worked on the tests in the test branch, not the main one. OAuth2 PKCE testing. Helped me find an error where, if the code was used (it was reset to "" ), it was accepted as "" . Now it correctly returns an error. OAuth2 flow testing. Warnings and diagnostics now have some simple checks too. And I merged it into main . Then I started cleaning up the Tailwind CSS. NOTE: they are in new branch dashboard/cleanup Why? Because I used the Play CDN in the past, so I couldn’t create utility classes in a CSS file. Soooo I didn’t. Andddd there were a lot of Tailwind classes that didn’t fit on my screen. Now that I started precompiling it, I could add them. I added 5 unique utility classes. All of them combined are used around ~120 times across all HTMLs. The longest one: @utility inputSelection { @apply w-full px-4 py-2 .5 bg-zinc-950 border border-zinc-800 rounded-xl text-zinc-100 focus : outline-none focus : ring-2 focus : ring-blue-300 focus : border-transparent transition-all appearance-none text-center [ text-align-last : center ] cursor-pointer ; } I also minified the CSS file. If I understand it, it removes anything the browser doesn’t need to understand the CSS (new lines, unnecessary spaces…). It’s better because those characters are still sent over the network, and fewer bytes mean less traffic. While using the new utility classes, I tried to preserve the layout, so everything should look the same as before.
Devlog SITE changes I found that some number inputs didn’t use the utility classes. I gave them inputText because they are really the same; the only difference is the HTML type . I also forgot to update the reloadable fuel section. It now uses the shorter utility class. Made sure that all text in the header is the same size (they weren’t). I copied all changes back to the main branch. config changes Then I added a config file using the configparser library. also added an option to disable the FastAPI docs. I started working on Wiki: reworking docs.md into a GitHub Wiki with up to date information. Error logger, so you can see what’s wrong without printing the API response in your code. I had some problems with catching the fastapi automatic response but I will leave it for next devlog
Devlog There was a small (or big) problem in my playground. If an error was returned in the response, you could only see it if your app handled it or by printing the response. That’s why I added an error logger. It can show errors in two ways: Terminal Log file How it works There were two ways of doing it (from what I learned): Middleware that captures all responses (this could be helpful in the future). Exception handlers (this is what I chose). I use two handlers: @app.exception_handler(RequestValidationError) @app.exception_handler(HTTPException) It was a horrible time searching for why it didn’t work. At first, I worked in a separate file, but I couldn’t get the (fastapi) app variable into those functions. So I copied them into main file to make them work first. I had to change some JSON responses to HTTPException to make the second handler work. After I captured the first request and printed it, I worked on one function that writes a log and another that prints to the terminal. I also created a class to store useful data. It works like this: Exception handler-> ->Put data into class -> ->Create response -> ->Return response ->Create a background task that logs the error I create a background task so the response doesn’t wait or even worse fails In the end I found that I can wrap these func with this simple func to make them work in different file def setup_error_logging(app: FastAPI): Added a config option: To disable it completely. To disable only the log file. It also bypasses all internal endpoints to make the logs more readable. The best fail… 😅 I returned an exception instead of raising it. I spent a good 15 minutes wondering why the response had status code 200 with a JSON body saying status code 400 . response changes I also checked how the authorization errors look and added two new ones: Missing Authorization header. Invalid vcc-api-key header. WIKI (not counted) I focus on making a GitHub wiki (new docs) After ending them and the error logger. Its time for the first ship !!!!!!! Nest instability: I made a backup server : https://frog01-21185.wykr.es/ Its not ideal one, bc some asian countries are blocked but its shouldn’t have any downtime (I hope so) If an Admin read it why I must copy enter from different text input 😭
Devlog Error logger added colors to the terminal print out using: \033[31m \033[0m Good to know that it is so easy to add colors to text added timestamps to log file and - between errors Changes how it reads body once again and fixed url encoded requests logging My additional information I put in detail in the json response (the real API can send it like that buttty I didn’t see it. info from docs ) additional changes: New scenarios mostly about service warnings You can add notes to the website thru config files Scopes I started working on scopes. What are they? They are really permissions (you can know them from discord bots or if you login thru GitHub etc.) I don’t want to put them in this first ship but I needed to work on something (while I work on wiki) and I CAN’T guarantee every thing works after adding them. You can see it in the scopes branch. what is done: I have made preparation so the additional database (dict) I use for OAuth can store more data have updated website func to work with changes and also pytest added all possible conve (connectivity API) scopes WIKI when I add everything to them I will finally try making a ship added the error logger page updated the sidebar scenario and snapshots page a lot of misc Bonus photos from vacation on baltic sea
Long time no see… The school started aaand I didn’t have time I had low motivation The only thing to do before first ship is docs but I could find time to finish them. Buut I back now. AND I promise to ship it before 7 of September. If you are voting on this project PLEASE do not skip. I have my birthday coming and if the shipwrights doesn’t have a long list it could mean this project payout could be my birthday gift. If I ofc ship it 😅 devlog Small marketing changes everywhere to say that this project doesn’t have any ready code to use Added info about error logger on the landing page Scopes A long way from last devlog Fixed pytest ( A second time) TEMPORARY FIX added so the scope error doesn’t - throw just internal error FIXed the Oauth2 endpoint at least 3 times Added a WIP endpoint to edit scope data from API Fixed how cars are created so they work with both - Oauth and scopes stuff Only looking dashboard page for scopes compare I think I forgot to say something in last devlog config file if you would like to use different instance Toml oillevel to oilLever AI disclaimer that I used this project to learn tailwind Make the doors have different statuses in mean time Untracked WIKI Redo the home page Started working on stardance path A lot of misc that I don’t remember other I created a small modified volvo example app to show that my app works like the real one
Devlog MAIN added a startup baner fixed snapshots not saving if website was used scope If you didn’t follow from start this branch contains the experimental scope support which is mostly done but I can guarantee stability that’s why it isn’t pushed to main in fist ship made the scope page work added a back button added button to scope on main page fixed snapshots loading/saving
Read till the end PLEASE 🥺 Devlog A lot of changes from the last devlog only 5 hrs Mostly bc I add stuff on top of but I will suffer in the future (See dev branch for these changes) Change all connectivity API to start with /connected-vehicle/v2/ to make room for different APIs After that I fixed pytest to reflect that I added a location API with a ONE endpoint There were few iterations Added scopes for this API location:read If I remember correctly Unique error responses (because location error look like old (v1) connectivity API Fixed that operationID could be a constant Added a config option to use longer API keys About here I Fixed the url for location api because it used the connectivity scheme Started working on energy API I added all data from it to this project In short one endpoints says what this car is capable of And the other says the values TODO: add its unique error its half done Scopes corresponding to energy API Fixed that some values and capabilities had the same name (bc of that some bool values where number so a it was important) WIP Oauth2 update: JWT tokens for access tokens WIP token can expire! what are JWT token? There consist of three parts header payload and signature The two first is important for my project the 3 isn’t . They store info about issuer, when token is active, scopes… A lot of useless data for this project or useful? We will see Life Bc of school I didn’t have a lot of time to write devlog (and write code) but I try to do my best before the end of stardance The next ship is planned for 28 September BIRTHDAY TODAY (16 September) Im celebrating my birthday 😄 If you write me a few good words It would be motivating for me.
Devlog A lot of breaking changes later and getting closer to PR and going to 2 ship Token lifetime WORKS made time when token is expired is rounded to int endpoint for invalidating token possibility for enabling expiring token for a specific token when it’s disabled for all in config file misc pytest for location and energy API fix the url for the enrgy API (it started with connectivity url not wi the energy api) cleanup import created new files to make the code more readable dashboard added location values added capabilities and values auto token generation and expiration in dashboard
Devlog A very long time no see. I have made a lot of progress on adding an SQL database. Testing on MySQL The backup server provider gives me access to one. SQL changes A lot of BIG changes. The reason why I haven’t posted for so long is that I didn’t want to post about something that doesn’t work. Created new classes to intercept data changes, both in case of direct dict changes and when going through the SQL model library. (I didn’t change much in the code, just imported it under the same name as the old database.) And it works! At the start, only reading data worked, but now it can send data back to the database. Added a regen function to make sure built-in API keys are always the same after a restart. Fixed the car creation function (but when I started storing the additional data in SQL, it broke AGAIN). Added configuration attributes. At first, just the database type, but then all the information needed to connect to a MySQL database. Fixed the scenario readconfig (wasn’t it updated in the past?). A really small number of things I added? Yes, but the amount of debugging and changing built-in functions in classes took me so long. (Could be because of school and not having time to do everything in one sitting.) But I learned how to make a dummy dict with a class, as I called it in the commit: proxy . Problems The SQL database can’t create new cars. Need to check all internal endpoints to make sure they work. Still haven’t merged the DEV branch (TODO). All information is stored in one column as JSON. It works, buuuut I don’t like it that way. Need to clean up the proxy classes. updating docs What failed this time? The second photo attached shows it. Have a look before reading more. _contains__ If you see it, congrats! But if you have a screen full of code, it’s harder to spot. It should be __contains__ , and I spent, I think, two days debugging why all in statements just didn’t work. I was so happy when I finally found it! XAMPP and Apple Silicon The manager app doesn’t open after a restart, so after consulting Google and AI, I found a command that I use: sudo /Applications/XAMPP/xamppfiles/xampp start xampp If someone is asking why I didn’t use the server provided one it just wasn’t practical for now.
Ships:
A Milestone Welcome everybody to the first ship of this project. What is this project? This project simulates how the Volvo API works. Why was this project created in the first place? So it’s easier to create and test your app that uses the Volvo API without using ready-made libraries. I can’t find the features you mentioned in the devlog? Check the scope branch or the upcoming dev branch. What I’m proud of: I learned a lot of things (this is my first big public project): Tailwind Python stuff (I started with C++) Writing documentation (Markdown) I also learned the basics of OAuth2 and how APIs work. Making a project with all the features needed to get started. I created an additional document for you, Stardancers: Stardance PATH What is still on the TODO list? More APIs Scopes docker image See the roadmap . What to see? error logger recreated endpoints dashboard web socket realtime changes internal endpints interactivity of the car...
|
1792853461.4565907
|
1792939861.4565907
|