|
33304
|
InterviewPrep AI by @Nikhilsahu | Stardance
|
Nikhilsahu
|
2
|
43.0
|
532
|
[{"ship_num": 1, "hours": 12.0, &# [{"ship_num": 1, "hours": 12.0, "multiplier": 14.84, "payout": 178, "blessing": "neutral", "text": "I worked on the first three phases of InterviewPrep AI. You can set up a mock interview, answer AI-generated questions, get feedback, and check your previous interviews from the dashboard. The hardest part was making the interview flow feel smooth and connecting all the pages together. I also spent time improving the UI and handling loading and error states. I'm happy that the project now feels like a real app instead of just a demo. Everything works together and the overall experience is much better now. Just open the website and start using it. No signup is needed. You can start a new interview, complete it, and check the feedback and history right away.", "repo": "https://github.com/Nikhil20222/interviewprep-ai/", "demo": "https://interviewprep-aii-eight.vercel.app/", "ts": "2026-07-17T03:15:14Z"}, {"ship_num": 2, "hours": 31.0, "multiplier": 11.51, "payout": 354, "blessing": "neutral", "text": "I developed my first AI-based tool called InterviewPrep AI, which helps users optimize their resumes prior to applying for internships or jobs through the use of artificial intelligence. As of right now, the application can load a user's resume, create an ATS score, perform different kinds of analysis on various sections of the resume and provide suggestions for improvement. By far, the hardest part of this project was to connect all the backend services into a cohesive process and ensure that everything works as intended. Besides that, I also put some effort into testing various formats of resumes and fixing minor bugs related to parsing and analysis of the document. I think I am the most proud of having the whole resume analysis pipeline up and running. It's no longer an AI-based wrapper, but rather something that can form a solid foundation for future projects. In case anyone would like to test the project, please, try uploading various formats of the resume (PDF, DOCX or TXT) and check how well the parser, ATS analysis and suggestions work. This is just Phase 1, while Phase 2 is already being implemented.", "repo": "https://github.com/Nikhil20222/interviewprep-ai/", "demo": "https://interviewprep-aii-eight.vercel.app/", "ts": "2026-07-10T21:37:03Z"}]...
|
[{"post_id": 25753, "ts": "202 [{"post_id": 25753, "ts": "2026-07-10T06:12:09Z", "hours": 5.0, "text": "Started working on InterviewPrep AI yesterday. I spent most of the time building the frontend for the first phase and setting up the overall structure of the project. The goal was to keep the interface simple, clean and easy to use instead of adding unnecessary design elements. Most of the core pages are now ready, so the next step is connecting everything to the backend and implementing the resume processing features."}, {"post_id": 25793, "ts": "2026-07-10T07:58:31Z", "hours": 1.0, "text": "Made some good progress on the backend today. I worked on the core services which process uploaded resumes including the file extraction pipeline, AI integration and the ATS checker. I spent some time testing out different resume formats and fixing a few things to make the flow more reliable. We now have the basic foundation of the resume analysis pipeline. Now, the next step is to connect everything to the frontend and improve the results of the analysis."}, {"post_id": 25981, "ts": "2026-07-10T15:03:53Z", "hours": 3.0, "text": "Made a lot of progress on InterviewPrep AI over the last few sessions. I finished writing the core logic for all the planned Phase 1 features, including resume upload, parsing, resume analysis, ATS scoring, and AI-powered improvement suggestions. Most of the work went into building the backend services and making sure each feature works correctly on its own. At this point, the remaining work for Phase 1 is integrating everything through the main application, testing the complete flow from upload to analysis, and deploying the project. Once the first version is stable and fully working, I’ll move on to Phase 2, which will focus on job description support, resume-to-JD matching, keyword analysis, and AI-powered resume optimization tailored to specific job roles."}, {"post_id": 26211, "ts": "2026-07-10T21:33:35Z", "hours": 1.0, "text": "Finished the first major milestone of InterviewPrep AI today! Phase 1 is now complete and the core resume analysis workflow is working end-to-end. I spent most of the time integrating the backend services, testing different resume formats, fixing edge cases, and making sure the overall flow felt smooth and reliable. What was completed in Phase 1: Resume upload (PDF/DOCX/TXT) 2.Resume parsing 3.Resume preview with extracted details 4.Resume analysis 5.ATS score generation AI-powered resume improvement suggestions The project now has a solid foundation, and I’m happy with how the first version has turned out. There are still plenty of improvements to make, but the core functionality is finally in place. Next up (Phase 2): Job description upload and parsing Resume vs Job Description match score 3.Missing skills and keyword analysis AI-powered resume optimization for specific job roles Better match reports and actionable recommendations Excited to start Phase 2 and make the project even more useful for internship and placement preparation."}, {"post_id": 27554, "ts": "2026-07-13T07:25:16Z", "hours": 5.0, "text": "Started redesigning the frontend After getting some feedback on the project, I decided to take some time to improve the overall frontend before diving into new features. The previous layout was functional, but it was too dash-boardy, with cards everywhere. Today I was mostly doing frontend restructuring before any feature changes. Things I did: I have begun redesigning the general layout Cleaned up html structure CSS brief Removed some unneeded UI elements Planned a section-by-section layout, rather than showing everything at once There were no changes in backend today. The idea is to simplify the project and make it easier to use before we move onto the resume analysis features."}, {"post_id": 27696, "ts": "2026-07-13T14:08:17Z", "hours": 5.0, "text": "Today I connected the redesigned frontend with JavaScript. Most of the work was handling user interactions and making sure different sections behave properly. Things I worked on: 1.Accordion behaviour 2.Dark mode toggle 3.Upload interactions 4.Better loading states 5.Small UI fixes while testing 6.JD Matching Still have to reconnect everything with the backend, but the frontend is now behaving the way I wanted"}, {"post_id": 27910, "ts": "2026-07-13T20:41:56Z", "hours": 0.0, "text": "I worked on some of the utility functions that handle uploaded resumes. These files aren’t very visible from the frontend, but they’re important because almost every upload passes through them. I improved the validation logic so unsupported files are caught earlier instead of failing later during parsing. I also cleaned up the temporary file handling because a few test uploads weren’t being removed properly after processing. Not the most exciting part of the project, but it’ll make the rest of the resume analysis pipeline much more reliable."}, {"post_id": 28119, "ts": "2026-07-14T06:12:26Z", "hours": 1.0, "text": "Working on resume parsing Today I focused on extracting information from uploaded resumes. I quickly realised that resumes are far less consistent than I expected. Some PDFs parsed perfectly, while others had missing spaces, broken formatting or section titles that weren’t detected correctly. Most of my time actually went into handling these edge cases instead of writing the parser itself. After a lot of testing, the extraction feels much more reliable now. Next I’ll use this parsed information for the ATS checker and resume analysis."}, {"post_id": 28155, "ts": "2026-07-14T08:39:51Z", "hours": 2.0, "text": "Today I worked on improving the ATS checker and AI suggestions. Earlier ATS score was just giving one percentage, so it didn’t feel very useful. I changed the logic so now it also tells why score increased or decreased instead of only showing a number. I also improved the keyword matching because sometimes it was matching unrelated words and giving wrong score. This part took some time because after fixing one issue another one was coming, so I had to test with different resumes to make the results more consistent. After that I worked on AI suggestions. Before, the AI was giving one big response which was hard to read. So I separated the suggestions into different sections based on resume parts. I also changed the prompts a little because sometimes AI was repeating the same advice in different words. It took a few prompt changes before I got output that looked clean and useful. Overall no big feature today, but I spent most of the time improving the quality of existing features. The ATS results and AI suggestions now feel much better than before."}, {"post_id": 28359, "ts": "2026-07-14T15:51:31Z", "hours": 4.0, "text": "Today I completed Phase 2 of the project. The main goal was to compare the uploaded resume with the job description instead of analysing both separately. At first I thought simple keyword matching would be enough, but I quickly realized it was giving wrong results. Sometimes important skills were missed because the wording was different, and sometimes repeated keywords were increasing the score even when the resume wasn’t actually relevant. I spent a lot of time improving the comparison logic and testing it with different resumes and job descriptions. The biggest challenge was finding a balance between being too strict and too lenient. After making multiple changes, the matching feels much more accurate and meaningful now. Finally, Phase 2 is complete and working well. There are still small things I can improve later, but the core resume-to-job matching system is done. From tomorrow I’ll start working on Phase 3."}, {"post_id": 28562, "ts": "2026-07-14T21:46:11Z", "hours": 3.0, "text": "Started working on the interview section After finishing the resume analysis and job description matching, I started building the interview part of the project. Today was mostly frontend work. I created the pages that will handle the complete interview flow instead of trying to fit everything onto one page. Things I worked on: Created the interview dashboard 2.Built the interview setup page Added the interview session layout Created the results page Added a navigation link so the new section is accessible from anywhere in the website Nothing is functional yet, but having the pages ready will make the backend integration much easier over the next few sessions."}, {"post_id": 28749, "ts": "2026-07-15T06:38:45Z", "hours": 1.0, "text": "Building the interview interface Spent most of time working on the styling for the interview pages. I wanted the new section to match the rest of the application instead of feeling like a completely different website. Today’s work included: Question cards Progress indicator Forms Review layout Results section Small responsive fixes I kept the styling pretty simple without adding unnecessary animations because readability is more important during an interview."}, {"post_id": 28855, "ts": "2026-07-15T12:25:04Z", "hours": 4.0, "text": "worked on JavaScript I connected the different interview pages together so the whole flow feels continuous instead of loading unrelated screens. I also spent quite a bit of time fixing small issues like: Question navigation Progress updates Form validation Button states Results rendering There wasn’t one huge bug today, but lots of smaller ones that together took longer than expected. The frontend is now smoother"}, {"post_id": 28870, "ts": "2026-07-15T13:10:38Z", "hours": 0.0, "text": "Phase 3 Complete – Mock Interview Finished Phase 3 of InterviewPrep AI today. The project started with resume analysis, then I added resume vs job description matching, and now it can also generate a complete AI mock interview based on both. What’s working now: Mock interview dashboard Interview setup page AI-generated interview questions Resume + Job Description based question generation Interview session flow AI feedback after submitting answers Final results page with overall review I also spent quite a bit of time testing the AI responses. Different models don’t always return data in the same format, so I had to handle a few inconsistent responses before everything started working properly. One thing I wanted to make sure was that the older features didn’t break while adding all this. I tested the resume analysis and JD matching flow again after integrating the interview section and both are still working fine. There are still a lot of ideas I want to add later like voice interviews, downloadable reports and interview history, but for now I’m happy with how Phase 3 turned out. The project finally feels like a complete interview preparation tool instead of just a resume analyzer."}]...
|
Title: InterviewPrep AI by @Nikhilsahu | Stardance Title: InterviewPrep AI by @Nikhilsahu | Stardance
Devlogs:
Phase 3 Complete – Mock Interview Finished Phase 3 of InterviewPrep AI today. The project started with resume analysis, then I added resume vs job description matching, and now it can also generate a complete AI mock interview based on both. What’s working now: Mock interview dashboard Interview setup page AI-generated interview questions Resume + Job Description based question generation Interview session flow AI feedback after submitting answers Final results page with overall review I also spent quite a bit of time testing the AI responses. Different models don’t always return data in the same format, so I had to handle a few inconsistent responses before everything started working properly. One thing I wanted to make sure was that the older features didn’t break while adding all this. I tested the resume analysis and JD matching flow again after integrating the interview section and both are still working fine. There are still a lot of ideas I want to add later like voice interviews, downloadable reports and interview history, but for now I’m happy with how Phase 3 turned out. The project finally feels like a complete interview preparation tool instead of just a resume analyzer.
worked on JavaScript I connected the different interview pages together so the whole flow feels continuous instead of loading unrelated screens. I also spent quite a bit of time fixing small issues like: Question navigation Progress updates Form validation Button states Results rendering There wasn’t one huge bug today, but lots of smaller ones that together took longer than expected. The frontend is now smoother
Building the interview interface Spent most of time working on the styling for the interview pages. I wanted the new section to match the rest of the application instead of feeling like a completely different website. Today’s work included: Question cards Progress indicator Forms Review layout Results section Small responsive fixes I kept the styling pretty simple without adding unnecessary animations because readability is more important during an interview.
Started working on the interview section After finishing the resume analysis and job description matching, I started building the interview part of the project. Today was mostly frontend work. I created the pages that will handle the complete interview flow instead of trying to fit everything onto one page. Things I worked on: Created the interview dashboard 2.Built the interview setup page Added the interview session layout Created the results page Added a navigation link so the new section is accessible from anywhere in the website Nothing is functional yet, but having the pages ready will make the backend integration much easier over the next few sessions.
Today I completed Phase 2 of the project. The main goal was to compare the uploaded resume with the job description instead of analysing both separately. At first I thought simple keyword matching would be enough, but I quickly realized it was giving wrong results. Sometimes important skills were missed because the wording was different, and sometimes repeated keywords were increasing the score even when the resume wasn’t actually relevant. I spent a lot of time improving the comparison logic and testing it with different resumes and job descriptions. The biggest challenge was finding a balance between being too strict and too lenient. After making multiple changes, the matching feels much more accurate and meaningful now. Finally, Phase 2 is complete and working well. There are still small things I can improve later, but the core resume-to-job matching system is done. From tomorrow I’ll start working on Phase 3.
Today I worked on improving the ATS checker and AI suggestions. Earlier ATS score was just giving one percentage, so it didn’t feel very useful. I changed the logic so now it also tells why score increased or decreased instead of only showing a number. I also improved the keyword matching because sometimes it was matching unrelated words and giving wrong score. This part took some time because after fixing one issue another one was coming, so I had to test with different resumes to make the results more consistent. After that I worked on AI suggestions. Before, the AI was giving one big response which was hard to read. So I separated the suggestions into different sections based on resume parts. I also changed the prompts a little because sometimes AI was repeating the same advice in different words. It took a few prompt changes before I got output that looked clean and useful. Overall no big feature today, but I spent most of the time improving the quality of existing features. The ATS results and AI suggestions now feel much better than before.
Working on resume parsing Today I focused on extracting information from uploaded resumes. I quickly realised that resumes are far less consistent than I expected. Some PDFs parsed perfectly, while others had missing spaces, broken formatting or section titles that weren’t detected correctly. Most of my time actually went into handling these edge cases instead of writing the parser itself. After a lot of testing, the extraction feels much more reliable now. Next I’ll use this parsed information for the ATS checker and resume analysis.
I worked on some of the utility functions that handle uploaded resumes. These files aren’t very visible from the frontend, but they’re important because almost every upload passes through them. I improved the validation logic so unsupported files are caught earlier instead of failing later during parsing. I also cleaned up the temporary file handling because a few test uploads weren’t being removed properly after processing. Not the most exciting part of the project, but it’ll make the rest of the resume analysis pipeline much more reliable.
Today I connected the redesigned frontend with JavaScript. Most of the work was handling user interactions and making sure different sections behave properly. Things I worked on: 1.Accordion behaviour 2.Dark mode toggle 3.Upload interactions 4.Better loading states 5.Small UI fixes while testing 6.JD Matching Still have to reconnect everything with the backend, but the frontend is now behaving the way I wanted
Started redesigning the frontend After getting some feedback on the project, I decided to take some time to improve the overall frontend before diving into new features. The previous layout was functional, but it was too dash-boardy, with cards everywhere. Today I was mostly doing frontend restructuring before any feature changes. Things I did: I have begun redesigning the general layout Cleaned up html structure CSS brief Removed some unneeded UI elements Planned a section-by-section layout, rather than showing everything at once There were no changes in backend today. The idea is to simplify the project and make it easier to use before we move onto the resume analysis features.
Finished the first major milestone of InterviewPrep AI today! Phase 1 is now complete and the core resume analysis workflow is working end-to-end. I spent most of the time integrating the backend services, testing different resume formats, fixing edge cases, and making sure the overall flow felt smooth and reliable. What was completed in Phase 1: Resume upload (PDF/DOCX/TXT) 2.Resume parsing 3.Resume preview with extracted details 4.Resume analysis 5.ATS score generation AI-powered resume improvement suggestions The project now has a solid foundation, and I’m happy with how the first version has turned out. There are still plenty of improvements to make, but the core functionality is finally in place. Next up (Phase 2): Job description upload and parsing Resume vs Job Description match score 3.Missing skills and keyword analysis AI-powered resume optimization for specific job roles Better match reports and actionable recommendations Excited to start Phase 2 and make the project even more useful for internship and placement preparation.
Made a lot of progress on InterviewPrep AI over the last few sessions. I finished writing the core logic for all the planned Phase 1 features, including resume upload, parsing, resume analysis, ATS scoring, and AI-powered improvement suggestions. Most of the work went into building the backend services and making sure each feature works correctly on its own. At this point, the remaining work for Phase 1 is integrating everything through the main application, testing the complete flow from upload to analysis, and deploying the project. Once the first version is stable and fully working, I’ll move on to Phase 2, which will focus on job description support, resume-to-JD matching, keyword analysis, and AI-powered resume optimization tailored to specific job roles.
Made some good progress on the backend today. I worked on the core services which process uploaded resumes including the file extraction pipeline, AI integration and the ATS checker. I spent some time testing out different resume formats and fixing a few things to make the flow more reliable. We now have the basic foundation of the resume analysis pipeline. Now, the next step is to connect everything to the frontend and improve the results of the analysis.
Started working on InterviewPrep AI yesterday. I spent most of the time building the frontend for the first phase and setting up the overall structure of the project. The goal was to keep the interface simple, clean and easy to use instead of adding unnecessary design elements. Most of the core pages are now ready, so the next step is connecting everything to the backend and implementing the resume processing features.
Ships:
I developed my first AI-based tool called InterviewPrep AI, which helps users optimize their resumes prior to applying for internships or jobs through the use of artificial intelligence. As of right now, the application can load a user's resume, create an ATS score, perform different kinds of analysis on various sections of the resume and provide suggestions for improvement. By far, the hardest part of this project was to connect all the backend services into a cohesive process and ensure that everything works as intended. Besides that, I also put some effort into testing various formats of resumes and fixing minor bugs related to parsing and analysis of the document. I think I am the most proud of having the whole resume analysis pipeline up and running. It's no longer an AI-based wrapper, but rather something that can form a solid foundation for future projects. In case anyone would like to test the project, please, try uploading various formats of the resume (PDF, DOCX or TXT) and check how well the parser, ATS analysis and suggestions work. This is just Phase 1, while Phase 2 is already being implemented.
I worked on the first three phases of InterviewPrep AI. You can set up a mock interview, answer AI-generated questions, get feedback, and check your previous interviews from the dashboard. The hardest part was making the interview flow feel smooth and connecting all the pages together. I also spent time improving the UI and handling loading and error states. I'm happy that the project now feels like a real app instead of just a demo. Everything works together and the overall experience is much better now. Just open the website and start using it. No signup is needed. You can start a new interview, complete it, and check the feedback and history right away....
|
1793775358.477823
|
1794639358.477823
|
|
26652
|
Mcrpd by @Ganimard | Stardance
|
Ganimard
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-1 [{"ship_num": 1, "ts": "2026-10-31T19:55:31Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I have made a 3 key macropad with a rotary encoder and oled screen and 4 LEDs. Note that a demo video is not attached as I did not have time to make one (my hackpad kit arrived on Oct 31st).", "repo": "https://github.com/Ganimard1/Macropad_stardance", "demo": ""}]...
|
[{"post_id": 85400, "ts": "202 [{"post_id": 85400, "ts": "2026-10-31T08:33:45Z", "hours": 0.5667, "text": "Figuring out how heat set inserts work + addidional fuckery (the plastic was melting and making a mess everywhere) I will not have time to add a demo video b4 stardance finishes but it will be up on the repo at some stage"}, {"post_id": 85386, "ts": "2026-10-31T07:49:04Z", "hours": 1.15, "text": "Soldered everything toghether"}, {"post_id": 71642, "ts": "2026-09-21T06:41:00Z", "hours": 0.7911, "text": "Doublechecked the pin mappings in my firmware"}, {"post_id": 71077, "ts": "2026-09-20T08:40:30Z", "hours": 0.9528, "text": "I’M DONE. firmware, case design and pcb design is all wrapped up just had to tidy up my github repo and get it ready for review"}, {"post_id": 70484, "ts": "2026-09-19T08:33:09Z", "hours": 1.7458, "text": "Ok a basic draft of the firmware is finished and I’ve tried to compile it where it said “invalid bootloader specified” or sm shit, but I’ve fixed that just got the errors qmk msys gives me to work out. Involved some major terminal and file explorer fuckery, especially as a beginner"}, {"post_id": 62072, "ts": "2026-09-05T09:46:47Z", "hours": 1.2167, "text": "finished case design. I actually added a little shroud thing for the mcu which will be glued onto the main case assembly after building."}, {"post_id": 62012, "ts": "2026-09-05T06:45:47Z", "hours": 0.8833, "text": "Case redesign(tolerances would not fit). still unfinished"}, {"post_id": 61929, "ts": "2026-09-05T03:08:24Z", "hours": 1.3428, "text": "finishing touches on the top plate"}, {"post_id": 61861, "ts": "2026-09-05T00:03:53Z", "hours": 0.9667, "text": "I finally found a boolean model to use for the usb-c cutout off of printables. The case now has a usb-c cutout."}, {"post_id": 60720, "ts": "2026-09-03T08:49:46Z", "hours": 1.0264, "text": "Fixed the led routing now all thats left is some DRC kinks to work out."}, {"post_id": 52906, "ts": "2026-08-23T09:00:07Z", "hours": 0.95, "text": "edited the pcb as there are a few kinks to work out with the footprints. My LEDs give an error message in DRC as “footprint not found”"}, {"post_id": 42501, "ts": "2026-08-07T08:52:02Z", "hours": 1.5331, "text": "still trying to add a usb c cutout"}, {"post_id": 38077, "ts": "2026-07-31T09:17:01Z", "hours": 1.6, "text": "trying to add a usb c cutout to my case"}, {"post_id": 35672, "ts": "2026-07-27T08:30:57Z", "hours": 0.9167, "text": "further firmware development. I worked mostly on the info.json file and reverse enginerred the orpheuspad’s code. Some AI was used for proofreading"}, {"post_id": 35055, "ts": "2026-07-26T07:15:21Z", "hours": 0.9669, "text": "Finally, after much undocumented reseach, i’ve started writing the firmware. I did vibecode and use help from AI a bit as I havent coded in anything past python."}, {"post_id": 31060, "ts": "2026-07-19T04:48:07Z", "hours": 1.0003, "text": "figuring out how qmk works and how i use it"}, {"post_id": 30556, "ts": "2026-07-18T07:14:13Z", "hours": 1.2336, "text": "Case design is basically done just gotta add a usb c cutout. The top plate is basically nonexistant as i wanted the pcb, components and soldering to show through the case"}, {"post_id": 30031, "ts": "2026-07-17T09:01:37Z", "hours": 2.6922, "text": "(hopefully) Final PCB rerouting and case design"}, {"post_id": 29312, "ts": "2026-07-16T05:05:54Z", "hours": 1.5669, "text": "Placement of things on the top case plate. Gonna add a boolean modifier to make the holes for it on the top plate later"}, {"post_id": 29216, "ts": "2026-07-15T23:31:39Z", "hours": 0.7003, "text": "Unfinished case (top plate and walls still unfinished"}, {"post_id": 28775, "ts": "2026-07-15T08:07:58Z", "hours": 0.8278, "text": "GND net finished and case design started"}, {"post_id": 28571, "ts": "2026-07-14T22:03:51Z", "hours": 1.2939, "text": "Final routing with the correct microcontroller. GND net still unfinished"}, {"post_id": 28153, "ts": "2026-07-14T08:26:51Z", "hours": 1.6469, "text": "Fixed prev ERC errors and begun routing"}, {"post_id": 27546, "ts": "2026-07-13T06:26:12Z", "hours": 2.3003, "text": "The tutorial for the hackpad uses the SAMD21 version of the xiao whereas they ship the xiao rp2040. Had to redesign everything around the rp2040. Schematic ERC still gives some errors and routing is not yet fully completed."}, {"post_id": 27059, "ts": "2026-07-12T08:15:12Z", "hours": 0.8167, "text": "finished case design and started firmware design"}, {"post_id": 25811, "ts": "2026-07-10T08:45:18Z", "hours": 1.4503, "text": "fixed the DRC issues from the LEDs and started case design"}, {"post_id": 24580, "ts": "2026-07-08T08:28:36Z", "hours": 1.3167, "text": "Added 4 LEDs. Kicad DRC gives a lot of errors still so got a few kinks to work out before routing."}, {"post_id": 22701, "ts": "2026-07-05T08:23:29Z", "hours": 0.5333, "text": "added silkscreen art to my pcb"}, {"post_id": 22456, "ts": "2026-07-04T22:32:19Z", "hours": 1.0167, "text": "added an oled screen+rotary encoder. gonna try to add some silkscreen art next time"}, {"post_id": 21350, "ts": "2026-07-03T07:32:42Z", "hours": 1.7047, "text": "I am building a comparatively basic 3 key macropad with a rotary encoder, an oled screen, LEDs and 3 switches. So far only the switches and the (badly incorporated) rotary encoder have been added. In further sessions I intend to fix the rotary encoder and add an oled screen (software parts to come later)."}]...
|
Title: Mcrpd by @Ganimard | Stardance
Devlogs:
I Title: Mcrpd by @Ganimard | Stardance
Devlogs:
I am building a comparatively basic 3 key macropad with a rotary encoder, an oled screen, LEDs and 3 switches. So far only the switches and the (badly incorporated) rotary encoder have been added. In further sessions I intend to fix the rotary encoder and add an oled screen (software parts to come later).
added an oled screen+rotary encoder. gonna try to add some silkscreen art next time
added silkscreen art to my pcb
Added 4 LEDs. Kicad DRC gives a lot of errors still so got a few kinks to work out before routing.
fixed the DRC issues from the LEDs and started case design
finished case design and started firmware design
The tutorial for the hackpad uses the SAMD21 version of the xiao whereas they ship the xiao rp2040. Had to redesign everything around the rp2040. Schematic ERC still gives some errors and routing is not yet fully completed.
Fixed prev ERC errors and begun routing
Final routing with the correct microcontroller. GND net still unfinished
GND net finished and case design started
Unfinished case (top plate and walls still unfinished
Placement of things on the top case plate. Gonna add a boolean modifier to make the holes for it on the top plate later
(hopefully) Final PCB rerouting and case design
Case design is basically done just gotta add a usb c cutout. The top plate is basically nonexistant as i wanted the pcb, components and soldering to show through the case
figuring out how qmk works and how i use it
Finally, after much undocumented reseach, i’ve started writing the firmware. I did vibecode and use help from AI a bit as I havent coded in anything past python.
further firmware development. I worked mostly on the info.json file and reverse enginerred the orpheuspad’s code. Some AI was used for proofreading
trying to add a usb c cutout to my case
still trying to add a usb c cutout
edited the pcb as there are a few kinks to work out with the footprints. My LEDs give an error message in DRC as “footprint not found”
Fixed the led routing now all thats left is some DRC kinks to work out.
I finally found a boolean model to use for the usb-c cutout off of printables. The case now has a usb-c cutout.
finishing touches on the top plate
Case redesign(tolerances would not fit). still unfinished
finished case design. I actually added a little shroud thing for the mcu which will be glued onto the main case assembly after building.
Ok a basic draft of the firmware is finished and I’ve tried to compile it where it said “invalid bootloader specified” or sm shit, but I’ve fixed that just got the errors qmk msys gives me to work out. Involved some major terminal and file explorer fuckery, especially as a beginner
I’M DONE. firmware, case design and pcb design is all wrapped up just had to tidy up my github repo and get it ready for review
Doublechecked the pin mappings in my firmware
Soldered everything toghether
Figuring out how heat set inserts work + addidional fuckery (the plastic was melting and making a mess everywhere) I will not have time to add a demo video b4 stardance finishes but it will be up on the repo at some stage
Ships:
I have made a 3 key macropad with a rotary encoder and oled screen and 4 LEDs. Note that a demo video is not attached as I did not have time to make one (my hackpad kit arrived on Oct 31st)....
|
1793775356.606682
|
1793861756.606682
|
|
19078
|
Space Game by @Ris2043 | Stardance
|
Ris2043
|
1
|
17.0
|
147
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-23T13:40:05Z", "hours": 17.0, "multiplier": 8.58, "payout": 147, "blessing": "neutral", "text": "The concept behind this game is simple but intense: You are a lone captain piloting a starship through a high-stakes sector of space. Your mission is to intercept and extract cosmic data from various planets in the solar system. The catch? The deeper you go, the more the universe tries to wipe you out with an absolute barrage of rogue meteors. Play it right in your browser: https://solar-systemgame.vercel.app/ Peek under the hood: https://github.com/Rishi-Rahul/Solar-System-game How it Works (The Technical Stuff) I wanted this game to feel incredibly snappy, whether you’re playing on a massive desktop monitor or tapping away on a phone screen during a break. Here is how I put it together using just raw HTML5 Canvas and vanilla JavaScript: Silky Smooth 60fps Rendering To keep the game looking crisp on high-end mobile screens and modern monitors, I hooked into window.devicePixelRatio. Instead of letting the browser stretch a blurry canvas, the game dynamically resizes its internal resolution to match the exact physical pixels of your screen. I also anchored everything to a base resolution of 800px using a global scale multiplier. This means whether you play on a tiny phone or a giant monitor, the game scales perfectly and the difficulty stays the same. Drifty Space Physics Instead of making the ship move instantly when you press a key (which feels robotic), I wrote a quick vector physics loop with built-in momentum. When you press WASD or drag your finger on a screen, you aren’t moving the ship’s position directly—you’re adding acceleration to its velocity vector. When you let go, a friction variable gently slows you down. This gives the ship that authentic, slippery “drifting through zero gravity” feel. Procedural Chaos To keep the game lightweight and lightning-fast to load, there are zero image files. Everything is drawn on the fly using math: The Meteors: Every single meteor is a unique, randomly generated polygon. The code picks a random number of sides and jag the edges so no two space rocks look exactly alike. The Neon Glow: I used canvas radial gradients and shadowBlur layers to make the Sun and target planets look like they’re practically melting through a retro CRT monitor. Features Cooked In Hybrid Controls: Supports arrow keys, WASD, or seamless touch-and-drag mechanics for mobile pilots. *Escalating Threat Levels: The further you survive, the faster the planets orbit and the tighter the meteor waves get. Dynamic Targeting: Your target planet gets an animated, high-contrast dashed orbit path so you know exactly where to fly. *Retro CRT Scanlines: A clever CSS linear-gradient trick overlays a vintage, arcade-cabinet grid over the entire screen.", "repo": "https://github.com/Rishi-Rahul/Solar-System-game", "demo": "https://solar-systemgame.vercel.app/"}]...
|
[{"post_id": 14355, "ts": "202 [{"post_id": 14355, "ts": "2026-06-23T13:38:06Z", "hours": 0.0, "text": "Fix all errors with the planetspeed, they are normal now, and as you progress, it gets faster"}, {"post_id": 14145, "ts": "2026-06-23T04:01:13Z", "hours": 7.0, "text": "Added Key elements to the project, planet speed gets faster as you progress, and meteor amount increases as you progress too!!!"}, {"post_id": 13675, "ts": "2026-06-22T13:01:49Z", "hours": 8.0, "text": "I’ve finished the whole game itself, need to fix some bugs like the planet speed."}]...
|
Title: Space Game by @Ris2043 | Stardance
Devlogs Title: Space Game by @Ris2043 | Stardance
Devlogs:
I’ve finished the whole game itself, need to fix some bugs like the planet speed.
Added Key elements to the project, planet speed gets faster as you progress, and meteor amount increases as you progress too!!!
Fix all errors with the planetspeed, they are normal now, and as you progress, it gets faster
Ships:
The concept behind this game is simple but intense: You are a lone captain piloting a starship through a high-stakes sector of space. Your mission is to intercept and extract cosmic data from various planets in the solar system. The catch? The deeper you go, the more the universe tries to wipe you out with an absolute barrage of rogue meteors. Play it right in your browser: https://solar-systemgame.vercel.app/ Peek under the hood: https://github.com/Rishi-Rahul/Solar-System-game How it Works (The Technical Stuff) I wanted this game to feel incredibly snappy, whether you’re playing on a massive desktop monitor or tapping away on a phone screen during a break. Here is how I put it together using just raw HTML5 Canvas and vanilla JavaScript: Silky Smooth 60fps Rendering To keep the game looking crisp on high-end mobile screens and modern monitors, I hooked into window.devicePixelRatio. Instead of letting the browser stretch a blurry canvas, the game dynamically resizes its internal resolution to match the exact physical pixels of your screen. I also anchored everything to a base resolution of 800px using a global scale multiplier. This means whether you play on a tiny phone or a giant monitor, the game scales perfectly and the difficulty stays the same. Drifty Space Physics Instead of making the ship move instantly when you press a key (which feels robotic), I wrote a quick vector physics loop with built-in momentum. When you press WASD or drag your finger on a screen, you aren’t moving the ship’s position directly—you’re adding acceleration to its velocity vector. When you let go, a friction variable gently slows you down. This gives the ship that authentic, slippery “drifting through zero gravity” feel. Procedural Chaos To keep the game lightweight and lightning-fast to load, there are zero image files. Everything is drawn on the fly using math: The Meteors: Every single meteor is a unique, randomly generated polygon. The code picks a random number of sides and jag the edges so no two space rocks look exactly alike. The Neon Glow: I used canvas radial gradients and shadowBlur layers to make the Sun and target planets look like they’re practically melting through a retro CRT monitor. Features Cooked In Hybrid Controls: Supports arrow keys, WASD, or seamless touch-and-drag mechanics for mobile pilots. *Escalating Threat Levels: The further you survive, the faster the planets orbit and the tighter the meteor waves get. Dynamic Targeting: Your target planet gets an animated, high-contrast dashed orbit path so you know exactly where to fly. *Retro CRT Scanlines: A clever CSS linear-gradient trick overlays a vintage, arcade-cabinet grid over the entire screen....
|
1793775355.6500244
|
1794639355.6500244
|
|
14589
|
My very own WebOS by @Eryk | Stardance
|
Eryk
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @Eryk | Stardance
|
1793775354.6453397
|
1794380154.6453397
|
|
5187
|
unchild by @hamsal | Stardance
|
hamsal
|
1
|
2.0
|
8
|
[{"ship_num": 1, "hours": 2.0, [{"ship_num": 1, "hours": 2.0, "multiplier": 3.67, "payout": 8, "blessing": "neutral", "text": "i made a biography of a kpop group unchild with a little quiz", "repo": "https://github.com/hamsal39/unchild", "demo": "https://hamsal39.github.io/unchild/", "ts": "2026-07-01T18:55:26Z"}]...
|
[{"post_id": 16486, "ts": "202 [{"post_id": 16486, "ts": "2026-06-26T20:39:38Z", "hours": 0.0, "text": "i just finished the easiest part which is the main part that i just put the basic info by the way in later devlogs u will see that i changed the avatars and tracks"}, {"post_id": 18559, "ts": "2026-06-29T19:08:54Z", "hours": 0.0, "text": "i have been working on the spotify part of my biography of unchild instead of the wrong tracks i put their 2 songs since their debut"}, {"post_id": 19426, "ts": "2026-06-30T19:04:57Z", "hours": 0.0, "text": "memberssssssss"}, {"post_id": 20163, "ts": "2026-07-01T18:23:51Z", "hours": 0.0, "text": "finished! i added a quiz, their music, their members and if you didn’t know about unchild before hope you become a CHACHA after this"}, {"post_id": 20934, "ts": "2026-07-02T17:44:42Z", "hours": 0.0, "text": "Shipping failed soooo……. made some touches"}, {"post_id": 22770, "ts": "2026-07-05T11:02:41Z", "hours": 0.0, "text": "at this point i am ready to quit. but one more try"}]...
|
Title: unchild by @hamsal | Stardance
Devlogs:
i Title: unchild by @hamsal | Stardance
Devlogs:
i just finished the easiest part which is the main part that i just put the basic info by the way in later devlogs u will see that i changed the avatars and tracks
i have been working on the spotify part of my biography of unchild instead of the wrong tracks i put their 2 songs since their debut
memberssssssss
finished! i added a quiz, their music, their members and if you didn’t know about unchild before hope you become a CHACHA after this
Shipping failed soooo……. made some touches
at this point i am ready to quit. but one more try
Ships:
i made a biography of a kpop group unchild with a little quiz...
|
1793775353.7476444
|
1794639353.7476444
|
|
19506
|
HackingNotes by @Ashu-cipher | Stardance
|
Ashu-cipher
|
2
|
16.0
|
75
|
[{"ship_num": 1, "hours": 10.0, &# [{"ship_num": 1, "hours": 10.0, "multiplier": 3.46, "payout": 35, "blessing": "neutral", "text": "I am making wiki for CyberSecurity enthusiast, this will help them in learning, finding vulnerability, growing. This project will grow with me, my knowledge. You can use it as reference or as a wiki, whichever way you want to use. I hope you find it useful. There is too much to add, i will update these things time to time. currently on hold", "repo": "https://github.com/Ashu-Cipher/HackingNotes", "demo": "https://ashu-cipher.github.io/HackingNotes/", "ts": "2026-07-02T17:10:27Z"}, {"ship_num": 2, "hours": 5.0, "multiplier": 7.9, "payout": 40, "blessing": "neutral", "text": "I am making wiki for CyberSecurity enthusiast, this will help them in learning, finding vulnerability, growing. This project will grow with me, my knowledge. You can use it as reference or as a wiki, whichever way you want to use. I hope you find it useful. There is too much to add, i will update these things time to time. currently on hold", "repo": "https://github.com/Ashu-Cipher/HackingNotes", "demo": "https://ashu-cipher.github.io/HackingNotes/", "ts": "2026-06-16T00:12:08Z"}]...
|
[{"post_id": 9596, "ts": "2026 [{"post_id": 9596, "ts": "2026-06-16T00:06:41Z", "hours": 10.0, "text": "I’m Making Notes for those who’re interested in CyberSecurity. This project will grow with me, hope you find it useful."}, {"post_id": 10961, "ts": "2026-06-17T23:38:27Z", "hours": 1.0, "text": "Completed transmission media and switching, next is The osi model"}, {"post_id": 11202, "ts": "2026-06-18T10:23:58Z", "hours": 0.0, "text": "completed OSI model, next is TCP/IP model"}, {"post_id": 20909, "ts": "2026-07-02T17:05:33Z", "hours": 2.0, "text": "completed TCP/IP model, maybe not available on page, ig deployment error"}, {"post_id": 24777, "ts": "2026-07-08T15:55:16Z", "hours": 1.0, "text": "okay, so i have decided to continue this project after a break and Physical Layer is done, currently working on Data Link Layer, Data Link Layer is fairly long enough so it would take some more time, after that let’s see what can i do, feel free to criticise, i’m up for Constructive criticism"}]...
|
Title: HackingNotes by @Ashu-cipher | Stardance
D Title: HackingNotes by @Ashu-cipher | Stardance
Devlogs:
okay, so i have decided to continue this project after a break and Physical Layer is done, currently working on Data Link Layer, Data Link Layer is fairly long enough so it would take some more time, after that let’s see what can i do, feel free to criticise, i’m up for Constructive criticism
completed TCP/IP model, maybe not available on page, ig deployment error
completed OSI model, next is TCP/IP model
Completed transmission media and switching, next is The osi model
I’m Making Notes for those who’re interested in CyberSecurity. This project will grow with me, hope you find it useful.
Ships:
I am making wiki for CyberSecurity enthusiast, this will help them in learning, finding vulnerability, growing. This project will grow with me, my knowledge. You can use it as reference or as a wiki, whichever way you want to use. I hope you find it useful. There is too much to add, i will update these things time to time. currently on hold
I am making wiki for CyberSecurity enthusiast, this will help them in learning, finding vulnerability, growing. This project will grow with me, my knowledge. You can use it as reference or as a wiki, whichever way you want to use. I hope you find it useful. There is too much to add, i will update these things time to time. currently on hold...
|
1793775352.837457
|
1794639352.837457
|
|
9273
|
My awesome macropad! by @manuja_proj | Stardance
|
manuja_proj
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @manuja_proj | Star Title: My awesome macropad! by @manuja_proj | Stardance...
|
1793775351.7549288
|
1794380151.7549288
|
|
51485
|
UNIVERSE WEB by @aryamankumar2403 | Stardance
|
aryamankumar2403
|
2
|
47.69
|
186
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-31T02:42:34Z", "hours": 7.0, "multiplier": 2.41, "payout": 17, "blessing": "neutral", "text": "I removed aal bugs and make the Lamp working", "repo": "https://github.com/Universe-Classes/UNIVERSE-CLASSES", "demo": "https://universe-classes.github.io/UNIVERSE-CLASSES/"}, {"ship_num": 2, "ts": "2026-08-24T08:49:41Z", "hours": 38.0, "multiplier": 4.51, "payout": 169, "blessing": "neutral", "text": "I am building an online learning platform called ‘Universe Classes’ specifically for Class 9 and 10 students following the Bihar Board curriculum. It is a complete portal where students can access free and paid video courses, download structured study materials and notes, and take daily practice quizzes. I’ve also built a dedicated admin panel to manage all the courses, student data, and notifications seamlessly", "repo": "https://github.com/Universe-Classes/UNIVERSE-CLASSES", "demo": "https://universe-classes.github.io/UNIVERSE-CLASSES/"}]...
|
[{"post_id": 59432, "ts": "202 [{"post_id": 59432, "ts": "2026-09-01T08:51:45Z", "hours": 2.6936, "text": "Today I added a 10-minute free trial option to the Universe Classes login page.Now new students can try the platform for 10 minutes before deciding to continue. I wanted to make the first experience simple and useful, so students can check the classes and see how the website works without directly buying anything.I’m also working on improving the login page design and making the whole experience smoother and easier to use.More updates coming soon on Universe Classes."}, {"post_id": 58606, "ts": "2026-08-31T02:41:27Z", "hours": 0.5144, "text": "hey i removed aaal bugs plese rtae"}, {"post_id": 56398, "ts": "2026-08-28T04:53:51Z", "hours": 0.5094, "text": "HI FRIENDS MY SITE NEW LOOK"}, {"post_id": 55414, "ts": "2026-08-27T07:03:20Z", "hours": 3.0514, "text": "I re writed aal css 5th Time"}, {"post_id": 55038, "ts": "2026-08-26T13:53:22Z", "hours": 1.4925, "text": "hi friends i worked 40hours to make this site checcker sayed its vibe coded or maked by ai i writted aal codes again of css and thats my last try i shiiped 4 times but aal times rejected this is last time iam shipping my project"}, {"post_id": 54921, "ts": "2026-08-26T04:31:57Z", "hours": 0.8578, "text": "New Look Of My login Padge The Webiste ais Still Have Errorrs I am trying To fix It"}, {"post_id": 54223, "ts": "2026-08-25T03:47:38Z", "hours": 0.7039, "text": "New look OF my EDUCATION SITE THATS GGOD AND PRETTY"}, {"post_id": 53618, "ts": "2026-08-24T08:29:22Z", "hours": 4.4983, "text": "I AM SHIPPING UNIVERSE CLASSES THE SITE WORK PROPERLY BUT YOU HAVE TO WAIT FOR 30 TO 40 SECOND TO LOAD CONTRNTS"}, {"post_id": 53078, "ts": "2026-08-23T14:24:42Z", "hours": 8.5289, "text": "HI MY SITE IS CRASES WHEN I LOGIN WITH 15 DEVICES I AM SOLVING IUSSUE WAIT FOR SOME DAY😞"}, {"post_id": 52411, "ts": "2026-08-22T15:18:14Z", "hours": 3.5128, "text": "I am building Universe Classesa E-learning Platform For Class 9 and Right now, I"}, {"post_id": 52248, "ts": "2026-08-22T10:45:47Z", "hours": 4.3808, "text": "Currently, I am developing a comprehensive, full-stack e-learning platform called ‘Universe Classes,’ specifically designed to bridge the educational gap for Class 9 and 10 students studying under the Bihar Board curriculum.The project is split into two primary ecosystems: a student-facing portal and a powerful, centralized Admin Control Panel.On the student side, the goal is to provide an intuitive, high-performance interface where learners can create secure accounts via Email or Google Authentication. Once logged in, students gain access to a dynamic dashboard that tracks their progress. The platform seamlessly categorizes content into Free and Paid tiers, offering high-quality video lectures, downloadable structured study materials (like NCERT solutions and hand-written notes), and an interactive daily MCQ quiz engine built to test their knowledge and boost exam preparation.On the backend and administrative side, I am building a robust Admin Panel that gives educators complete control over the application. Admins can upload unlimited courses, link YouTube or Google Drive lectures, manage PDF notes, update live notifications, and highlight academic milestones through a Toppers showcase. We are currently integrating Firebase to securely manage user authentication, session states, and real-time database structures, ensuring that sensitive student data and premium course content remain fully protected.Ultimately, ‘Universe Classes’ isn’t just a website—it is a scalable, secure, and production-ready educational ecosystem built to make quality learning accessible, organized, and affordable"}, {"post_id": 52074, "ts": "2026-08-22T04:39:18Z", "hours": 1.6956, "text": "Some paid notes was just aaded"}, {"post_id": 52046, "ts": "2026-08-22T02:49:16Z", "hours": 0.3086, "text": "I am currently developing an e-learning platform called ‘Universe Classes’ for Class 9 and 10 students. I’ve already designed the frontend interface and a robust admin dashboard. Right now, I am focusing on integrating the backend services, handling secure user login authentication, and structuring the database to manage both free and premium courses and study materials"}, {"post_id": 52024, "ts": "2026-08-22T01:56:09Z", "hours": 10.7028, "text": "LOOK AT THE LOGIN PADGE"}, {"post_id": 51502, "ts": "2026-08-21T08:19:29Z", "hours": 4.4867, "text": "The site is Almost Redy Aal functions are working prperly But site is not proper smooth I am tring to make it perfect"}]...
|
Title: UNIVERSE WEB by @aryamankumar2403 | Stardan Title: UNIVERSE WEB by @aryamankumar2403 | Stardance
Devlogs:
The site is Almost Redy Aal functions are working prperly But site is not proper smooth I am tring to make it perfect
LOOK AT THE LOGIN PADGE
I am currently developing an e-learning platform called ‘Universe Classes’ for Class 9 and 10 students. I’ve already designed the frontend interface and a robust admin dashboard. Right now, I am focusing on integrating the backend services, handling secure user login authentication, and structuring the database to manage both free and premium courses and study materials
Some paid notes was just aaded
Currently, I am developing a comprehensive, full-stack e-learning platform called ‘Universe Classes,’ specifically designed to bridge the educational gap for Class 9 and 10 students studying under the Bihar Board curriculum.The project is split into two primary ecosystems: a student-facing portal and a powerful, centralized Admin Control Panel.On the student side, the goal is to provide an intuitive, high-performance interface where learners can create secure accounts via Email or Google Authentication. Once logged in, students gain access to a dynamic dashboard that tracks their progress. The platform seamlessly categorizes content into Free and Paid tiers, offering high-quality video lectures, downloadable structured study materials (like NCERT solutions and hand-written notes), and an interactive daily MCQ quiz engine built to test their knowledge and boost exam preparation.On the backend and administrative side, I am building a robust Admin Panel that gives educators complete control over the application. Admins can upload unlimited courses, link YouTube or Google Drive lectures, manage PDF notes, update live notifications, and highlight academic milestones through a Toppers showcase. We are currently integrating Firebase to securely manage user authentication, session states, and real-time database structures, ensuring that sensitive student data and premium course content remain fully protected.Ultimately, ‘Universe Classes’ isn’t just a website—it is a scalable, secure, and production-ready educational ecosystem built to make quality learning accessible, organized, and affordable
I am building Universe Classesa E-learning Platform For Class 9 and Right now, I
HI MY SITE IS CRASES WHEN I LOGIN WITH 15 DEVICES I AM SOLVING IUSSUE WAIT FOR SOME DAY😞
I AM SHIPPING UNIVERSE CLASSES THE SITE WORK PROPERLY BUT YOU HAVE TO WAIT FOR 30 TO 40 SECOND TO LOAD CONTRNTS
New look OF my EDUCATION SITE THATS GGOD AND PRETTY
New Look Of My login Padge The Webiste ais Still Have Errorrs I am trying To fix It
hi friends i worked 40hours to make this site checcker sayed its vibe coded or maked by ai i writted aal codes again of css and thats my last try i shiiped 4 times but aal times rejected this is last time iam shipping my project
I re writed aal css 5th Time
HI FRIENDS MY SITE NEW LOOK
hey i removed aaal bugs plese rtae
Today I added a 10-minute free trial option to the Universe Classes login page.Now new students can try the platform for 10 minutes before deciding to continue. I wanted to make the first experience simple and useful, so students can check the classes and see how the website works without directly buying anything.I’m also working on improving the login page design and making the whole experience smoother and easier to use.More updates coming soon on Universe Classes.
Ships:
I am building an online learning platform called ‘Universe Classes’ specifically for Class 9 and 10 students following the Bihar Board curriculum. It is a complete portal where students can access free and paid video courses, download structured study materials and notes, and take daily practice quizzes. I’ve also built a dedicated admin panel to manage all the courses, student data, and notifications seamlessly
I removed aal bugs and make the Lamp working...
|
1793775350.8608146
|
1794639350.8608146
|
|
11282
|
A very simple stt by @soraitsuri | Stardance
|
soraitsuri
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: A very simple stt by @soraitsuri | Stardanc Title: A very simple stt by @soraitsuri | Stardance...
|
1793775349.7351503
|
1794380149.7351503
|
|
54940
|
arya whether by @aryamankumar2403 | Stardance
|
aryamankumar2403
|
2
|
63.0
|
32
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-04T13:26:22Z", "hours": 54.0, "multiplier": 6.69, "payout": 0, "blessing": "neutral", "text": "What did i make ? I built a responsive weather website where users can search for a city and see its current weather, temperature, humidity, wind, pressure, hourly forecast and upcoming forecast. I also redesigned the whole interface and added smoother animations, transitions, weather visuals and a better way to explore different cities. What was challenging? The hardest part was getting all the different weather information to work together without making the interface confusing. Handling API responses, loading states, invalid searches and different screen sizes took more time than I expected. I also had to keep adjusting the animations because some of them looked good individually but felt too much when everything was running together. What i am proud of? I am most proud of the redesign because it started from a rough paper sketch and slowly became an actual working website. I also like that I didn’t just focus on making it look good — I spent time fixing the small interactions and making the weather data actually useful. What should people know? The project is still being developed, so some things may change as I continue working on it. I have intentionally kept the latest redesign hidden for now because I want to reveal the new look", "repo": "https://github.com/AryaBuilds/WHETHER-", "demo": "https://aryabuilds.github.io/WHETHER-/"}, {"ship_num": 2, "ts": "2026-08-29T05:04:20Z", "hours": 9.0, "multiplier": 3.66, "payout": 32, "blessing": "neutral", "text": "I Maked A full 3d funsctional Animated 3d gether aap for Pc And Mobile I Aaded open Api And Most Difiiculte part Is To make Dedgine", "repo": "https://github.com/AryaBuilds/WHETHER-", "demo": "https://aryabuilds.github.io/WHETHER-/"}]...
|
[{"post_id": 61496, "ts": "202 [{"post_id": 61496, "ts": "2026-09-04T13:16:43Z", "hours": 1.9011, "text": "i aaded map"}, {"post_id": 61422, "ts": "2026-09-04T10:12:45Z", "hours": 2.1961, "text": "After a lot of work behind the scenes, I finally revealed the home screen of the project. The main layout, visuals, animations, and overall experience are starting to come together. There is still a lot left to polish, but I’m happy with how it’s taking shape. Current progress: ~80% complete. The remaining 20% is mainly about refining the details, improving the animations, fixing small issues, and making everything feel more Profeesional"}, {"post_id": 61321, "ts": "2026-09-04T05:21:24Z", "hours": 1.6528, "text": "Hlw friend my whether web is almost completed aal api hanling mobile view tab desktop view aal are working perfect the animation are fully smooth any datanot in raw form Aal site is completed i will show the imadge of home view in next Devlog foolw the project to see what is made"}, {"post_id": 60939, "ts": "2026-09-03T16:45:26Z", "hours": 2.0514, "text": "After improving the weather visuals, I started checking how the website behaves on smaller screens. The desktop layout was looking good, but when everything became narrower, some cards started feeling too crowded and a few sections needed better spacing. Instead of making a completely separate mobile design, I am adjusting the existing layout so the same website can naturally adapt to different screen sizes. I am also checking the search area, weather information and forecast cards because these are the sections that can become difficult to use on a small screen."}, {"post_id": 60851, "ts": "2026-09-03T14:07:08Z", "hours": 4.3489, "text": "After finishing the basic error handling, I started working on how the website visually represents different weather conditions. I noticed that showing only the temperature and text does not give the user much feeling about what the weather is actually like. So I started connecting the weather conditions with the correct icons and visual elements. The tricky part was that the API can return different condition names, so I had to make sure similar conditions were handled correctly instead of creating a separate case for every small variation. I am also trying to keep the visuals consistent with the new design. I don’t want to add too many effects just for the sake of animation, so I am keeping them subtle and related to the actual weather."}, {"post_id": 60723, "ts": "2026-09-03T08:54:42Z", "hours": 3.0394, "text": "After working on the loading state, I moved on to the situations where something goes wrong. A weather website cannot assume that every search will always return a perfect result, so I wanted to make these cases feel like a normal part of the experience instead of looking like a broken page. I started handling cases such as an invalid city name, an empty search and problems with the API response. One small issue I found was that simply showing an error message was not enough — the user should also understand what they need to do next. So I am keeping the error messages simple and making sure the rest of the interface stays usable when a request fails. I am also checking that a failed search does not remove the weather information unnecessarily. What I worked on Invalid city handling Empty search handling API error handling Better error messages Keeping the interface usable after an error Testing different failed requests"}, {"post_id": 60655, "ts": "2026-09-03T04:44:50Z", "hours": 2.2597, "text": "After improving the city search, I started working on what happens between the search and the final weather result. I noticed that when the API takes a little time to respond, the page can feel like nothing is happening, which is not a very good experience. So I started adding a proper loading state while the new weather data is being fetched. I am also making sure that the old information does not stay visible in a confusing way while the new city is loading. Another thing I am working on is keeping the animations connected with these changes, so the weather information does not suddenly appear without any transition. What I worked on Added a loading state for weather searches Improved the transition between old Worked on API response timing Prevented confusing outdated information Connected loading with the existing animations Started preparing better error feedback"}, {"post_id": 60613, "ts": "2026-09-03T02:10:16Z", "hours": 6.2564, "text": "After working on how the weather data flows through the website, I started focusing on the city search experience. The search feature is an important part of the project because it is how users will interact with the website most of the time. One issue I noticed was that changing the city affected multiple parts of the page at once. The current weather, forecast and other information all need to update together. So instead of handling every section separately, I started organising the search flow more carefully. I am also working on making the interaction feel smoother after a search. The goal is to avoid the page feeling like it suddenly changes from one city to another. What I worked on Improving the city search flow Updating multiple weather sections together Handling different city searches Improving the response after searching Working on smoother content changes Preparing the search system for better error handling later"}, {"post_id": 60243, "ts": "2026-09-02T14:20:39Z", "hours": 3.3247, "text": "can you Belive I dont Have My Presnol laptop or pc i am from a very poor family from india and i am makeing projects working on hackclub from schools computer so i have limited time to work and make projects soory to giving less information"}, {"post_id": 60155, "ts": "2026-09-02T10:41:42Z", "hours": 2.1561, "text": "After arranging the main weather sections, I started working on how the information moves through the website. I noticed that simply getting the API data was not enough — the same data had to reach the correct cards and sections without making the page feel messy. I started separating the current weather, hourly data and forecast data so each part could be handled properly. While doing this, I found a few cases where some values were missing or the weather condition was not matching the icon being shown. I fixed these parts by making the data handling more flexible and checking the response before displaying it. I am also keeping the structure simple so it will be easier to add more features later."}, {"post_id": 60089, "ts": "2026-09-02T07:25:14Z", "hours": 3.3619, "text": "HI thats new dedgined tower For my site home screen i will revel only this pls like and foolow my devlog project and pls give suggestion on cooment what to aad to get 10 on 10 rating on ship"}, {"post_id": 60015, "ts": "2026-09-02T03:31:33Z", "hours": 8.6178, "text": "After getting the main structure ready, I started working on the different weather sections one by one. I did not want to build everything together because it became difficult to see which part was causing a problem. I started with the current weather information and then worked on the forecast and hourly sections. While doing this, I noticed that some information looked fine on its own but did not look balanced when placed next to the other sections. So I kept adjusting the structure and spacing while checking the whole page together. I am also trying to keep the information easy to understand, because showing too much weather data at once can make the page confusing. What I worked on Current weather information Forecast section Hourly weather section Weather informtion cards Other cities section Better arrangement of weather data Connecting different sections visually"}, {"post_id": 59630, "ts": "2026-09-01T15:29:40Z", "hours": 5.2403, "text": "The visual part of the redesign is getting close, so now I have started working on the actual functionality. One problem I noticed was that the page looked good with fixed weather information, but that is not useful for a real weather website because the data needs to change dynamically when a user searches for another city.I started connecting the [Yahan apni API ka naam likhein, e.g., OpenWeatherMap] API and working on how the JSON data will be received and parsed. At first, handling different responses was a little confusing because not every city returns the same weather condition data format (some cities lacked specific fields like rain or wind speed), so I had to make my JavaScript logic more flexible using conditional checks.I also added robust error handling using try…catch blocks for cases like an invalid city name (404 errors) or missing data, so the website displays a clean “City Not Found” message instead of crashing or freezing.What I worked on:Connected the live weather API and parsed the incoming JSON response.Replaced all static/fixed UI placeholders with dynamic live data.Linked the city search input button with the API fetch trigger.Implemented logic to dynamically render temperature, humidity, and weather condition text.Handled edge cases (invalid search results, API down, or empty inputs) to prevent UI breakage.Tested the app with multiple global cities to ensure consistent data behavior."}, {"post_id": 59433, "ts": "2026-09-01T08:54:16Z", "hours": 2.6108, "text": "After working on the transitions, I am now doing the small details that can make the website feel more complete. I am going through the whole page again and checking things like spacing, text sizes, card alignment and how each section looks together. I also found a few small things that did not feel right in the first version, so I am fixing them instead of leaving them as they are. The goal now is not to add a lot of new stuff, but to make the existing design cleaner and more polished."}, {"post_id": 59362, "ts": "2026-09-01T03:36:55Z", "hours": 0.4961, "text": "I have started working on the transitions of my weather website. The main design and animations are already there, but some parts still feel a little too sudden when they change or appear. Now I am trying to make everything feel more smooth and natural. I am adjusting the timing, speed and small movements of different elements so the website does not feel like everything is just jumping from one state to another."}, {"post_id": 59344, "ts": "2026-09-01T02:41:28Z", "hours": 0.5247, "text": "After completing the main CSS design, I have started working on the animations for the weather website. I want the page to feel a little more alive instead of everything just appearing on the screen at once. Right now I am experimenting with small animations for the weather section, cards, clouds and different parts of the page. I am trying to keep the animations smooth and simple so they do not make the website feel overloaded. I am also checking how the animations look while scrolling and on different screen sizes. Some animations still need a few adjustments, so this phase is not completely finished yet. i want to give a suprise to You so I didnt attached the dedgine imadge Smooth page animations Weather and cloud animations Card hover effects Small transitions between sections Scroll-based effects Making animations work properly on mobile"}, {"post_id": 58932, "ts": "2026-08-31T14:27:33Z", "hours": 1.8086, "text": "I finished the CSS part of my weather website redesign. After making the rough layout in the first phase, I started turning that idea into an actual interface with proper spacing, sections, cards and responsive layout. I worked on the main weather area, forecast sections, hourly weather, other cities and the footer. I also adjusted the typography, sizes and spacing so the page feels more balanced and closer to the sketch I made. The CSS is now mostly completed, and the website finally looks much closer to the design I had in mind. There are still some small things I want to improve later, but the main visual structure is done. What I completed Main page layout Weather hero section Search bar styling Weather information cards Forecast cards Hourly forecast layout Other cities cards Footer section Spacing and typography Responsive layout adjustments"}, {"post_id": 58781, "ts": "2026-08-31T11:04:42Z", "hours": 1.8761, "text": "to redesign my weather website because the old design was working, but I was not fully happy with how it looked. Some sections felt too plain and the information was not arranged the way I wanted. For this phase, I first looked at my old website and thought about what I should change. I did not want to completely change the idea of the project, so I kept the main weather features but started planning a new layout. Before writing the code, I made a rough sketch on paper. I planned the header, city search, main weather section, forecast cards, hourly weather, other cities and the bottom sections. I also wanted the new design to feel more like a real website and less like a basic practice project. I focused on better spacing, simple typography, clear sections and making the page look good on different screen sizes. Things I planned to improve Redesign the full page layout Make the weather section more clear Improve the forecast cards Add a better hourly forecast section Make the other cities section cleaner Improve mobile responsiveness Keep the interface simple and easy to use"}, {"post_id": 57043, "ts": "2026-08-29T03:39:07Z", "hours": 0.5303, "text": "finaaly animations working smoothly and aal whethers are acurate"}, {"post_id": 56562, "ts": "2026-08-28T11:20:38Z", "hours": 0.6133, "text": "project completed time to ship"}, {"post_id": 56538, "ts": "2026-08-28T10:23:20Z", "hours": 0.8494, "text": "i am aading 3d transictions animations currenetly"}, {"post_id": 56497, "ts": "2026-08-28T09:14:28Z", "hours": 0.4083, "text": "LOOK AT THE DESDGIEN GUYS"}, {"post_id": 56488, "ts": "2026-08-28T08:42:07Z", "hours": 1.2314, "text": "HI I AADED API TO WORK IT ACURATE"}, {"post_id": 56457, "ts": "2026-08-28T07:09:46Z", "hours": 5.0381, "text": "HI LOOK AT THIS CSS IS COMPLETED"}]...
|
Title: arya whether by @aryamankumar2403 | Stardan Title: arya whether by @aryamankumar2403 | Stardance
Devlogs:
HI LOOK AT THIS CSS IS COMPLETED
HI I AADED API TO WORK IT ACURATE
LOOK AT THE DESDGIEN GUYS
i am aading 3d transictions animations currenetly
project completed time to ship
finaaly animations working smoothly and aal whethers are acurate
to redesign my weather website because the old design was working, but I was not fully happy with how it looked. Some sections felt too plain and the information was not arranged the way I wanted. For this phase, I first looked at my old website and thought about what I should change. I did not want to completely change the idea of the project, so I kept the main weather features but started planning a new layout. Before writing the code, I made a rough sketch on paper. I planned the header, city search, main weather section, forecast cards, hourly weather, other cities and the bottom sections. I also wanted the new design to feel more like a real website and less like a basic practice project. I focused on better spacing, simple typography, clear sections and making the page look good on different screen sizes. Things I planned to improve Redesign the full page layout Make the weather section more clear Improve the forecast cards Add a better hourly forecast section Make the other cities section cleaner Improve mobile responsiveness Keep the interface simple and easy to use
I finished the CSS part of my weather website redesign. After making the rough layout in the first phase, I started turning that idea into an actual interface with proper spacing, sections, cards and responsive layout. I worked on the main weather area, forecast sections, hourly weather, other cities and the footer. I also adjusted the typography, sizes and spacing so the page feels more balanced and closer to the sketch I made. The CSS is now mostly completed, and the website finally looks much closer to the design I had in mind. There are still some small things I want to improve later, but the main visual structure is done. What I completed Main page layout Weather hero section Search bar styling Weather information cards Forecast cards Hourly forecast layout Other cities cards Footer section Spacing and typography Responsive layout adjustments
After completing the main CSS design, I have started working on the animations for the weather website. I want the page to feel a little more alive instead of everything just appearing on the screen at once. Right now I am experimenting with small animations for the weather section, cards, clouds and different parts of the page. I am trying to keep the animations smooth and simple so they do not make the website feel overloaded. I am also checking how the animations look while scrolling and on different screen sizes. Some animations still need a few adjustments, so this phase is not completely finished yet. i want to give a suprise to You so I didnt attached the dedgine imadge Smooth page animations Weather and cloud animations Card hover effects Small transitions between sections Scroll-based effects Making animations work properly on mobile
I have started working on the transitions of my weather website. The main design and animations are already there, but some parts still feel a little too sudden when they change or appear. Now I am trying to make everything feel more smooth and natural. I am adjusting the timing, speed and small movements of different elements so the website does not feel like everything is just jumping from one state to another.
After working on the transitions, I am now doing the small details that can make the website feel more complete. I am going through the whole page again and checking things like spacing, text sizes, card alignment and how each section looks together. I also found a few small things that did not feel right in the first version, so I am fixing them instead of leaving them as they are. The goal now is not to add a lot of new stuff, but to make the existing design cleaner and more polished.
The visual part of the redesign is getting close, so now I have started working on the actual functionality. One problem I noticed was that the page looked good with fixed weather information, but that is not useful for a real weather website because the data needs to change dynamically when a user searches for another city.I started connecting the [Yahan apni API ka naam likhein, e.g., OpenWeatherMap] API and working on how the JSON data will be received and parsed. At first, handling different responses was a little confusing because not every city returns the same weather condition data format (some cities lacked specific fields like rain or wind speed), so I had to make my JavaScript logic more flexible using conditional checks.I also added robust error handling using try…catch blocks for cases like an invalid city name (404 errors) or missing data, so the website displays a clean “City Not Found” message instead of crashing or freezing.What I worked on:Connected the live weather API and parsed the incoming JSON response.Replaced all static/fixed UI placeholders with dynamic live data.Linked the city search input button with the API fetch trigger.Implemented logic to dynamically render temperature, humidity, and weather condition text.Handled edge cases (invalid search results, API down, or empty inputs) to prevent UI breakage.Tested the app with multiple global cities to ensure consistent data behavior.
After getting the main structure ready, I started working on the different weather sections one by one. I did not want to build everything together because it became difficult to see which part was causing a problem. I started with the current weather information and then worked on the forecast and hourly sections. While doing this, I noticed that some information looked fine on its own but did not look balanced when placed next to the other sections. So I kept adjusting the structure and spacing while checking the whole page together. I am also trying to keep the information easy to understand, because showing too much weather data at once can make the page confusing. What I worked on Current weather information Forecast section Hourly weather section Weather informtion cards Other cities section Better arrangement of weather data Connecting different sections visually
HI thats new dedgined tower For my site home screen i will revel only this pls like and foolow my devlog project and pls give suggestion on cooment what to aad to get 10 on 10 rating on ship
After arranging the main weather sections, I started working on how the information moves through the website. I noticed that simply getting the API data was not enough — the same data had to reach the correct cards and sections without making the page feel messy. I started separating the current weather, hourly data and forecast data so each part could be handled properly. While doing this, I found a few cases where some values were missing or the weather condition was not matching the icon being shown. I fixed these parts by making the data handling more flexible and checking the response before displaying it. I am also keeping the structure simple so it will be easier to add more features later.
can you Belive I dont Have My Presnol laptop or pc i am from a very poor family from india and i am makeing projects working on hackclub from schools computer so i have limited time to work and make projects soory to giving less information
After working on how the weather data flows through the website, I started focusing on the city search experience. The search feature is an important part of the project because it is how users will interact with the website most of the time. One issue I noticed was that changing the city affected multiple parts of the page at once. The current weather, forecast and other information all need to update together. So instead of handling every section separately, I started organising the search flow more carefully. I am also working on making the interaction feel smoother after a search. The goal is to avoid the page feeling like it suddenly changes from one city to another. What I worked on Improving the city search flow Updating multiple weather sections together Handling different city searches Improving the response after searching Working on smoother content changes Preparing the search system for better error handling later
After improving the city search, I started working on what happens between the search and the final weather result. I noticed that when the API takes a little time to respond, the page can feel like nothing is happening, which is not a very good experience. So I started adding a proper loading state while the new weather data is being fetched. I am also making sure that the old information does not stay visible in a confusing way while the new city is loading. Another thing I am working on is keeping the animations connected with these changes, so the weather information does not suddenly appear without any transition. What I worked on Added a loading state for weather searches Improved the transition between old Worked on API response timing Prevented confusing outdated information Connected loading with the existing animations Started preparing better error feedback
After working on the loading state, I moved on to the situations where something goes wrong. A weather website cannot assume that every search will always return a perfect result, so I wanted to make these cases feel like a normal part of the experience instead of looking like a broken page. I started handling cases such as an invalid city name, an empty search and problems with the API response. One small issue I found was that simply showing an error message was not enough — the user should also understand what they need to do next. So I am keeping the error messages simple and making sure the rest of the interface stays usable when a request fails. I am also checking that a failed search does not remove the weather information unnecessarily. What I worked on Invalid city handling Empty search handling API error handling Better error messages Keeping the interface usable after an error Testing different failed requests
After finishing the basic error handling, I started working on how the website visually represents different weather conditions. I noticed that showing only the temperature and text does not give the user much feeling about what the weather is actually like. So I started connecting the weather conditions with the correct icons and visual elements. The tricky part was that the API can return different condition names, so I had to make sure similar conditions were handled correctly instead of creating a separate case for every small variation. I am also trying to keep the visuals consistent with the new design. I don’t want to add too many effects just for the sake of animation, so I am keeping them subtle and related to the actual weather.
After improving the weather visuals, I started checking how the website behaves on smaller screens. The desktop layout was looking good, but when everything became narrower, some cards started feeling too crowded and a few sections needed better spacing. Instead of making a completely separate mobile design, I am adjusting the existing layout so the same website can naturally adapt to different screen sizes. I am also checking the search area, weather information and forecast cards because these are the sections that can become difficult to use on a small screen.
Hlw friend my whether web is almost completed aal api hanling mobile view tab desktop view aal are working perfect the animation are fully smooth any datanot in raw form Aal site is completed i will show the imadge of home view in next Devlog foolw the project to see what is made
After a lot of work behind the scenes, I finally revealed the home screen of the project. The main layout, visuals, animations, and overall experience are starting to come together. There is still a lot left to polish, but I’m happy with how it’s taking shape. Current progress: ~80% complete. The remaining 20% is mainly about refining the details, improving the animations, fixing small issues, and making everything feel more Profeesional
i aaded map
Ships:
I Maked A full 3d funsctional Animated 3d gether aap for Pc And Mobile I Aaded open Api And Most Difiiculte part Is To make Dedgine
What did i make ? I built a responsive weather website where users can search for a city and see its current weather, temperature, humidity, wind, pressure, hourly forecast and upcoming forecast. I also redesigned the whole interface and added smoother animations, transitions, weather visuals and a better way to explore different cities. What was challenging? The hardest part was getting all the different weather information to work together without making the interface confusing. Handling API responses, loading states, invalid searches and different screen sizes took more time than I expected. I also had to keep adjusting the animations because some of them looked good individually but felt too much when everything was running together. What i am proud of? I am most proud of the redesign because it started from a rough paper sketch and slowly became an actual working website. I also like that I didn’t just focus on making it look good — I spent time fixing the small interactions and making the weather data actually useful. What should people know? The project is still being developed, so some things may change as I continue working on it. I have intentionally kept the latest redesign hidden for now because I want to reveal the new look...
|
1793775348.7532809
|
1794639348.7532809
|
|
33219
|
My first slack bot! by @_jacy | Stardance
|
_jacy
|
1
|
1.0
|
0
|
[{"ship_num": 1, "hours": 1.0, [{"ship_num": 1, "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I created a Slack bot that provides real time information on stocks all over the world. uses alpha venture API and is run on my Ubuntu server with python", "repo": "https://github.com/jeffmc6767/Stardance-StockBuddy", "demo": "https://app.slack.com/client/E09V59WQY1E/C0BGSNN875X?skip_today=1", "ts": "2026-07-10T01:21:41Z"}]...
|
[{"post_id": 25630, "ts": "202 [{"post_id": 25630, "ts": "2026-07-10T01:16:46Z", "hours": 0.0, "text": "BOT IS WORKING REALLY WELL! I didn’t follow the guide, instead, I create a python code that is basically what the bot follows, then uploaded to GitHub. After, I installed the GitHub packages on my Homeserver(Ubuntu) then hosted it from there. Now my bot works everywhere"}, {"post_id": 26354, "ts": "2026-07-11T03:01:33Z", "hours": 0.0, "text": "I added the list to github"}]...
|
Title: My first slack bot! by @_jacy | Stardance
Title: My first slack bot! by @_jacy | Stardance
Devlogs:
BOT IS WORKING REALLY WELL! I didn’t follow the guide, instead, I create a python code that is basically what the bot follows, then uploaded to GitHub. After, I installed the GitHub packages on my Homeserver(Ubuntu) then hosted it from there. Now my bot works everywhere
I added the list to github
Ships:
I created a Slack bot that provides real time information on stocks all over the world. uses alpha venture API and is run on my Ubuntu server with python...
|
1793775344.8438106
|
1794639344.8438106
|
|
48749
|
A GAME NEVER ENDS by @aryamankumar2403 | Stardance
|
aryamankumar2403
|
2
|
5.0
|
6
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-26T10:02:32Z", "hours": 3.0, "multiplier": 1.09, "payout": 4, "blessing": "neutral", "text": "i fixed aal bugs guys", "repo": "https://github.com/AryaBuilds/GAME-NEVER-ENDS", "demo": "https://aryabuilds.github.io/GAME-NEVER-ENDS/"}, {"ship_num": 2, "ts": "2026-08-17T02:42:39Z", "hours": 2.0, "multiplier": 1.09, "payout": 2, "blessing": "neutral", "text": "“I am building an endless, fast-paced arcade-style game where the action never stops. The game features infinite levels with dynamically rising difficulty, a minimalist user interface, and is specifically designed for quick, high-score focused gameplay sessions.”", "repo": "https://github.com/AryaBuilds/GAME-NEVER-ENDS", "demo": "https://aryabuilds.github.io/GAME-NEVER-ENDS/"}]...
|
[{"post_id": 51445, "ts": "202 [{"post_id": 51445, "ts": "2026-08-21T04:53:37Z", "hours": 0.3797, "text": "new look"}, {"post_id": 50956, "ts": "2026-08-20T12:58:26Z", "hours": 2.5578, "text": "a game never ends"}, {"post_id": 48633, "ts": "2026-08-17T03:19:32Z", "hours": 0.3678, "text": "A UNIQE GAME THAT NEVER ENDS"}, {"post_id": 48618, "ts": "2026-08-17T02:41:37Z", "hours": 1.0767, "text": "“I am building an endless, fast-paced arcade-style game where the action never stops. The game features infinite levels with dynamically rising difficulty, a minimalist user interface, and is specifically designed for quick, high-score focused gameplay sessions.”"}, {"post_id": 48107, "ts": "2026-08-16T12:11:58Z", "hours": 0.7961, "text": "hi every one"}]...
|
Title: A GAME NEVER ENDS by @aryamankumar2403 | St Title: A GAME NEVER ENDS by @aryamankumar2403 | Stardance
Devlogs:
hi every one
“I am building an endless, fast-paced arcade-style game where the action never stops. The game features infinite levels with dynamically rising difficulty, a minimalist user interface, and is specifically designed for quick, high-score focused gameplay sessions.”
A UNIQE GAME THAT NEVER ENDS
a game never ends
new look
Ships:
“I am building an endless, fast-paced arcade-style game where the action never stops. The game features infinite levels with dynamically rising difficulty, a minimalist user interface, and is specifically designed for quick, high-score focused gameplay sessions.”
i fixed aal bugs guys...
|
1793775342.3391955
|
1794639342.3391955
|
|
39599
|
My very own WebOS by @AhmetFAY | Stardance
|
AhmetFAY
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @AhmetFAY | Stardance
|
1793775341.2727299
|
1794380141.2727299
|
|
14489
|
PandaOS by @panda | Stardance
|
panda
|
1
|
6.0
|
74
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-15T21:56:55Z", "hours": 6.0, "multiplier": 12.02, "payout": 74, "blessing": "neutral", "text": "I made my very own webOS from scratch, themed just like my portfolio and nvim config. Check it out !", "repo": "https://github.com/mail2adnanyazik-bit/pandaOS", "demo": "https://panda-os-five.vercel.app/"}]...
|
[{"post_id": 8256, "ts": "2026 [{"post_id": 8256, "ts": "2026-06-13T18:52:29Z", "hours": 0.4458, "text": "Fixed final minor bugs, pushed final version to GitHub, and used Vercel to deploy ! Im pretty much done now, and am pretty proud of the end result - check out the page here : https://panda-84hn8kync-mail2adnanyazik-bits-projects.vercel.app/ I would love to hear some feedback / get some bug reports - feel free to check it out and let me know what you think in the comments !"}, {"post_id": 7585, "ts": "2026-06-12T18:01:28Z", "hours": 0.6078, "text": "Fixed all bugs from last time, did all TODO’s also added polish, animations, etc. fixed some buggy features"}, {"post_id": 7035, "ts": "2026-06-11T19:55:56Z", "hours": 2.4794, "text": "Added content to apps, a spotlight app search, and other polish features such as right clicking desktop, a music player, etc Still TODO : sync the dock volume bar with the settings volume bar and remove vol bar from music app. make the buttons for notes look better - right now they are wierd and grey fix brightness slider - when adjusted it just turns screen and background white make calculator look better Make text in panda profile bigger, and make window in total bigger along with everything inside it add song status bar (how long it has been playing , a loading bar dude, like in spotify) above the play and pause and so buttons delete about from spotlight add more css to all apps"}, {"post_id": 6356, "ts": "2026-06-10T18:10:46Z", "hours": 2.64, "text": "Finished the Homepage and core logic for my WebOS What was done : Added background image Changed font to look a little more terminal-y finished core window dragging logic made a close button for the windows time and date display on bottom right fake (for now) volume slider placeholder “Apps” including projects placeholder, sysmon (fake system stats display), terminal (again placeholder) Core logic for which window is in foreground and which in back (drawing layers) TODO : replace placeholders with actual content (i can copy a bit from my portfolio website :P ) add a favorite music playing app (and subsequently make volume slider actually adjust volume) push to github decide on next features to add"}]...
|
Title: PandaOS by @panda | Stardance
Devlogs:
Fin Title: PandaOS by @panda | Stardance
Devlogs:
Finished the Homepage and core logic for my WebOS What was done : Added background image Changed font to look a little more terminal-y finished core window dragging logic made a close button for the windows time and date display on bottom right fake (for now) volume slider placeholder “Apps” including projects placeholder, sysmon (fake system stats display), terminal (again placeholder) Core logic for which window is in foreground and which in back (drawing layers) TODO : replace placeholders with actual content (i can copy a bit from my portfolio website :P ) add a favorite music playing app (and subsequently make volume slider actually adjust volume) push to github decide on next features to add
Added content to apps, a spotlight app search, and other polish features such as right clicking desktop, a music player, etc Still TODO : sync the dock volume bar with the settings volume bar and remove vol bar from music app. make the buttons for notes look better - right now they are wierd and grey fix brightness slider - when adjusted it just turns screen and background white make calculator look better Make text in panda profile bigger, and make window in total bigger along with everything inside it add song status bar (how long it has been playing , a loading bar dude, like in spotify) above the play and pause and so buttons delete about from spotlight add more css to all apps
Fixed all bugs from last time, did all TODO’s also added polish, animations, etc. fixed some buggy features
Fixed final minor bugs, pushed final version to GitHub, and used Vercel to deploy ! Im pretty much done now, and am pretty proud of the end result - check out the page here : https://panda-84hn8kync-mail2adnanyazik-bits-projects.vercel.app/ I would love to hear some feedback / get some bug reports - feel free to check it out and let me know what you think in the comments !
Ships:
I made my very own webOS from scratch, themed just like my portfolio and nvim config. Check it out !...
|
1793775338.3373628
|
1793861738.3373628
|
|
30479
|
FaceFall by @f | Stardance
|
f
|
1
|
37.0
|
310
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-05T15:54:03Z", "hours": 24.0, "multiplier": 13.74, "payout": 310, "blessing": "neutral", "text": "What I made FaceFall is a real-time 3D cloth simulator written in C99. It simulates cloth falling over spheres, cubes, and arbitrary OBJ meshes, with a live preview and deterministic MP4 export at up to 4K 120 FPS. What was challenging Getting the cloth to actually behave like fabric. Most of the work went into making the simulation stable while adding self-collision, realistic aerodynamics, and reliable mesh collision without particles tunnelling through geometry or the cloth exploding. What I’m proud of I’m most proud that it feels believable. You can change cloth resolution, material, wind, and colliders, then export smooth 120 FPS videos, all from a single C source file. How to test it Build with build.bat and run facefall.exe. I recommend using a 64×64 or 128×128 cloth, trying each collider, toggling self-collision, changing the fabric presets, and exporting a 120 FPS video with V. You can also run facefall –selftest to verify the physics automatically.", "repo": "https://github.com/pefia/FaceFall", "demo": "https://github.com/pefia/FaceFall/releases/tag/v1.2"}]...
|
[{"post_id": 24408, "ts": "202 [{"post_id": 24408, "ts": "2026-07-07T22:53:27Z", "hours": 13.0, "text": "More ways to break the cloth This update was mostly about adding interactive features. The biggest one was cloth tearing . My first attempt never actually worked because the strain limiter prevented springs from stretching far enough to snap. The fix was checking the stretch before the limiter ran, then making sure tearing also removed the connected shear and bend springs so pieces actually separated instead of hanging by invisible links. I also added: A throwable physics ball that transfers momentum into the cloth. Mouse grabbing so you can pull and fling the fabric around. A live tension heatmap to show where the cloth is under stress. Slow motion (down to 1/8× ) and frame-by-frame stepping for debugging. The ball ended up being my favourite feature. Throwing it through a pinned curtain now rips a hole through the fabric, the stress heatmap lights up around the impact, and the cloth keeps simulating normally afterwards. Everything was backed up with new self-tests for tearing and ball collisions, and the original cloth behaviour stayed identical when the new features were disabled."}, {"post_id": 22922, "ts": "2026-07-05T15:50:26Z", "hours": 8.0, "text": "FaceFall - Devlog #3 Making the cloth actually feel like cloth This update was all about making the simulation feel physically believable instead of just stable. Some things worked exactly as I’d hoped, some didn’t, and one bug ended up explaining why cloth doesn’t really bounce. Better aerodynamics The old simulation only used simple linear drag, which meant the whole cloth slowed down evenly in every direction. It worked, but everything fell like it was moving through syrup. I replaced that with per-triangle aerodynamic forces. Every triangle now generates drag based on its orientation and velocity, so the cloth behaves much more naturally. A flat sheet catches the air like a parachute, while an edge-on sheet slices straight through it. The drag is also normalised so changing the cloth resolution doesn’t completely change the way it falls. The difference is surprisingly noticeable. Around the one second mark the cloth now billows into a canopy before landing, something the old solver never managed. Self collision Another thing I wanted was proper self collision. Previously, folds could pass straight through each other. I implemented a spatial hash so nearby particles can efficiently detect overlaps without checking every possible pair, keeping the cost close to linear even on larger simulations. The first time I tried self collision a while ago it was unstable because I only corrected positions. This time every collision also updates particle velocity, so the solver no longer fights itself. Folded cloth now stacks into proper layers instead of collapsing through itself. Softer collisions I also rewrote the collision response. Instead of instantly pushing particles outside the collider, objects now behave like spring-damper surfaces. The cloth compresses slightly into the collision shell before settling, which produces much smoother landings and completely removed the tiny jitter I was previously working around. The bounce bug This ended up being the most interesting part of the update. I originally wanted the cloth to bounce realistically, so I tried several different approaches. None of them looked right. While debugging I found something strange. After impact, some particles still had positive upward velocity for frame after frame, yet they never actually moved. The culprit was strain limiting. Every correction was changing particle positions without updating their velocities, meaning momentum was effectively disappearing from the simulation. Once I applied the matching velocity correction alongside each positional fix, impacts started travelling naturally through the cloth as visible waves instead of vanishing. Ironically, fixing that bug also answered the original question. Real cloth barely bounces. Once the sheet starts draping over a sphere, the hanging fabric absorbs almost all of the remaining energy. Even with perfect restitution the cloth only lifted a few centimetres before settling again. Because of that, the default fabric presets now use very low restitution values. Silk barely rebounds at all, while leather keeps a little more energy. Higher frame rate The simulator now runs internally at 120 FPS . Preview mode still displays at 60 FPS by stepping the simulation twice per frame, while exports run at the full rate. Renders take longer, but the smoother motion is absolutely worth it, especially during impact. Current state This update made the simulation feel much closer to real fabric. The cloth now catches the air properly, folded layers no longer pass through each other, collisions are smoother, and the behaviour after impact looks far more convincing than before. It also reminded me that sometimes the most realistic result isn’t the one you expect. After spending hours trying to make the cloth bounce, the correct answer turned out to be that real cloth… mostly doesn’t."}, {"post_id": 22529, "ts": "2026-07-05T01:38:01Z", "hours": 2.0, "text": "Going back to basics After trying a few more “realistic” cloth techniques, I realised I’d made the simulation worse instead of better. The biggest problems were all my own: Self-collision pushed overlapping particles apart in position space without changing their velocity, so the springs immediately snapped them back and the whole cloth could launch itself across the scene. Replacing bend springs with angle constraints made the cloth feel soft and unstable because the position-based constraints were fighting the force-based spring solver. Per-triangle aerodynamic forces changed the way the cloth fell and settled, but not for the better. Sometimes the simplest solution really is the right one. I rolled the simulator back to the model that was already producing the best results: Structural, shear, and bend springs Per-particle wind Linear air drag Strain limiting as the only position correction I removed self-collision and the angle-based bending entirely. Fabric presets now just adjust the bend spring stiffness, so materials like silk and leather still behave differently without adding unnecessary complexity. The settings menu was cleaned up to match. The rendering improvements all stayed, including the updated shader, high-resolution offscreen exports (1080p, 1440p and 4K), and the quality-of-life improvements to the presets and UI. I also added a --selftest mode that automatically runs a standard cloth drop onto the sphere and checks that the simulation stays stable. It verifies that particle positions remain finite, the cloth doesn’t explode or fling itself away, and structural springs stay within the configured strain limit."}, {"post_id": 22155, "ts": "2026-07-04T13:59:55Z", "hours": 1.0, "text": "FaceFall — Devlog #2 2026-07-04 — The cloth was invisible the whole time This update started with one simple bug report: “the cloth barely renders and it keeps clipping into the model.” It turned out to be three completely different problems. By the end of today I’d rebuilt the renderer, rewritten parts of the collision system, doubled the maximum cloth resolution to 128x128 , added adjustable cloth and collider sizes, and accidentally made the entire simulation explode into NaNs. The invisible cloth At first I assumed the renderer or lighting was broken. It wasn’t. The real problem was raylib’s batching. I disabled backface culling before submitting the cloth geometry, but re-enabled it before the batch was actually flushed to the GPU. The simulation itself was perfectly fine, but almost the entire cloth was getting backface-culled before it ever reached the screen. The fix was simply flushing the render batch before and after changing the GPU state so the cloth was actually drawn with culling disabled. While I was there I also rewrote the lighting. Instead of flat shading per quad, the cloth now generates smooth per-vertex normals and uses simple Gouraud shading. The difference is huge, especially on higher resolutions. The clipping bug The second issue was much harder. The first problem was that my collision shell was far too thin. At lower resolutions the particles stayed outside the collider, but the rendered surface between them could still cut straight through the mesh. I fixed that by scaling the collision shell with particle spacing so coarse cloth stays slightly further away from the surface. That solved part of it. The bigger issue only showed up against thin meshes. Sometimes a particle could move completely through the object in a single step, and because the collision system only looked at the particle’s final position it would happily push it out of the wrong side. The solution was switching to continuous collision detection. Every particle now stores its previous position, and I sweep that movement against the mesh instead of only checking where it ended up. The explosion My first implementation of continuous collision looked perfect. For about three seconds. Then the cloth completely disappeared. It turned out I had created an energy feedback loop where particles bounced between both sides of thin geometry until the simulation exploded into NaNs. Instead of pushing particles to a new position after a collision, I now simply restore their previous valid position and remove the inward velocity. It’s slightly more conservative, but completely stable. Bigger simulations With collision working properly again I increased the maximum cloth resolution from 64x64 to 128x128 . That pushed the simulation to over 16,000 particles , nearly 100,000 springs , and roughly 32,000 rendered triangles . To keep performance reasonable I added a simple spatial grid for mesh collisions so particles only test nearby triangles instead of the entire mesh every substep. The result is still effectively real-time, even at the highest resolution. New settings The settings menu also picked up a couple of new options: Adjustable cloth size Adjustable collider size Changing either one rebuilds the simulation immediately, updates the collision data, and automatically reframes the camera so everything stays visible. Current state FaceFall is finally starting to feel like a proper tool rather than just a physics demo. The renderer looks significantly better, collisions are much more reliable, larger simulations run comfortably, and exporting deterministic comparison clips is now almost entirely hands-off. There’s still plenty left to do, especially around self-collision, but it’s getting much closer to the project I originally imagined."}, {"post_id": 22094, "ts": "2026-07-04T11:07:25Z", "hours": 11.0, "text": "Dev Log #1 - FaceFall I started FaceFall because I kept seeing those short videos where a cloth drops over the same object at different mesh resolutions, but I don’t know how to use things like Blender to make them myself. The difference between a 2x2 sheet and a dense mesh is surprisingly satisfying, and I wanted to build my own version from scratch instead of relying on an existing physics engine. The goal isn’t just to make another cloth simulator. The mesh density is the whole point. At really low resolutions the cloth behaves more like a stiff piece of cardboard, while higher resolutions start producing proper folds, ripples, and believable draping. Reference: https://www.youtube.com/shorts/s_G2gBbWYF0 What’s working So far I’ve built a complete cloth simulator in a single C99 source file using raylib. Current features include: Mass-spring cloth simulation Structural, shear, and bending springs Hooke’s law with damping Semi-implicit Euler integration Runtime cloth resolutions from 2x2 up to 64x64 Sphere, cube, and arbitrary OBJ mesh colliders Three application modes: Settings Live preview Deterministic render/export Direct ffmpeg export to MP4 At this point it’s less of a physics experiment and more of a small content creation pipeline. I can recreate the exact same simulation with different resolutions and export identical camera angles for comparison videos. Challenges The biggest challenge early on was stability. Increasing spring stiffness quickly caused the simulation to explode, so I ended up basing the number of simulation substeps on the spring frequency instead of using a fixed timestep. The cloth also stretched far too much at first and looked more like rubber than fabric. Adding strain limiting made a huge difference and stopped the structural springs from over-extending. Collision was easily the hardest part. Spheres and cubes weren’t too bad, but arbitrary OBJ meshes became a rabbit hole of closest-point tests, broad-phase checks, collision response, and trying to stop particles tunnelling straight through thin geometry. I also spent longer than I’d like fighting Windows. Exporting raw frames through ffmpeg would randomly corrupt the output until I realised _popen needed to be opened in binary mode. Current bug The biggest thing I’m still working through is sphere collision. Most of the time it behaves exactly how I’d expect, but every now and then parts of the cloth clip into the sphere instead of settling over the surface. Once a few particles end up inside the collider the cloth starts rendering incorrectly, so it’s pretty obvious when it happens. I’m fairly confident the issue isn’t the spring solver anymore. The collision detection itself is finding the contacts, but the positional correction isn’t always pushing particles completely back outside the sphere. That’s the main thing I want to fix before moving on. What’s next Once the collision is reliable I want to polish the visuals and start generating comparison clips at different mesh densities. That’s really the whole reason I started this project. Seeing the exact same cloth drop change from a rigid, blocky sheet into something that actually looks like fabric is surprisingly satisfying, and now I finally have a tool that lets me create those videos however I want."}]...
|
Title: FaceFall by @f | Stardance
Devlogs:
Dev Lo Title: FaceFall by @f | Stardance
Devlogs:
Dev Log #1 - FaceFall I started FaceFall because I kept seeing those short videos where a cloth drops over the same object at different mesh resolutions, but I don’t know how to use things like Blender to make them myself. The difference between a 2x2 sheet and a dense mesh is surprisingly satisfying, and I wanted to build my own version from scratch instead of relying on an existing physics engine. The goal isn’t just to make another cloth simulator. The mesh density is the whole point. At really low resolutions the cloth behaves more like a stiff piece of cardboard, while higher resolutions start producing proper folds, ripples, and believable draping. Reference: https://www.youtube.com/shorts/s_G2gBbWYF0 What’s working So far I’ve built a complete cloth simulator in a single C99 source file using raylib. Current features include: Mass-spring cloth simulation Structural, shear, and bending springs Hooke’s law with damping Semi-implicit Euler integration Runtime cloth resolutions from 2x2 up to 64x64 Sphere, cube, and arbitrary OBJ mesh colliders Three application modes: Settings Live preview Deterministic render/export Direct ffmpeg export to MP4 At this point it’s less of a physics experiment and more of a small content creation pipeline. I can recreate the exact same simulation with different resolutions and export identical camera angles for comparison videos. Challenges The biggest challenge early on was stability. Increasing spring stiffness quickly caused the simulation to explode, so I ended up basing the number of simulation substeps on the spring frequency instead of using a fixed timestep. The cloth also stretched far too much at first and looked more like rubber than fabric. Adding strain limiting made a huge difference and stopped the structural springs from over-extending. Collision was easily the hardest part. Spheres and cubes weren’t too bad, but arbitrary OBJ meshes became a rabbit hole of closest-point tests, broad-phase checks, collision response, and trying to stop particles tunnelling straight through thin geometry. I also spent longer than I’d like fighting Windows. Exporting raw frames through ffmpeg would randomly corrupt the output until I realised _popen needed to be opened in binary mode. Current bug The biggest thing I’m still working through is sphere collision. Most of the time it behaves exactly how I’d expect, but every now and then parts of the cloth clip into the sphere instead of settling over the surface. Once a few particles end up inside the collider the cloth starts rendering incorrectly, so it’s pretty obvious when it happens. I’m fairly confident the issue isn’t the spring solver anymore. The collision detection itself is finding the contacts, but the positional correction isn’t always pushing particles completely back outside the sphere. That’s the main thing I want to fix before moving on. What’s next Once the collision is reliable I want to polish the visuals and start generating comparison clips at different mesh densities. That’s really the whole reason I started this project. Seeing the exact same cloth drop change from a rigid, blocky sheet into something that actually looks like fabric is surprisingly satisfying, and now I finally have a tool that lets me create those videos however I want.
FaceFall — Devlog #2 2026-07-04 — The cloth was invisible the whole time This update started with one simple bug report: “the cloth barely renders and it keeps clipping into the model.” It turned out to be three completely different problems. By the end of today I’d rebuilt the renderer, rewritten parts of the collision system, doubled the maximum cloth resolution to 128x128 , added adjustable cloth and collider sizes, and accidentally made the entire simulation explode into NaNs. The invisible cloth At first I assumed the renderer or lighting was broken. It wasn’t. The real problem was raylib’s batching. I disabled backface culling before submitting the cloth geometry, but re-enabled it before the batch was actually flushed to the GPU. The simulation itself was perfectly fine, but almost the entire cloth was getting backface-culled before it ever reached the screen. The fix was simply flushing the render batch before and after changing the GPU state so the cloth was actually drawn with culling disabled. While I was there I also rewrote the lighting. Instead of flat shading per quad, the cloth now generates smooth per-vertex normals and uses simple Gouraud shading. The difference is huge, especially on higher resolutions. The clipping bug The second issue was much harder. The first problem was that my collision shell was far too thin. At lower resolutions the particles stayed outside the collider, but the rendered surface between them could still cut straight through the mesh. I fixed that by scaling the collision shell with particle spacing so coarse cloth stays slightly further away from the surface. That solved part of it. The bigger issue only showed up against thin meshes. Sometimes a particle could move completely through the object in a single step, and because the collision system only looked at the particle’s final position it would happily push it out of the wrong side. The solution was switching to continuous collision detection. Every particle now stores its previous position, and I sweep that movement against the mesh instead of only checking where it ended up. The explosion My first implementation of continuous collision looked perfect. For about three seconds. Then the cloth completely disappeared. It turned out I had created an energy feedback loop where particles bounced between both sides of thin geometry until the simulation exploded into NaNs. Instead of pushing particles to a new position after a collision, I now simply restore their previous valid position and remove the inward velocity. It’s slightly more conservative, but completely stable. Bigger simulations With collision working properly again I increased the maximum cloth resolution from 64x64 to 128x128 . That pushed the simulation to over 16,000 particles , nearly 100,000 springs , and roughly 32,000 rendered triangles . To keep performance reasonable I added a simple spatial grid for mesh collisions so particles only test nearby triangles instead of the entire mesh every substep. The result is still effectively real-time, even at the highest resolution. New settings The settings menu also picked up a couple of new options: Adjustable cloth size Adjustable collider size Changing either one rebuilds the simulation immediately, updates the collision data, and automatically reframes the camera so everything stays visible. Current state FaceFall is finally starting to feel like a proper tool rather than just a physics demo. The renderer looks significantly better, collisions are much more reliable, larger simulations run comfortably, and exporting deterministic comparison clips is now almost entirely hands-off. There’s still plenty left to do, especially around self-collision, but it’s getting much closer to the project I originally imagined.
Going back to basics After trying a few more “realistic” cloth techniques, I realised I’d made the simulation worse instead of better. The biggest problems were all my own: Self-collision pushed overlapping particles apart in position space without changing their velocity, so the springs immediately snapped them back and the whole cloth could launch itself across the scene. Replacing bend springs with angle constraints made the cloth feel soft and unstable because the position-based constraints were fighting the force-based spring solver. Per-triangle aerodynamic forces changed the way the cloth fell and settled, but not for the better. Sometimes the simplest solution really is the right one. I rolled the simulator back to the model that was already producing the best results: Structural, shear, and bend springs Per-particle wind Linear air drag Strain limiting as the only position correction I removed self-collision and the angle-based bending entirely. Fabric presets now just adjust the bend spring stiffness, so materials like silk and leather still behave differently without adding unnecessary complexity. The settings menu was cleaned up to match. The rendering improvements all stayed, including the updated shader, high-resolution offscreen exports (1080p, 1440p and 4K), and the quality-of-life improvements to the presets and UI. I also added a --selftest mode that automatically runs a standard cloth drop onto the sphere and checks that the simulation stays stable. It verifies that particle positions remain finite, the cloth doesn’t explode or fling itself away, and structural springs stay within the configured strain limit.
FaceFall - Devlog #3 Making the cloth actually feel like cloth This update was all about making the simulation feel physically believable instead of just stable. Some things worked exactly as I’d hoped, some didn’t, and one bug ended up explaining why cloth doesn’t really bounce. Better aerodynamics The old simulation only used simple linear drag, which meant the whole cloth slowed down evenly in every direction. It worked, but everything fell like it was moving through syrup. I replaced that with per-triangle aerodynamic forces. Every triangle now generates drag based on its orientation and velocity, so the cloth behaves much more naturally. A flat sheet catches the air like a parachute, while an edge-on sheet slices straight through it. The drag is also normalised so changing the cloth resolution doesn’t completely change the way it falls. The difference is surprisingly noticeable. Around the one second mark the cloth now billows into a canopy before landing, something the old solver never managed. Self collision Another thing I wanted was proper self collision. Previously, folds could pass straight through each other. I implemented a spatial hash so nearby particles can efficiently detect overlaps without checking every possible pair, keeping the cost close to linear even on larger simulations. The first time I tried self collision a while ago it was unstable because I only corrected positions. This time every collision also updates particle velocity, so the solver no longer fights itself. Folded cloth now stacks into proper layers instead of collapsing through itself. Softer collisions I also rewrote the collision response. Instead of instantly pushing particles outside the collider, objects now behave like spring-damper surfaces. The cloth compresses slightly into the collision shell before settling, which produces much smoother landings and completely removed the tiny jitter I was previously working around. The bounce bug This ended up being the most interesting part of the update. I originally wanted the cloth to bounce realistically, so I tried several different approaches. None of them looked right. While debugging I found something strange. After impact, some particles still had positive upward velocity for frame after frame, yet they never actually moved. The culprit was strain limiting. Every correction was changing particle positions without updating their velocities, meaning momentum was effectively disappearing from the simulation. Once I applied the matching velocity correction alongside each positional fix, impacts started travelling naturally through the cloth as visible waves instead of vanishing. Ironically, fixing that bug also answered the original question. Real cloth barely bounces. Once the sheet starts draping over a sphere, the hanging fabric absorbs almost all of the remaining energy. Even with perfect restitution the cloth only lifted a few centimetres before settling again. Because of that, the default fabric presets now use very low restitution values. Silk barely rebounds at all, while leather keeps a little more energy. Higher frame rate The simulator now runs internally at 120 FPS . Preview mode still displays at 60 FPS by stepping the simulation twice per frame, while exports run at the full rate. Renders take longer, but the smoother motion is absolutely worth it, especially during impact. Current state This update made the simulation feel much closer to real fabric. The cloth now catches the air properly, folded layers no longer pass through each other, collisions are smoother, and the behaviour after impact looks far more convincing than before. It also reminded me that sometimes the most realistic result isn’t the one you expect. After spending hours trying to make the cloth bounce, the correct answer turned out to be that real cloth… mostly doesn’t.
More ways to break the cloth This update was mostly about adding interactive features. The biggest one was cloth tearing . My first attempt never actually worked because the strain limiter prevented springs from stretching far enough to snap. The fix was checking the stretch before the limiter ran, then making sure tearing also removed the connected shear and bend springs so pieces actually separated instead of hanging by invisible links. I also added: A throwable physics ball that transfers momentum into the cloth. Mouse grabbing so you can pull and fling the fabric around. A live tension heatmap to show where the cloth is under stress. Slow motion (down to 1/8× ) and frame-by-frame stepping for debugging. The ball ended up being my favourite feature. Throwing it through a pinned curtain now rips a hole through the fabric, the stress heatmap lights up around the impact, and the cloth keeps simulating normally afterwards. Everything was backed up with new self-tests for tearing and ball collisions, and the original cloth behaviour stayed identical when the new features were disabled.
Ships:
What I made FaceFall is a real-time 3D cloth simulator written in C99. It simulates cloth falling over spheres, cubes, and arbitrary OBJ meshes, with a live preview and deterministic MP4 export at up to 4K 120 FPS. What was challenging Getting the cloth to actually behave like fabric. Most of the work went into making the simulation stable while adding self-collision, realistic aerodynamics, and reliable mesh collision without particles tunnelling through geometry or the cloth exploding. What I’m proud of I’m most proud that it feels believable. You can change cloth resolution, material, wind, and colliders, then export smooth 120 FPS videos, all from a single C source file. How to test it Build with build.bat and run facefall.exe. I recommend using a 64×64 or 128×128 cloth, trying each collider, toggling self-collision, changing the fabric presets, and exporting a 120 FPS video with V. You can also run facefall –selftest to verify the physics automatically....
|
1793775334.6754024
|
1794639334.6754024
|
|
27527
|
My first slack bot! by @klarararara | Stardance
|
klarararara
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @klarararara | Stard Title: My first slack bot! by @klarararara | Stardance...
|
1793775327.453676
|
1794380127.453676
|
|
45988
|
vraj's site by @vrajsanghavi | Stardance
|
vrajsanghavi
|
2
|
6.0
|
3
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-16T16:39:08Z", "hours": 1.0, "multiplier": 4.69, "payout": 3, "blessing": "neutral", "text": "i have made my website to display who i am and what i am doing…", "repo": "https://github.com/vraj2011/personal-site", "demo": "https://vraj-site.netlify.app"}, {"ship_num": 2, "ts": "2026-08-15T09:15:24Z", "hours": 5.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "🚀 An interactive personal portfolio blending cricket, electronics, coding, and creative web development — built from scratch with HTML, CSS & JavaScript.", "repo": "https://github.com/vraj2011/personal-site", "demo": "https://vraj-site.netlify.app"}]...
|
[{"post_id": 48188, "ts": "202 [{"post_id": 48188, "ts": "2026-08-16T14:15:05Z", "hours": 0.2969, "text": "i have full looks now,fixed last time’s error ,done in just 20 minutes, because i lost it at then but i got it back…."}, {"post_id": 47997, "ts": "2026-08-16T08:45:06Z", "hours": 0.2939, "text": "finally, last feature is completed whole website is completed and deployed to https://vraj-site.netlify.app"}, {"post_id": 47040, "ts": "2026-08-14T17:13:26Z", "hours": 4.5283, "text": "today,i creted my website’s project.. i created most of the things today my project is ready to deploy but i will deploy it later because there’s a feature which is not here yet… it is cursor effects i will quickly work on it and deploy it.!!"}]...
|
Title: vraj's site by @vrajsanghavi | Stardanc Title: vraj's site by @vrajsanghavi | Stardance
Devlogs:
today,i creted my website’s project.. i created most of the things today my project is ready to deploy but i will deploy it later because there’s a feature which is not here yet… it is cursor effects i will quickly work on it and deploy it.!!
finally, last feature is completed whole website is completed and deployed to https://vraj-site.netlify.app
i have full looks now,fixed last time’s error ,done in just 20 minutes, because i lost it at then but i got it back….
Ships:
🚀 An interactive personal portfolio blending cricket, electronics, coding, and creative web development — built from scratch with HTML, CSS & JavaScript.
i have made my website to display who i am and what i am doing…...
|
1793775324.6154788
|
1794639324.6154788
|
|
18263
|
AquaRead by @Mohamed_Ayadi | Stardance
|
Mohamed_Ayadi
|
1
|
5.0
|
51
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-17T13:53:22Z", "hours": 5.0, "multiplier": 9.65, "payout": 51, "blessing": "neutral", "text": "AquaRead — Irrigation Need Predictor Know before you water. Save what the soil already has. What did I make? I built AquaRead — a tiny, browser-based tool that helps farmers decide how much water their field actually needs. It’s not another dashboard with charts for the sake of charts. It’s a practical decision helper. You enter a handful of things you already know about your field — soil type, current moisture, crop, growth stage, recent rainfall, temperature — and the tool gives you back a clear prediction (Low, Medium, or High), a confidence breakdown, a plain-language explanation, and one practical thing you can do right now. No login. No installation. No data sent anywhere. Just open the page, adjust the sliders, click predict, and get an answer. It’s built to feel like a conversation with an agronomist friend — not a machine. What was challenging? The hardest part was resisting the urge to overcomplicate things. I had a full dataset with 14 columns — Electrical Conductivity, Organic Carbon, Wind Speed, Field Area, Mulching Used, Water Source, Region, Irrigation Type — all begging to be used. But irrigation need doesn’t come from 14 things. It comes from a handful of core drivers: soil moisture, rainfall, temperature, crop stage, and soil type. So I chose essentials over impressiveness. That meant leaving out data that didn’t move the needle, trusting that farmers know their fields better than any dashboard ever could. Another challenge: the dataset is unbalanced. About 59% show Low irrigation need, 38% show Medium, and only 3% show High. High need is genuinely rare — it only happens when moisture is low AND rainfall is low AND temperatures are high simultaneously. Getting the model to recognize that rarity without over-predicting High was a delicate balance. What am I proud of? The explanation layer. It would have been easy to just show “Low” and move on. But that’s not useful. What’s useful is telling someone WHY the model said Low — so they can trust it, disagree with it, or learn something about their field. The explanation reads like: “Based on adequate soil moisture, good recent rainfall, and moderate temperatures, the model suggests Low irrigation need.” That’s just connecting the dots in a way that makes sense to a human who’s been watching the sky and feeling the soil. I’m also proud of the confidence bars. They’re simple — three horizontal bars — but they tell a story. When you see “Low: 72%, Medium: 22%, High: 6%” you know the model isn’t guessing. It’s weighing evidence. And when you see a tight spread — say, 45% / 40% / 15% — you know the conditions are borderline, and maybe you should trust your own judgment more. What should people know to test my project? Here’s how to kick the tires: Open the page in any modern browser (Chrome, Firefox, Safari, Edge — they all work). Play with the sliders and dropdowns. Try extreme conditions: Dry scenario: Moisture = 10%, Rainfall = 0mm, Temperature = 40°C → should return High. Wet scenario: Moisture = 55%, Rainfall = 1200mm, Temperature = 18°C → should return Low. Borderline: Moisture = 30%, Rainfall = 200mm, Temperature = 28°C, Crop = Rice, Stage = Flowering → often returns Medium with narrow confidence. Read the explanation. Does it match what you’d expect? Does it feel like a real agronomist talking? Look at the confidence bars. Are they wide or narrow? That tells you how clear-cut the conditions are. The tool is trained on 10,000 records across four soil types, six crops, and three seasons. The model logic is rule-based — not a neural network, but a carefully weighted decision system that mimics how an agronomist thinks. It’s transparent, predictable, and easy to tweak. Know before you water. Save what the soil already has. — AquaRead", "repo": "https://github.com/medayedi123/AquaRead", "demo": "https://aquaread.netlify.app/"}]...
|
[{"post_id": 10372, "ts": "202 [{"post_id": 10372, "ts": "2026-06-17T01:43:19Z", "hours": 5.0, "text": "🌱 AquaRead — Devlog aka “I built a plant hydration therapist” The Origin Story My mom kept drowning her garden. Every. Single. Day. Even after rain. I was like “Mom, you’re watering the tomatoes to death” and she hit me with “Well how am I supposed to know??” So I built this instead of doing my math homework. Priorities, right? What It Does You punch in some numbers about your field — soil type, moisture, what you’re growing, weather stuff — and it spits out: Low/Medium/High irrigation need How confident it is (with a fancy bar chart) Why it thinks that One actually useful thing to do right now No PhD required. No manual. Just sliders and dropdowns. The Data 10,000 real farm records. Messy. Unbalanced. Perfect. 59% Low irrigation 38% Medium 3% High (because emergencies are rare IRL) The model had to learn that “High” actually matters, not just predict “Low” every time and call it a day. What I Kept (and What I Threw Out) Used: Soil_Type, Soil_Moisture, Temperature, Humidity, Rainfall Crop_Type, Growth_Stage, Season Trashed: Electrical_Conductivity, Organic_Carbon, Wind_Speed Field_Area, Mulching, Water_Source, Region, Irrigation_Type Why? Because irrigation need comes down to like 5 things. The rest is noise. Fight me. The Design (aka “I care about colors”) Forest green ( #2d5a3d ) — the serious backbone Straw gold ( #c9a84c ) — warmth so it’s not a hospital Sage for chill, terracotta for “OMG WATER YOUR CROPS” Fonts: Literata for headings (book vibes), Plus Jakarta Sans for UI (clean but friendly), DM Mono for numbers (because monospaced numbers make my brain happy). No charts-for-the-sake-of-charts. Just the confidence bar because “Low: 72%” is way more useful than just “Low.” The Proud Moment Mom tested it. Punched in her garden. Model said: “Medium irrigation need. Soil moisture is adequate but temperature is rising. Consider watering in the evening to reduce evaporation.” She looked at me like I hacked the Matrix. I was just like “yeah, JavaScript, whatever” but inside I was doing backflips. What’s Next (v2.0) GPS weather lookup — auto-fill temperature and rainfall from a weather API History log — track predictions over time, see patterns The Honest Part (AI helped) Yeah I used AI. For the boilerplate. For the JavaScript I always forget. For debugging that one stupid bug where the bars wouldn’t render. Not for the creative decisions. Not for the colors or the flow or the “vibe.” That’s all me. Think of it as a coding intern who knows everything but has zero taste. I tell it what to build, it spits out code, I fix it, break it, fix it again, and make it actually good."}]...
|
Title: AquaRead by @Mohamed_Ayadi | Stardance
Dev Title: AquaRead by @Mohamed_Ayadi | Stardance
Devlogs:
🌱 AquaRead — Devlog aka “I built a plant hydration therapist” The Origin Story My mom kept drowning her garden. Every. Single. Day. Even after rain. I was like “Mom, you’re watering the tomatoes to death” and she hit me with “Well how am I supposed to know??” So I built this instead of doing my math homework. Priorities, right? What It Does You punch in some numbers about your field — soil type, moisture, what you’re growing, weather stuff — and it spits out: Low/Medium/High irrigation need How confident it is (with a fancy bar chart) Why it thinks that One actually useful thing to do right now No PhD required. No manual. Just sliders and dropdowns. The Data 10,000 real farm records. Messy. Unbalanced. Perfect. 59% Low irrigation 38% Medium 3% High (because emergencies are rare IRL) The model had to learn that “High” actually matters, not just predict “Low” every time and call it a day. What I Kept (and What I Threw Out) Used: Soil_Type, Soil_Moisture, Temperature, Humidity, Rainfall Crop_Type, Growth_Stage, Season Trashed: Electrical_Conductivity, Organic_Carbon, Wind_Speed Field_Area, Mulching, Water_Source, Region, Irrigation_Type Why? Because irrigation need comes down to like 5 things. The rest is noise. Fight me. The Design (aka “I care about colors”) Forest green ( #2d5a3d ) — the serious backbone Straw gold ( #c9a84c ) — warmth so it’s not a hospital Sage for chill, terracotta for “OMG WATER YOUR CROPS” Fonts: Literata for headings (book vibes), Plus Jakarta Sans for UI (clean but friendly), DM Mono for numbers (because monospaced numbers make my brain happy). No charts-for-the-sake-of-charts. Just the confidence bar because “Low: 72%” is way more useful than just “Low.” The Proud Moment Mom tested it. Punched in her garden. Model said: “Medium irrigation need. Soil moisture is adequate but temperature is rising. Consider watering in the evening to reduce evaporation.” She looked at me like I hacked the Matrix. I was just like “yeah, JavaScript, whatever” but inside I was doing backflips. What’s Next (v2.0) GPS weather lookup — auto-fill temperature and rainfall from a weather API History log — track predictions over time, see patterns The Honest Part (AI helped) Yeah I used AI. For the boilerplate. For the JavaScript I always forget. For debugging that one stupid bug where the bars wouldn’t render. Not for the creative decisions. Not for the colors or the flow or the “vibe.” That’s all me. Think of it as a coding intern who knows everything but has zero taste. I tell it what to build, it spits out code, I fix it, break it, fix it again, and make it actually good.
Ships:
AquaRead — Irrigation Need Predictor Know before you water. Save what the soil already has. What did I make? I built AquaRead — a tiny, browser-based tool that helps farmers decide how much water their field actually needs. It’s not another dashboard with charts for the sake of charts. It’s a practical decision helper. You enter a handful of things you already know about your field — soil type, current moisture, crop, growth stage, recent rainfall, temperature — and the tool gives you back a clear prediction (Low, Medium, or High), a confidence breakdown, a plain-language explanation, and one practical thing you can do right now. No login. No installation. No data sent anywhere. Just open the page, adjust the sliders, click predict, and get an answer. It’s built to feel like a conversation with an agronomist friend — not a machine. What was challenging? The hardest part was resisting the urge to overcomplicate things. I had a full dataset with 14 columns — Electrical Conductivity, Organic Carbon, Wind Speed, Field Area, Mulching Used, Water Source, Region, Irrigation Type — all begging to be used. But irrigation need doesn’t come from 14 things. It comes from a handful of core drivers: soil moisture, rainfall, temperature, crop stage, and soil type. So I chose essentials over impressiveness. That meant leaving out data that didn’t move the needle, trusting that farmers know their fields better than any dashboard ever could. Another challenge: the dataset is unbalanced. About 59% show Low irrigation need, 38% show Medium, and only 3% show High. High need is genuinely rare — it only happens when moisture is low AND rainfall is low AND temperatures are high simultaneously. Getting the model to recognize that rarity without over-predicting High was a delicate balance. What am I proud of? The explanation layer. It would have been easy to just show “Low” and move on. But that’s not useful. What’s useful is telling someone WHY the model said Low — so they can trust it, disagree with it, or learn something about their field. The explanation reads like: “Based on adequate soil moisture, good recent rainfall, and moderate temperatures, the model suggests Low irrigation need.” That’s just connecting the dots in a way that makes sense to a human who’s been watching the sky and feeling the soil. I’m also proud of the confidence bars. They’re simple — three horizontal bars — but they tell a story. When you see “Low: 72%, Medium: 22%, High: 6%” you know the model isn’t guessing. It’s weighing evidence. And when you see a tight spread — say, 45% / 40% / 15% — you know the conditions are borderline, and maybe you should trust your own judgment more. What should people know to test my project? Here’s how to kick the tires: Open the page in any modern browser (Chrome, Firefox, Safari, Edge — they all work). Play with the sliders and dropdowns. Try extreme conditions: Dry scenario: Moisture = 10%, Rainfall = 0mm, Temperature = 40°C → should return High. Wet scenario: Moisture = 55%, Rainfall = 1200mm, Temperature = 18°C → should return Low. Borderline: Moisture = 30%, Rainfall = 200mm, Temperature = 28°C, Crop = Rice, Stage = Flowering → often returns Medium with narrow confidence. Read the explanation. Does it match what you’d expect? Does it feel like a real agronomist talking? Look at the confidence bars. Are they wide or narrow? That tells you how clear-cut the conditions are. The tool is trained on 10,000 records across four soil types, six crops, and three seasons. The model logic is rule-based — not a neural network, but a carefully weighted decision system that mimics how an agronomist thinks. It’s transparent, predictable, and easy to tweak. Know before you water. Save what the soil already has. — AquaRead...
|
1793775321.6799097
|
1794639321.6799097
|
|
24518
|
FAST by @Slayer | Stardance
|
Slayer
|
1
|
8.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-25T06:36:40Z", "hours": 8.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I have built a single page website for the students. Students who just passed their Fsc exams are now willing to take admission in the universties. FAST NUCES is one of the top universties of Pakistan. They conduct their own entry test. My website will help students to calculate thier aggegate according to thier test marks, matric and fsc marks.", "repo": "https://github.com/SlayerArman/FAST", "demo": "https://slayerarman.github.io/FAST/"}]...
|
[{"post_id": 15508, "ts": "202 [{"post_id": 15508, "ts": "2026-06-25T06:25:35Z", "hours": 3.0, "text": "So the project is finally finished and I am gonna ship it. I hope it get a good review. All the error and the calculation problems are fixed now. It shows correct aggregate according to the policy of FAST NUCES Entry Test Program. As the tests are happening now students can use this website to calculate their aggregate easily. They could also check the previous merit lists of the universty."}, {"post_id": 15182, "ts": "2026-06-24T17:48:05Z", "hours": 3.0, "text": "Added the buttons for better user interaction. This website helps students to calculate merits of FAST Universty."}, {"post_id": 14823, "ts": "2026-06-24T02:24:06Z", "hours": 2.0, "text": "No AI Copy Pasting. Pure 330+ lines typed with my fingers in 2h."}]...
|
Title: FAST by @Slayer | Stardance
Devlogs:
No AI Title: FAST by @Slayer | Stardance
Devlogs:
No AI Copy Pasting. Pure 330+ lines typed with my fingers in 2h.
Added the buttons for better user interaction. This website helps students to calculate merits of FAST Universty.
So the project is finally finished and I am gonna ship it. I hope it get a good review. All the error and the calculation problems are fixed now. It shows correct aggregate according to the policy of FAST NUCES Entry Test Program. As the tests are happening now students can use this website to calculate their aggregate easily. They could also check the previous merit lists of the universty.
Ships:
I have built a single page website for the students. Students who just passed their Fsc exams are now willing to take admission in the universties. FAST NUCES is one of the top universties of Pakistan. They conduct their own entry test. My website will help students to calculate thier aggegate according to thier test marks, matric and fsc marks....
|
1793775320.6018763
|
1794639320.6018763
|
|
3639
|
My awesome macropad! by @Rondomdude | Stardance
|
Rondomdude
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Rondomdude | Stard Title: My awesome macropad! by @Rondomdude | Stardance...
|
1793775316.7808003
|
1794380116.7808003
|
|
26857
|
pefiaOS , a bare-metal x86 operating system with a pefiaOS , a bare-metal x86 operating system with a graphical shell by @f | Stardance...
|
f
|
1
|
40.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-29T19:38:25Z", "hours": 7.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Overview pefiaOS is a bare metal 32-bit x86 operating system written entirely from scratch in C and NASM. It contains around 9,000 lines of kernel code with no libc or third party kernel code. Features Graphical desktop with overlapping windows, taskbar, Start menu, and window manager Complete networking stack (Ethernet, ARP, IPv4, ICMP, UDP, DHCP, DNS, TCP) TLS 1.3 implementation from scratch for real HTTPS support Web browser with HTML rendering and inline image support Five built in games including Flappy Bird, Pong, Tetris, a Mario style platformer, and a Wolfenstein style raycaster Runs the original 1993 DOOM through PureDOOM inside a desktop window Challenges Some of the more difficult parts of the project included: Writing TLS 1.3 and its cryptographic primitives entirely from scratch Building a complete TCP/IP networking stack without timer interrupts Implementing DEFLATE, JPEG, and BMP decoders by hand Running everything in a cooperative single threaded kernel Integrating the real DOOM engine into a freestanding bare metal environment Highlights I’m especially proud that pefiaOS isn’t just a toy kernel. It can browse the real web over HTTPS, run a full graphical desktop, play games, and even run the original DOOM, all on hardware with no host operating system, no libc, and no runtime underneath. Running pefiaOS After building the cross compiler, simply run: make make run Or boot pefiaOS.iso in VirtualBox using an Intel PRO/1000 network adapter. Things to try Browse a real HTTPS website Play one of the built in games Launch DOOM from the Start menu Open the terminal and run about Capture network traffic with make run-net Current limitations No audio support yet TLS does not verify server certificates No preemptive multitasking No JavaScript engine The part that still feels surreal is watching the OS boot, opening the browser, and loading real HTTPS websites from the internet on an operating system I built entirely from scratch.", "repo": "https://github.com/pefia/pefiaos", "demo": "https://github.com/pefia/pefiaOS/releases/tag/v1.3"}]...
|
[{"post_id": 35746, "ts": "202 [{"post_id": 35746, "ts": "2026-07-27T11:53:45Z", "hours": 6.0, "text": "67 hours !!!!!!!! This update was mainly about improving the web browser and fixing bugs I found across the OS. The browser is now much more capable than before. I added a much better CSS engine, a lot more JavaScript features, proper form support with POST requests, cookies, animated GIFs, media placeholders, and lots of networking improvements. I also changed the homepage to DuckDuckGo Lite, so you can actually search the web from inside pefiaOS. I also fixed several kernel bugs, including memory corruption issues, framebuffer bugs, safer memory management, more reliable timing, and network driver improvements. Building the OS is easier now too. If you don’t have the cross compiler installed, it can now use your system GCC instead. I also improved VM compatibility by adding better diagnostics when booting with the wrong firmware. There is still a lot I want to add, like UTF-8 support, certificate verification, paging, and user mode, but this is the biggest browser update pefiaOS has had so far."}, {"post_id": 31701, "ts": "2026-07-20T09:56:29Z", "hours": 15.0, "text": "Devlog 05 - The Return: Giving pefiaOS a real kernel This update was mostly focused on replacing a lot of the “fake OS” parts with real operating system infrastructure. The biggest milestone was getting interrupts working. I added my own GDT, built an IDT with exception and IRQ handlers, remapped the PIC, programmed the PIT to 100 Hz, and implemented kernel threads with a handwritten x86 context switch. The scheduler is still cooperative because the heap and window manager aren’t thread safe enough for preemption yet, but background threads can finally run independently. I also wrote an ATA PIO driver capable of reading and writing real IDE disks using LBA28 addressing. On top of that I rewrote the VFS into a writable, heap-backed filesystem, so applications can now create, modify and delete files instead of relying on a compile-time file table. Persistence is still missing, but FAT32 can now be built on top of the driver. The desktop gained a lot of new functionality too. The code editor now supports syntax highlighting and line numbers, the terminal gained proper filesystem commands like mkdir , touch , rm , cat , echo > file , and ps , and I added both C and Python-style interpreters using the same recursive descent expression engine. Graphics also received a major upgrade. The desktop now runs at 1920x1080 and I replaced the old 1-bit bitmap font with grayscale anti-aliased glyphs generated from Consolas. The renderer blends glyph coverage into the framebuffer, making text much easier to read without changing any existing layouts. I also improved the desktop itself with window snapping, a scrollable Start menu, a live Settings app for themes and system settings, interactive browser text inputs, and a number of browser rendering improvements including larger page support and faster text drawing. The hardest part was getting all these systems working together. Interrupts initially caused repeated triple faults because my descriptor tables were wrong, the scheduler had to coexist with the existing window manager, and changing the VFS meant updating almost every built-in application. To make sure nothing regressed, I added a boot self-test that verifies the interpreter, writable VFS, scheduler, timer interrupts and ATA disk driver every time the OS starts. Things I’d love people to test: Open multiple windows and try snapping them around the desktop. Use the terminal to create, edit and delete files. Open the code editor and test syntax highlighting. Try typing into browser text inputs. Change the desktop theme and accent colour in Settings. This update doesn’t add one huge feature, but it lays the groundwork for the next major milestones: paging, user-mode processes, ELF loading, and a persistent filesystem."}, {"post_id": 21661, "ts": "2026-07-03T18:50:12Z", "hours": 12.0, "text": "Devlog — Snake, Breakout, a Smarter Shell, and Build Hygiene This week I added two new games (Snake and Breakout, bringing the total to seven), expanded the shell with new built-ins and command history, and cleaned up the build system. Everything boots and runs in QEMU. Snake The ring buffer approach makes movement O(1) instead of O(n): uint16_t s_body [ SN_CAP ]; /* ring buffer of cell indices */ int s_head , s_len ; Input and movement run on separate clocks. Input latches every 33 ms, movement every 130 - 4×score ms (minimum 60 ms). This way no keypresses drop and difficulty scales naturally. The grid is 16 pixel cells, clamped to window size. Apples spawn via rejection sampling. Filling the entire board wins the round. Breakout 26.6 fixed point physics handles shallow angles that integer pixels would quantise to zero. Paddle english depends on where you hit it: int off = bx - g -> k_px ; g -> k_bvy = - g -> k_bvy ; g -> k_bvx = ( off << 6 ) / ( pw / 6 ); Ball starts stuck to the paddle, launches with Space. Three lives, then game over. Integration Adding two games touched almost no window-manager code. Two enum entries in games.h , two lines per dispatch switch in games.c , and the Start menu entry in taskbar.c . The WM handles everything else automatically. Shell Improvements Added five new built-ins: free , uptime , history , ver , and fixed echo to print blank lines. Terminal got uptime too. One Version String #define PEFIA_VERSION \"pefiaOS 0.3 (Stardance)\" All three places that display version now build from this single define. Build Fixes Fixed header dependency tracking: CFLAGS += -MMD -MP -include $(OBJS:.o=.d) Editing a header now correctly rebuilds only the objects that include it. Cleaned up boot.asm trailing whitespace too. Testing Verified in my virtual machine: both games launch and play correctly, Terminal shows the new version string, all shell commands work. Seven games on a kernel I wrote from scratch!! :D"}, {"post_id": 18560, "ts": "2026-06-29T19:08:55Z", "hours": 1.0, "text": "Bringing Games (and DOOM) to pefiaOS This update was all about making pefiaOS capable of running real time applications. The desktop was originally designed around event driven apps, so games needed quite a bit of work before they were even possible. What’s new? Off screen rendering to eliminate flickering Proper held key input for responsive controls Fixed timestep game loop Resizable game windows Flappy Bird Pong Tetris Mario style platformer Wolfenstein style 3D raycaster Once those were working, I had to answer the obvious question: can it run DOOM? It turns out it can. I integrated PureDOOM by writing a platform layer that hooks the engine into my own memory allocator, timer, input system, framebuffer, and virtual filesystem. Since there’s no disk driver yet, the shareware WAD is embedded directly into the kernel, meaning DOOM now runs inside a normal desktop window on pefiaOS itself. Seeing the real 1993 DOOM running on an operating system I built from scratch has easily been one of the most rewarding moments of the project so far, and it also kinda shows that it can do something cool too, not just boring kernels and such."}, {"post_id": 18008, "ts": "2026-06-28T23:43:33Z", "hours": 1.0, "text": "PefiaOS Browser Engine Update - 12:35AM Replaced old HTML renderer with a proper DOM tree system Added CSS engine basic cascade box model layout Implemented lightweight JavaScript interpreter variables loops getElementById() innerHTML ⸻ Bug Fix Fixed image caching bug caused by reading bitmap dimensions after freeing memory Issue resulted in images being stored as 0×0 and rendering as blank white boxes PNG rendering now works correctly again (including Google logo) ⸻ Result Pages now render using DOM structure CSS styling is partially functional JavaScript enables basic interactivity Image rendering is stable again Google homepage renders significantly more correctly"}, {"post_id": 17727, "ts": "2026-06-28T17:16:30Z", "hours": 3.0, "text": "I have currently written the operating system from scratch, created a GUI (Graphical User Interface) and a window manager. I have apps such as a terminal with Linux-inspired commands and a working Browser written from scratch! Google doesn’t serve plain HTTP anymore, so getting to google.com meant implementing modern cryptography inside my own kernel. I ended up writing SHA-256, HMAC/HKDF, AES-128-GCM and X25519 myself before finally getting the handshake to complete. Most of the debugging came down to tiny mistakes—one incorrect byte somewhere could make the whole connection fail. Once that finally worked, I could build the browser on top of it. Right now it has a basic HTTP client and a renderer that supports enough HTML and CSS to display text with word wrapping, links and scrolling."}]...
|
Title: pefiaOS , a bare-metal x86 operating system Title: pefiaOS , a bare-metal x86 operating system with a graphical shell by @f | Stardance
Devlogs:
I have currently written the operating system from scratch, created a GUI (Graphical User Interface) and a window manager. I have apps such as a terminal with Linux-inspired commands and a working Browser written from scratch! Google doesn’t serve plain HTTP anymore, so getting to google.com meant implementing modern cryptography inside my own kernel. I ended up writing SHA-256, HMAC/HKDF, AES-128-GCM and X25519 myself before finally getting the handshake to complete. Most of the debugging came down to tiny mistakes—one incorrect byte somewhere could make the whole connection fail. Once that finally worked, I could build the browser on top of it. Right now it has a basic HTTP client and a renderer that supports enough HTML and CSS to display text with word wrapping, links and scrolling.
PefiaOS Browser Engine Update - 12:35AM Replaced old HTML renderer with a proper DOM tree system Added CSS engine basic cascade box model layout Implemented lightweight JavaScript interpreter variables loops getElementById() innerHTML ⸻ Bug Fix Fixed image caching bug caused by reading bitmap dimensions after freeing memory Issue resulted in images being stored as 0×0 and rendering as blank white boxes PNG rendering now works correctly again (including Google logo) ⸻ Result Pages now render using DOM structure CSS styling is partially functional JavaScript enables basic interactivity Image rendering is stable again Google homepage renders significantly more correctly
Bringing Games (and DOOM) to pefiaOS This update was all about making pefiaOS capable of running real time applications. The desktop was originally designed around event driven apps, so games needed quite a bit of work before they were even possible. What’s new? Off screen rendering to eliminate flickering Proper held key input for responsive controls Fixed timestep game loop Resizable game windows Flappy Bird Pong Tetris Mario style platformer Wolfenstein style 3D raycaster Once those were working, I had to answer the obvious question: can it run DOOM? It turns out it can. I integrated PureDOOM by writing a platform layer that hooks the engine into my own memory allocator, timer, input system, framebuffer, and virtual filesystem. Since there’s no disk driver yet, the shareware WAD is embedded directly into the kernel, meaning DOOM now runs inside a normal desktop window on pefiaOS itself. Seeing the real 1993 DOOM running on an operating system I built from scratch has easily been one of the most rewarding moments of the project so far, and it also kinda shows that it can do something cool too, not just boring kernels and such.
Devlog — Snake, Breakout, a Smarter Shell, and Build Hygiene This week I added two new games (Snake and Breakout, bringing the total to seven), expanded the shell with new built-ins and command history, and cleaned up the build system. Everything boots and runs in QEMU. Snake The ring buffer approach makes movement O(1) instead of O(n): uint16_t s_body [ SN_CAP ]; /* ring buffer of cell indices */ int s_head , s_len ; Input and movement run on separate clocks. Input latches every 33 ms, movement every 130 - 4×score ms (minimum 60 ms). This way no keypresses drop and difficulty scales naturally. The grid is 16 pixel cells, clamped to window size. Apples spawn via rejection sampling. Filling the entire board wins the round. Breakout 26.6 fixed point physics handles shallow angles that integer pixels would quantise to zero. Paddle english depends on where you hit it: int off = bx - g -> k_px ; g -> k_bvy = - g -> k_bvy ; g -> k_bvx = ( off << 6 ) / ( pw / 6 ); Ball starts stuck to the paddle, launches with Space. Three lives, then game over. Integration Adding two games touched almost no window-manager code. Two enum entries in games.h , two lines per dispatch switch in games.c , and the Start menu entry in taskbar.c . The WM handles everything else automatically. Shell Improvements Added five new built-ins: free , uptime , history , ver , and fixed echo to print blank lines. Terminal got uptime too. One Version String #define PEFIA_VERSION "pefiaOS 0.3 (Stardance)" All three places that display version now build from this single define. Build Fixes Fixed header dependency tracking: CFLAGS += -MMD -MP -include $(OBJS:.o=.d) Editing a header now correctly rebuilds only the objects that include it. Cleaned up boot.asm trailing whitespace too. Testing Verified in my virtual machine: both games launch and play correctly, Terminal shows the new version string, all shell commands work. Seven games on a kernel I wrote from scratch!! :D
Devlog 05 - The Return: Giving pefiaOS a real kernel This update was mostly focused on replacing a lot of the “fake OS” parts with real operating system infrastructure. The biggest milestone was getting interrupts working. I added my own GDT, built an IDT with exception and IRQ handlers, remapped the PIC, programmed the PIT to 100 Hz, and implemented kernel threads with a handwritten x86 context switch. The scheduler is still cooperative because the heap and window manager aren’t thread safe enough for preemption yet, but background threads can finally run independently. I also wrote an ATA PIO driver capable of reading and writing real IDE disks using LBA28 addressing. On top of that I rewrote the VFS into a writable, heap-backed filesystem, so applications can now create, modify and delete files instead of relying on a compile-time file table. Persistence is still missing, but FAT32 can now be built on top of the driver. The desktop gained a lot of new functionality too. The code editor now supports syntax highlighting and line numbers, the terminal gained proper filesystem commands like mkdir , touch , rm , cat , echo > file , and ps , and I added both C and Python-style interpreters using the same recursive descent expression engine. Graphics also received a major upgrade. The desktop now runs at 1920x1080 and I replaced the old 1-bit bitmap font with grayscale anti-aliased glyphs generated from Consolas. The renderer blends glyph coverage into the framebuffer, making text much easier to read without changing any existing layouts. I also improved the desktop itself with window snapping, a scrollable Start menu, a live Settings app for themes and system settings, interactive browser text inputs, and a number of browser rendering improvements including larger page support and faster text drawing. The hardest part was getting all these systems working together. Interrupts initially caused repeated triple faults because my descriptor tables were wrong, the scheduler had to coexist with the existing window manager, and changing the VFS meant updating almost every built-in application. To make sure nothing regressed, I added a boot self-test that verifies the interpreter, writable VFS, scheduler, timer interrupts and ATA disk driver every time the OS starts. Things I’d love people to test: Open multiple windows and try snapping them around the desktop. Use the terminal to create, edit and delete files. Open the code editor and test syntax highlighting. Try typing into browser text inputs. Change the desktop theme and accent colour in Settings. This update doesn’t add one huge feature, but it lays the groundwork for the next major milestones: paging, user-mode processes, ELF loading, and a persistent filesystem.
67 hours !!!!!!!! This update was mainly about improving the web browser and fixing bugs I found across the OS. The browser is now much more capable than before. I added a much better CSS engine, a lot more JavaScript features, proper form support with POST requests, cookies, animated GIFs, media placeholders, and lots of networking improvements. I also changed the homepage to DuckDuckGo Lite, so you can actually search the web from inside pefiaOS. I also fixed several kernel bugs, including memory corruption issues, framebuffer bugs, safer memory management, more reliable timing, and network driver improvements. Building the OS is easier now too. If you don’t have the cross compiler installed, it can now use your system GCC instead. I also improved VM compatibility by adding better diagnostics when booting with the wrong firmware. There is still a lot I want to add, like UTF-8 support, certificate verification, paging, and user mode, but this is the biggest browser update pefiaOS has had so far.
Ships:
Overview pefiaOS is a bare metal 32-bit x86 operating system written entirely from scratch in C and NASM. It contains around 9,000 lines of kernel code with no libc or third party kernel code. Features Graphical desktop with overlapping windows, taskbar, Start menu, and window manager Complete networking stack (Ethernet, ARP, IPv4, ICMP, UDP, DHCP, DNS, TCP) TLS 1.3 implementation from scratch for real HTTPS support Web browser with HTML rendering and inline image support Five built in games including Flappy Bird, Pong, Tetris, a Mario style platformer, and a Wolfenstein style raycaster Runs the original 1993 DOOM through PureDOOM inside a desktop window Challenges Some of the more difficult parts of the project included: Writing TLS 1.3 and its cryptographic primitives entirely from scratch Building a complete TCP/IP networking stack without timer interrupts Implementing DEFLATE, JPEG, and BMP decoders by hand Running everything in a cooperative single threaded kernel Integrating the real DOOM engine into a freestanding bare metal environment Highlights I’m especially proud that pefiaOS isn’t just a toy kernel. It can browse the real web over HTTPS, run a full graphical desktop, play games, and even run the original DOOM, all on hardware with no host operating system, no libc, and no runtime underneath. Running pefiaOS After building the cross compiler, simply run: make make run Or boot pefiaOS.iso in VirtualBox using an Intel PRO/1000 network adapter. Things to try Browse a real HTTPS website Play one of the built in games Launch DOOM from the Start menu Open the terminal and run about Capture network traffic with make run-net Current limitations No audio support yet TLS does not verify server certificates No preemptive multitasking No JavaScript engine The part that still feels surreal is watching the OS boot, opening the browser, and loading real HTTPS websites from the internet on an operating system I built entirely from scratch....
|
1793775313.8599014
|
1794639313.8599014
|
|
21311
|
Called It by @prajithvishnur | Stardance
|
prajithvishnur
|
2
|
12.0
|
84
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-09T18:11:55Z", "hours": 5.0, "multiplier": 11.52, "payout": 50, "blessing": "neutral", "text": "I just worked on making the app better, and I think it’s ready to be reshipped. I worked on rewriting more stuff without the AI.", "repo": "https://github.com/prajith-vishnu/called-it", "demo": "https://called-it-self.vercel.app"}, {"ship_num": 2, "ts": "2026-07-02T14:51:05Z", "hours": 7.0, "multiplier": 6.54, "payout": 34, "blessing": "neutral", "text": "Called It is a free prediction game where you call outcomes of real events like NASA missions, sports, and pop culture, then earn points and streaks for being right, with no money involved. The hardest part was making it feel alive on a free AI tier: new predictions are posted automatically several times a day, but the pipeline is capped, rate-limited, and retries safely, so it never breaks or overspends. I am most proud of the crowd system: your score reflects picks made by real players, and beating the crowd on a bold pick pays off more than following the favorite. To test it, just open the site, lock in a few picks on the feed, check the Space and NASA category, and look at the leaderboard and streaks to see the scoring in action.", "repo": "https://github.com/prajith-vishnu/called-it", "demo": "https://called-it-self.vercel.app"}]...
|
[{"post_id": 22907, "ts": "202 [{"post_id": 22907, "ts": "2026-07-05T15:29:44Z", "hours": 1.2042, "text": "Made some small changes. nothing major. project is working well."}, {"post_id": 21549, "ts": "2026-07-03T15:52:42Z", "hours": 0.6978, "text": "Changed up the website’s look, hosted on Vercel, and fixed the sign-in issues."}, {"post_id": 21231, "ts": "2026-07-03T02:02:39Z", "hours": 1.6664, "text": "Changed website to be hosted on vercel and made some tweaks"}, {"post_id": 20968, "ts": "2026-07-02T18:17:28Z", "hours": 0.915, "text": "Rewrote the readme and added features like pick of the day, dark mode, and sound effects."}, {"post_id": 20820, "ts": "2026-07-02T15:04:19Z", "hours": 1.0022, "text": "Fixed some bugs post ship… and updated the readme."}, {"post_id": 20777, "ts": "2026-07-02T13:58:58Z", "hours": 0.5808, "text": "Added a Space and NASA category! The app is lowk looking really good rn :)"}, {"post_id": 20510, "ts": "2026-07-02T03:47:09Z", "hours": 1.2494, "text": "Added a sign-in that uses a username and password. I also added a streak that gives you more points for coming back daily!"}, {"post_id": 20420, "ts": "2026-07-02T00:45:48Z", "hours": 0.5619, "text": "Got a working prototype and I think it’s looking really cool! Working on making the AI API work (most likely going to try to use Grok)."}, {"post_id": 20196, "ts": "2026-07-01T19:00:17Z", "hours": 4.8364, "text": "Came up with the idea for the project to try to create a free predictions market where the only thing you get are bragging rights with no money involved. I hope this goes well! I have been working on the code and almost have a prototype ready!"}]...
|
Title: Called It by @prajithvishnur | Stardance
D Title: Called It by @prajithvishnur | Stardance
Devlogs:
Came up with the idea for the project to try to create a free predictions market where the only thing you get are bragging rights with no money involved. I hope this goes well! I have been working on the code and almost have a prototype ready!
Got a working prototype and I think it’s looking really cool! Working on making the AI API work (most likely going to try to use Grok).
Added a sign-in that uses a username and password. I also added a streak that gives you more points for coming back daily!
Added a Space and NASA category! The app is lowk looking really good rn :)
Fixed some bugs post ship… and updated the readme.
Rewrote the readme and added features like pick of the day, dark mode, and sound effects.
Changed website to be hosted on vercel and made some tweaks
Changed up the website’s look, hosted on Vercel, and fixed the sign-in issues.
Made some small changes. nothing major. project is working well.
Ships:
Called It is a free prediction game where you call outcomes of real events like NASA missions, sports, and pop culture, then earn points and streaks for being right, with no money involved. The hardest part was making it feel alive on a free AI tier: new predictions are posted automatically several times a day, but the pipeline is capped, rate-limited, and retries safely, so it never breaks or overspends. I am most proud of the crowd system: your score reflects picks made by real players, and beating the crowd on a bold pick pays off more than following the favorite. To test it, just open the site, lock in a few picks on the feed, check the Space and NASA category, and look at the leaderboard and streaks to see the scoring in action.
I just worked on making the app better, and I think it’s ready to be reshipped. I worked on rewriting more stuff without the AI....
|
1793775312.6376421
|
1793861712.6376421
|
|
17412
|
NASA CONTROL SIM by @nishchaybhudia | Stardance
|
nishchaybhudia
|
1
|
11.0
|
182
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-14T13:53:55Z", "hours": 11.0, "multiplier": 16.59, "payout": 182, "blessing": "neutral", "text": "What I made I created a NASA style rocket simulator in Pygame with launch, orbit, and also mission selection. Players control a rocket, manage fuel and try to reach orbit. In orbit, they deploy satellites while avoiding debris and timing orbital windows. What was challenging … The hardest part was managing multiple game states without breaking transitions between them. Balancing the rocket physics so it feels realistic but still fun took a lot of tweaking. The angle maths for orbital windows and debris collision detection was also tricky. What I was proud of . I’m proud of the orbital gameplay because it adds timing and strategy beyond simple movement. The mission system changes difficulty in a meaningful way without changing the core game. The HUD, logs, and effects make the game feel complete and immersive. What people should know to test my project SPACE toggles the engine, R fixes engine failure, and D deploys satellites in orbit. The goal is to reach 80,000m and then deploy 3 satellites in green windows. Fuel, debris, and random failures can end a run early, so timing matters.", "repo": "https://github.com/Hidden-Ghost-123/NASA---CONTROL-DESK", "demo": "https://nbhudia.itch.io/nasa-rocket-mission-control"}]...
|
[{"post_id": 13838, "ts": "202 [{"post_id": 13838, "ts": "2026-06-22T17:57:07Z", "hours": 0.0, "text": "finshing off sharpening the UI . make changes to the corners of the screen and make the rocket launch smoother ."}, {"post_id": 8670, "ts": "2026-06-14T12:30:52Z", "hours": 1.0, "text": "Particle system: engine exhaust emits orange/yellow/red particles with lifetime, fade, and spread. Stage sep triggers a burst of white sparks. Screen shake: triggers on engine failure, stage sep, debris near miss, and collision. Magnitude + decay. Mission Select screen (new state before LAUNCH): STANDARD default settings, good starting point EXPRESS 70% fuel, fewer events, big time bonus DEBRIS STORM 9 debris pieces, more failures Mission name shown throughout HUD + logged on win. High score table: session based top 5 per mission. Shown on WIN screen; press H on menu to view all. Polished WIN screen: animated green scan lines + stars. FAIL screen: shows cause + survival time. Throttle bar added to HUD (shows ramp state). Rocket engine on indicator (green light on HUD). Debris proximity warning shown as distance readout. Orbital window “ping” animation when window opens."}, {"post_id": 8231, "ts": "2026-06-13T18:10:13Z", "hours": 0.0, "text": "• OrbitalWindow system: 3 rotating green arcs on the orbit ring. D key ONLY works when rocket is inside a window. Windows slowly drift at different speeds timing matters. A window goes grey and cooldown after each deployment. DebrisField: 5 pieces of orbiting space junk at varying radii/speeds (some retrograde). Collision = instant FAIL. Proximity warning: debris glows red + screen edge pulses when within 42px. Collision radius: 16px. Throttle upgraded: SPACE toggles, but engine now throttles UP gradually over 1 sec to add drama to ignition. Score breakdown: fuel bonus + time bonus + sat bonus, all shown separately on the WIN screen. FAIL now shows cause: collision vs fuel-out vs pad abort. Orbit panel (right-side): shows window status, debris count, and DEPLOY hint when inside a window. Max altitude cap removed: rocket keeps climbing during launch phase until fuel/orbit condition met. Random event rates tuned so failures feel fair, not cheap."}, {"post_id": 8126, "ts": "2026-06-13T15:53:35Z", "hours": 0.0, "text": "Full state machine: MENU , LAUNCH ,ORBIT , WIN / FAIL Menu screen with controls panel + mission briefing panel Animated bouncing rocket on menu with pulsing prompt Engine repair mechanic: press R after engine failure Fuel leak doesn’t insta kill; manageable drain Star field that alpha fades in as altitude climbs Rocket fins added, gravity turn tilt hinted HUD rewritten: Flight Computer panel and two progress bars (FUEL bar and ALTITUDE TO ORBIT bar during launch) Stage separation auto fires at 20 km with log message WIN / FAIL overlays with ENTER to restart ESC quits from anywhere Score calculation on win (fuel × 12 + time bonus) Satellite now drawn with solar panels Delta time physics: physics no longer frame rate dependent"}, {"post_id": 8077, "ts": "2026-06-13T14:17:08Z", "hours": 0.0, "text": "Features Added : Stage Separation System Automatic transition from Stage 1 to Stage 2 during ascent Stage specific performance changes Increased thrust and fuel capacity after separation Enhanced Orbital Behaviour Improved orbital movement calculations Orbit speed now varies based on spacecraft state Smoother transition from ascent to orbital operations Re entry Heat Framework Introduced atmospheric heating mechanics Heat accumulation and cooling systems Visual warning indicators for dangerous conditions"}, {"post_id": 8038, "ts": "2026-06-13T12:18:20Z", "hours": 1.0, "text": "focused on turning the simulator into a complete playable game with objectives, structure and also end conditions. new features added : Full mission win condition (deploy 3 satellites to succeed) Full mission fail condition (fuel depletion with no progress) Central Game controller system to manage all logic Clean separation between update and UI handling Global mission states: launch, orbit, win, fail Large scale integration of all previous systems into one loop"}, {"post_id": 7994, "ts": "2026-06-13T10:29:08Z", "hours": 1.0, "text": "introduced instability into the simulation, turning it from a controlled mission tool into a reactive system where things can go wrong. Features Added are : Random event system running during flight Engine failure state (thrust stops working) Fuel leak simulation (accelerated fuel loss) System recovery events that can restore functionality Expanded mission log integration for emergencies Status indicators reflecting system health in real time Events affecting both launch and orbit modes. i made the simulation non deterministic for the first time"}, {"post_id": 7971, "ts": "2026-06-13T09:14:19Z", "hours": 1.0, "text": "This was the first major shift in the simulators structure, moving from a single continuous launch system into a dual-mode mission environment. features added : Introduced Launch Mode … Orbit Mode switching (M key) Built a basic orbital map centered on earth Rocket now transitions from ascent simulation into orbital representation Added satellite deployment system (D key in orbit mode) Multiple satellites can now exist simultaneously in orbit Each satellite follows independent circular orbital motion around earth ( blue circle)"}, {"post_id": 7634, "ts": "2026-06-12T19:12:54Z", "hours": 1.0, "text": "focused on transforming the simulator from a basic rocket launch prototype into a proper mission control experience. features Added : Mission timer with NASA-style T+MM:SS formatting Dedicated Mission Control telemetry panel Mission event logging system Flight status tracking (On Pad, Ascent, High Ascent, Edge of Space, Space) Low fuel warning system Karman Line detection and milestone event logging Improved altitude and velocity scaling"}, {"post_id": 7584, "ts": "2026-06-12T17:59:55Z", "hours": 1.0, "text": "focused on making the simulator feel like an actual ascent through Earth’s atmosphere rather than a simple vertical movement game. Features Added : Dynamic sky that gradually transitions from blue atmosphere to the darkness of space. Basic atmospheric drag system that slows the rocket at lower altitudes. Altitude based environment changes. Space/Atmosphere status indicator in the telemetry panel. Improved flight behaviour through updated physics tuning."}, {"post_id": 7554, "ts": "2026-06-12T16:56:37Z", "hours": 0.0, "text": "I built the foundation of a NASA style mission simulator in Pygame. The focus was keeping everything simple but physically believable enough to feel like a real launch system. What i added : A controllable rocket object with basic physics Gravity pulling the rocket down constantly Thrust system controlled by toggling the engine (SPACE BAR) Fuel consumption that decreases while the engine is active Altitude and velocity tracking in real time A basic HUD showing mission telemetry (altitude, speed, fuel, engine state) Simple visual representation of a rocket with a flame animation Ground reference to give a sense of scale Result: You can now launch a rocket from the ground, control its thrust, and watch it respond to gravity and fuel constraints while tracking live telemetry like a simplified NASA test console."}]...
|
Title: NASA CONTROL SIM by @nishchaybhudia | Stard Title: NASA CONTROL SIM by @nishchaybhudia | Stardance
Devlogs:
I built the foundation of a NASA style mission simulator in Pygame. The focus was keeping everything simple but physically believable enough to feel like a real launch system. What i added : A controllable rocket object with basic physics Gravity pulling the rocket down constantly Thrust system controlled by toggling the engine (SPACE BAR) Fuel consumption that decreases while the engine is active Altitude and velocity tracking in real time A basic HUD showing mission telemetry (altitude, speed, fuel, engine state) Simple visual representation of a rocket with a flame animation Ground reference to give a sense of scale Result: You can now launch a rocket from the ground, control its thrust, and watch it respond to gravity and fuel constraints while tracking live telemetry like a simplified NASA test console.
focused on making the simulator feel like an actual ascent through Earth’s atmosphere rather than a simple vertical movement game. Features Added : Dynamic sky that gradually transitions from blue atmosphere to the darkness of space. Basic atmospheric drag system that slows the rocket at lower altitudes. Altitude based environment changes. Space/Atmosphere status indicator in the telemetry panel. Improved flight behaviour through updated physics tuning.
focused on transforming the simulator from a basic rocket launch prototype into a proper mission control experience. features Added : Mission timer with NASA-style T+MM:SS formatting Dedicated Mission Control telemetry panel Mission event logging system Flight status tracking (On Pad, Ascent, High Ascent, Edge of Space, Space) Low fuel warning system Karman Line detection and milestone event logging Improved altitude and velocity scaling
This was the first major shift in the simulators structure, moving from a single continuous launch system into a dual-mode mission environment. features added : Introduced Launch Mode … Orbit Mode switching (M key) Built a basic orbital map centered on earth Rocket now transitions from ascent simulation into orbital representation Added satellite deployment system (D key in orbit mode) Multiple satellites can now exist simultaneously in orbit Each satellite follows independent circular orbital motion around earth ( blue circle)
introduced instability into the simulation, turning it from a controlled mission tool into a reactive system where things can go wrong. Features Added are : Random event system running during flight Engine failure state (thrust stops working) Fuel leak simulation (accelerated fuel loss) System recovery events that can restore functionality Expanded mission log integration for emergencies Status indicators reflecting system health in real time Events affecting both launch and orbit modes. i made the simulation non deterministic for the first time
focused on turning the simulator into a complete playable game with objectives, structure and also end conditions. new features added : Full mission win condition (deploy 3 satellites to succeed) Full mission fail condition (fuel depletion with no progress) Central Game controller system to manage all logic Clean separation between update and UI handling Global mission states: launch, orbit, win, fail Large scale integration of all previous systems into one loop
Features Added : Stage Separation System Automatic transition from Stage 1 to Stage 2 during ascent Stage specific performance changes Increased thrust and fuel capacity after separation Enhanced Orbital Behaviour Improved orbital movement calculations Orbit speed now varies based on spacecraft state Smoother transition from ascent to orbital operations Re entry Heat Framework Introduced atmospheric heating mechanics Heat accumulation and cooling systems Visual warning indicators for dangerous conditions
Full state machine: MENU , LAUNCH ,ORBIT , WIN / FAIL Menu screen with controls panel + mission briefing panel Animated bouncing rocket on menu with pulsing prompt Engine repair mechanic: press R after engine failure Fuel leak doesn’t insta kill; manageable drain Star field that alpha fades in as altitude climbs Rocket fins added, gravity turn tilt hinted HUD rewritten: Flight Computer panel and two progress bars (FUEL bar and ALTITUDE TO ORBIT bar during launch) Stage separation auto fires at 20 km with log message WIN / FAIL overlays with ENTER to restart ESC quits from anywhere Score calculation on win (fuel × 12 + time bonus) Satellite now drawn with solar panels Delta time physics: physics no longer frame rate dependent
• OrbitalWindow system: 3 rotating green arcs on the orbit ring. D key ONLY works when rocket is inside a window. Windows slowly drift at different speeds timing matters. A window goes grey and cooldown after each deployment. DebrisField: 5 pieces of orbiting space junk at varying radii/speeds (some retrograde). Collision = instant FAIL. Proximity warning: debris glows red + screen edge pulses when within 42px. Collision radius: 16px. Throttle upgraded: SPACE toggles, but engine now throttles UP gradually over 1 sec to add drama to ignition. Score breakdown: fuel bonus + time bonus + sat bonus, all shown separately on the WIN screen. FAIL now shows cause: collision vs fuel-out vs pad abort. Orbit panel (right-side): shows window status, debris count, and DEPLOY hint when inside a window. Max altitude cap removed: rocket keeps climbing during launch phase until fuel/orbit condition met. Random event rates tuned so failures feel fair, not cheap.
Particle system: engine exhaust emits orange/yellow/red particles with lifetime, fade, and spread. Stage sep triggers a burst of white sparks. Screen shake: triggers on engine failure, stage sep, debris near miss, and collision. Magnitude + decay. Mission Select screen (new state before LAUNCH): STANDARD default settings, good starting point EXPRESS 70% fuel, fewer events, big time bonus DEBRIS STORM 9 debris pieces, more failures Mission name shown throughout HUD + logged on win. High score table: session based top 5 per mission. Shown on WIN screen; press H on menu to view all. Polished WIN screen: animated green scan lines + stars. FAIL screen: shows cause + survival time. Throttle bar added to HUD (shows ramp state). Rocket engine on indicator (green light on HUD). Debris proximity warning shown as distance readout. Orbital window “ping” animation when window opens.
finshing off sharpening the UI . make changes to the corners of the screen and make the rocket launch smoother .
Ships:
What I made I created a NASA style rocket simulator in Pygame with launch, orbit, and also mission selection. Players control a rocket, manage fuel and try to reach orbit. In orbit, they deploy satellites while avoiding debris and timing orbital windows. What was challenging … The hardest part was managing multiple game states without breaking transitions between them. Balancing the rocket physics so it feels realistic but still fun took a lot of tweaking. The angle maths for orbital windows and debris collision detection was also tricky. What I was proud of . I’m proud of the orbital gameplay because it adds timing and strategy beyond simple movement. The mission system changes difficulty in a meaningful way without changing the core game. The HUD, logs, and effects make the game feel complete and immersive. What people should know to test my project SPACE toggles the engine, R fixes engine failure, and D deploys satellites in orbit. The goal is to reach 80,000m and then deploy 3 satellites in green windows. Fuel, debris, and random failures can end a run early, so timing matters....
|
1793775310.981973
|
1794639310.981973
|
|
18255
|
Untitled project by @devoflife | Stardance
|
devoflife
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @devoflife | Stardance
|
1793775307.645986
|
1794380107.645986
|
|
21309
|
History Guesser by @Mohamed_Ayadi | Stardance
|
Mohamed_Ayadi
|
1
|
12.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T00:19:52Z", "hours": 12.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a history trivia game called History Guesser. It’s a single HTML file that runs in any browser. The concept is simple. A pin drops on a world map. A year appears at the bottom of the screen. You pick the correct historical event from four options. After you answer, the game shows you a description and a fun fact about the event. You learn something even when you get it wrong. The game has 70 events spread across nine categories. War, Science, Politics, Exploration, Culture, Disaster, Sports, Business, and a few others. There are three difficulty levels. Easy, Medium, and Hard. You can filter by category and difficulty before you start. The game tracks your score and your streak. What I’m proud of The map actually works. The pin lands in the right place for each event. I spent hours tweaking coordinates to get that right. The fun facts are my favorite part. I dug through Wikipedia to find interesting details that stick with you. Little things that make history memorable. The quit button. It took more thought than it should have. Players need a clean way to exit without refreshing the page. I added a visible button plus Escape key support. Small thing, big difference. The design feels warm, not cold and technical. Parchment colors, a compass rose, serif fonts. It feels like an old atlas. That was intentional. What was challenging The map was the hardest part. I tried drawing it with canvas polygons and failed miserably. Africa looked like a blob. Europe looked like a potato. Wasted two days on that approach. Switching to a background image solved the problem but introduced new ones. Event placement was tedious. Every pin needed exact coordinates. I manually positioned 70 events. Refresh the page, adjust by 0.005, refresh again. Over and over. Making difficulty levels feel meaningful was tricky. I mixed obscurity with age. Ancient events are harder by default. Recent ones are easier. It’s not perfect but it works. UI responsiveness took effort. Making the game work on both desktop and mobile required careful testing. Mobile-first approach, tested on actual devices. If you want to test it The game is a single file called index.html. You need a map image called img.jpg in the same folder. Any world map with clear country outlines works. Open index.html in any browser. No server required. No installation. No dependencies. Just double click and play. If the map doesn’t load, check that img.jpg is in the same folder. The file name must be exactly img.jpg. Case matters on some systems. The game also has an online fallback so it should still work. The game should load instantly. The pin should appear smoothly. Buttons respond to both mouse and touch. Everything feels snappy. Try different category and difficulty filters. Each combination changes the event pool significantly. Easy mode has mostly famous recent events. Hard mode tests more obscure moments in history. If you find a bug or have a suggestion for more events, let me know. I’d like to add more categories eventually. Maybe a leaderboard or timer mode. But for now, this version does what I set out to do. It makes history feel less like a textbook and more like a discovery.", "repo": "https://github.com/medayedi123/History-Guesser", "demo": "https://historyguesser.netlify.app/"}]...
|
[{"post_id": 10974, "ts": "202 [{"post_id": 10974, "ts": "2026-06-18T00:13:29Z", "hours": 12.0, "text": "Dev Log So I had this idea. I wanted to make history feel physical, like it actually happened somewhere. Drop a pin. Show the year. Make people guess. That felt more like a game than a textbook. The first version was a disaster. I tried drawing the world map myself using canvas polygons. Two days of tweaking coordinates and my map still looked like a deformed potato. Africa was a blob. Europe looked like it had been through a war. I finally gave up and switched to a real image. Getting the map to work took way longer than I expected. Online images were slow. Base64 was huge. SVG was a nightmare. Eventually I just told people to drop a jpg in the same folder. It’s not fancy, but it works and it’s fast. The pin placement was its own headache. Every event needed exact coordinates. Battle of Hastings needed to hit England. Columbus needed the Caribbean. Hours of refreshing the page and tweaking numbers by tiny amounts. My eyes hurt. But building the event list was actually fun. I dug through Wikipedia looking for interesting stuff. War, science, politics, exploration, culture, disaster. Each event needed a year, location, description, and a fun fact. I probably spent too much time down rabbit holes. Did you know Beethoven was completely deaf when he conducted his ninth symphony? Or that the Mona Lisa has no eyebrows? I don’t regret a single minute of that. Difficulty levels were tricky. I mixed obscurity with age. Ancient stuff is harder. Recent stuff is easier. It’s not perfect but it works. Design wise, I wanted the game to feel warm — like an old atlas, not a corporate dashboard. Parchment colors, a compass rose, serif fonts. I wanted people to feel like they were opening a book from their grandparent’s shelf. The quit button was a small thing that took too much thought. I realized people need an easy way out. So I put one in the corner and added Escape key support. Small detail, big difference. What I learned: the little stuff matters. A good map makes the game feel real. A fun fact turns a correct answer into something you actually remember. A visible quit button shows you respect the user’s time. I also learned that AI is useful for grinding through boilerplate and generating ideas faster than I could alone. But the creative stuff, the polish, the decisions about what actually feels good — that’s still on me. The AI sketches scaffolding. I build the house. The result is a game that loads instantly, works on any device, and teaches you something without feeling like school. It’s not perfect. I’d love to add more events, better visuals, maybe some sound effects. But it’s solid, it’s fun, and I’m happy with it. If you play it and learn one thing you didn’t know before, I’ll consider it a win."}]...
|
Title: History Guesser by @Mohamed_Ayadi | Stardan Title: History Guesser by @Mohamed_Ayadi | Stardance
Devlogs:
Dev Log So I had this idea. I wanted to make history feel physical, like it actually happened somewhere. Drop a pin. Show the year. Make people guess. That felt more like a game than a textbook. The first version was a disaster. I tried drawing the world map myself using canvas polygons. Two days of tweaking coordinates and my map still looked like a deformed potato. Africa was a blob. Europe looked like it had been through a war. I finally gave up and switched to a real image. Getting the map to work took way longer than I expected. Online images were slow. Base64 was huge. SVG was a nightmare. Eventually I just told people to drop a jpg in the same folder. It’s not fancy, but it works and it’s fast. The pin placement was its own headache. Every event needed exact coordinates. Battle of Hastings needed to hit England. Columbus needed the Caribbean. Hours of refreshing the page and tweaking numbers by tiny amounts. My eyes hurt. But building the event list was actually fun. I dug through Wikipedia looking for interesting stuff. War, science, politics, exploration, culture, disaster. Each event needed a year, location, description, and a fun fact. I probably spent too much time down rabbit holes. Did you know Beethoven was completely deaf when he conducted his ninth symphony? Or that the Mona Lisa has no eyebrows? I don’t regret a single minute of that. Difficulty levels were tricky. I mixed obscurity with age. Ancient stuff is harder. Recent stuff is easier. It’s not perfect but it works. Design wise, I wanted the game to feel warm — like an old atlas, not a corporate dashboard. Parchment colors, a compass rose, serif fonts. I wanted people to feel like they were opening a book from their grandparent’s shelf. The quit button was a small thing that took too much thought. I realized people need an easy way out. So I put one in the corner and added Escape key support. Small detail, big difference. What I learned: the little stuff matters. A good map makes the game feel real. A fun fact turns a correct answer into something you actually remember. A visible quit button shows you respect the user’s time. I also learned that AI is useful for grinding through boilerplate and generating ideas faster than I could alone. But the creative stuff, the polish, the decisions about what actually feels good — that’s still on me. The AI sketches scaffolding. I build the house. The result is a game that loads instantly, works on any device, and teaches you something without feeling like school. It’s not perfect. I’d love to add more events, better visuals, maybe some sound effects. But it’s solid, it’s fun, and I’m happy with it. If you play it and learn one thing you didn’t know before, I’ll consider it a win.
Ships:
I made a history trivia game called History Guesser. It’s a single HTML file that runs in any browser. The concept is simple. A pin drops on a world map. A year appears at the bottom of the screen. You pick the correct historical event from four options. After you answer, the game shows you a description and a fun fact about the event. You learn something even when you get it wrong. The game has 70 events spread across nine categories. War, Science, Politics, Exploration, Culture, Disaster, Sports, Business, and a few others. There are three difficulty levels. Easy, Medium, and Hard. You can filter by category and difficulty before you start. The game tracks your score and your streak. What I’m proud of The map actually works. The pin lands in the right place for each event. I spent hours tweaking coordinates to get that right. The fun facts are my favorite part. I dug through Wikipedia to find interesting details that stick with you. Little things that make history memorable. The quit button. It took more thought than it should have. Players need a clean way to exit without refreshing the page. I added a visible button plus Escape key support. Small thing, big difference. The design feels warm, not cold and technical. Parchment colors, a compass rose, serif fonts. It feels like an old atlas. That was intentional. What was challenging The map was the hardest part. I tried drawing it with canvas polygons and failed miserably. Africa looked like a blob. Europe looked like a potato. Wasted two days on that approach. Switching to a background image solved the problem but introduced new ones. Event placement was tedious. Every pin needed exact coordinates. I manually positioned 70 events. Refresh the page, adjust by 0.005, refresh again. Over and over. Making difficulty levels feel meaningful was tricky. I mixed obscurity with age. Ancient events are harder by default. Recent ones are easier. It’s not perfect but it works. UI responsiveness took effort. Making the game work on both desktop and mobile required careful testing. Mobile-first approach, tested on actual devices. If you want to test it The game is a single file called index.html. You need a map image called img.jpg in the same folder. Any world map with clear country outlines works. Open index.html in any browser. No server required. No installation. No dependencies. Just double click and play. If the map doesn’t load, check that img.jpg is in the same folder. The file name must be exactly img.jpg. Case matters on some systems. The game also has an online fallback so it should still work. The game should load instantly. The pin should appear smoothly. Buttons respond to both mouse and touch. Everything feels snappy. Try different category and difficulty filters. Each combination changes the event pool significantly. Easy mode has mostly famous recent events. Hard mode tests more obscure moments in history. If you find a bug or have a suggestion for more events, let me know. I’d like to add more categories eventually. Maybe a leaderboard or timer mode. But for now, this version does what I set out to do. It makes history feel less like a textbook and more like a discovery....
|
1793775304.3470051
|
1794639304.3470051
|
|
16527
|
Asteroid Threat Sim by @nishchaybhudia | Stardance
|
nishchaybhudia
|
1
|
9.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-07T08:26:10Z", "hours": 9.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built a sleek NASA Deep Space Monitoring Matrix that simulates real time ISS tracking, solar weather incident logs and near Earth asteroid risk assessments.. The biggest hurdle was completely rewriting the interface from Python’s desktop based Tkinter framework into responsive HTMLand python so it could run flawlessly directly inside a web browser.I am proud of the dynamic cyber grid tracking map and updating telemetry feeds which you can test directly on itch.io by switching tabs to watch the live simulation matrix react in real time.", "repo": "https://github.com/Hidden-Ghost-123/NASA", "demo": "https://nbhudia.itch.io/nasa-project-v2"}]...
|
[{"post_id": 24625, "ts": "202 [{"post_id": 24625, "ts": "2026-07-08T10:36:04Z", "hours": 0.0, "text": "i added the final fixed files to the github and added a detailed and readable README.md … i also fixed a api bug"}, {"post_id": 23991, "ts": "2026-07-07T08:06:22Z", "hours": 2.0, "text": "i linked the data that the api outputs to the tkinter frontend ui that i began making …. this lead me to many errors such as intiger value errors and data sorting errors…. the data that the api outputs is very volatile as the data is extreamly minute in the data that is to do with satelites and speed and volatility of certain objects … this is not yet finished and cannot run fully yet …."}, {"post_id": 7525, "ts": "2026-06-12T15:49:59Z", "hours": 2.0, "text": "i worked on cleaning up the code and making sure i hit all my targets set in the previous devlog . not all were done.Hit a 429 error during testing when I accidentally called the API in a tight loop. The raw requests traceback is ugly.i then added proper handling. Bug I spent 20 minutes on: Had session.get(url, params, timeout) positionally … but timeout is a keyword argument. Changed to session.get(url, params=params, timeout=timeout). usual silly mistakes ."}, {"post_id": 7459, "ts": "2026-06-12T12:58:49Z", "hours": 1.0, "text": "i Built the first version of the NASA client, enabling access to “astronomy Picture of the day” (APOD), Near Earth object (NEO) feeds, and Mars Rover mission data through reusable API request methods. … looking to add error handling next as it is not in place at the moment"}, {"post_id": 7428, "ts": "2026-06-12T11:33:30Z", "hours": 2.0, "text": "Been reading api.nasa.gov docs for the past hour. Way more data than I expected. APOD, asteroids, Mars photos, space weather, satellite imagery — all free. Some endpoints don’t even need a key. Wrote the simplest possible test before building anything. set up the folder structure. coded the first parts of the config.py ."}]...
|
Title: Asteroid Threat Sim by @nishchaybhudia | St Title: Asteroid Threat Sim by @nishchaybhudia | Stardance
Devlogs:
Been reading api.nasa.gov docs for the past hour. Way more data than I expected. APOD, asteroids, Mars photos, space weather, satellite imagery — all free. Some endpoints don’t even need a key. Wrote the simplest possible test before building anything. set up the folder structure. coded the first parts of the config.py .
i Built the first version of the NASA client, enabling access to “astronomy Picture of the day” (APOD), Near Earth object (NEO) feeds, and Mars Rover mission data through reusable API request methods. … looking to add error handling next as it is not in place at the moment
i worked on cleaning up the code and making sure i hit all my targets set in the previous devlog . not all were done.Hit a 429 error during testing when I accidentally called the API in a tight loop. The raw requests traceback is ugly.i then added proper handling. Bug I spent 20 minutes on: Had session.get(url, params, timeout) positionally … but timeout is a keyword argument. Changed to session.get(url, params=params, timeout=timeout). usual silly mistakes .
i linked the data that the api outputs to the tkinter frontend ui that i began making …. this lead me to many errors such as intiger value errors and data sorting errors…. the data that the api outputs is very volatile as the data is extreamly minute in the data that is to do with satelites and speed and volatility of certain objects … this is not yet finished and cannot run fully yet ….
i added the final fixed files to the github and added a detailed and readable README.md … i also fixed a api bug
Ships:
I built a sleek NASA Deep Space Monitoring Matrix that simulates real time ISS tracking, solar weather incident logs and near Earth asteroid risk assessments.. The biggest hurdle was completely rewriting the interface from Python’s desktop based Tkinter framework into responsive HTMLand python so it could run flawlessly directly inside a web browser.I am proud of the dynamic cyber grid tracking map and updating telemetry feeds which you can test directly on itch.io by switching tabs to watch the live simulation matrix react in real time....
|
1793775303.1016073
|
1794639303.1016073
|
|
30294
|
macOS New Tab by @ahnafiscool | Stardance
|
ahnafiscool
|
1
|
5.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-06T11:43:28Z", "hours": 5.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made macOS themed New Tab page. The project mission looks quite simple and thats the part which makes it hard to stand out from the others. I experimented with various layouts and structures until I came up with the finished UI of the site.", "repo": "https://github.com/AhnafPro/custom-new-tab", "demo": "http://macosnewtab.free.nf/"}]...
|
[{"post_id": 23422, "ts": "202 [{"post_id": 23422, "ts": "2026-07-06T11:31:10Z", "hours": 4.0, "text": "The project is completed and polished after long time with lots n lots of changes. I tried my best to replicate macOS Tahoe theme. Here are all the features: Dock with floating apps (shortcuts) Window containing NASA APOD and News embed. Search bar in the center with classic ‘hello’ placeholder (uses Borel font). Working glassy time, day and date on top."}]...
|
Title: macOS New Tab by @ahnafiscool | Stardance
Title: macOS New Tab by @ahnafiscool | Stardance
Devlogs:
The project is completed and polished after long time with lots n lots of changes. I tried my best to replicate macOS Tahoe theme. Here are all the features: Dock with floating apps (shortcuts) Window containing NASA APOD and News embed. Search bar in the center with classic ‘hello’ placeholder (uses Borel font). Working glassy time, day and date on top.
Ships:
I made macOS themed New Tab page. The project mission looks quite simple and thats the part which makes it hard to stand out from the others. I experimented with various layouts and structures until I came up with the finished UI of the site....
|
1793775298.2161565
|
1794639298.2161565
|
|
17359
|
Frictionless by @Mohamed_Ayadi | Stardance
|
Mohamed_Ayadi
|
1
|
13.0
|
134
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-13T19:38:25Z", "hours": 10.0, "multiplier": 13.37, "payout": 134, "blessing": "neutral", "text": "What did you make? I built Recovery Quest, a web application that transforms recovery and healthy habits into an RPG-style experience. The idea started with a simple observation: taking care of ourselves often feels invisible. You sleep well, eat better, stay active, and make healthier choices, yet it’s hard to see the impact of those small decisions from day to day. Without visible progress, motivation fades. Recovery Quest changes that. Users log information related to their sleep, nutrition, and exercise, and the system evaluates their overall recovery state. Instead of just displaying numbers, the app presents meaningful feedback through game-inspired progression systems. Healthy choices contribute to a sense of growth, turning recovery from an abstract concept into a journey users can actively follow. The goal is simple: make taking care of yourself feel rewarding instead of repetitive. What was challenging? The biggest challenge was designing a system that felt encouraging without oversimplifying recovery. Recovery isn’t determined by a single factor. Sleep, nutrition, and physical activity all influence how someone feels, and I had to think carefully about how these elements should work together to generate useful feedback. Another challenge was balancing the RPG elements. I didn’t want Recovery Quest to become just another game with health-themed decorations. The progression systems had to support the main purpose of the app: helping users understand and improve their recovery habits. Finding that balance between engagement and meaningful feedback required a lot of experimentation and refinement. What are you proud of? I’m proud that Recovery Quest makes something invisible feel visible. Recovery is difficult to measure in everyday life. Most people don’t notice the cumulative effect of sleeping better, eating more consistently, or exercising regularly until weeks later. Recovery Quest highlights those small victories. Users can see how their habits influence their recovery state and receive feedback that encourages them to continue building healthier routines. I’m also proud that I built the entire experience as a fully functional front-end application using HTML, CSS, and JavaScript, combining recovery tracking with engaging progression mechanics into one cohesive experience. Most of all, I’m proud of creating something that encourages people to take care of themselves through positive reinforcement rather than guilt or pressure. What should people know so they can test your project? To test Recovery Quest, simply explore the app by entering information related to your sleep, nutrition, and exercise habits. The system will evaluate your recovery state and provide feedback based on the choices you make. One important thing to note is that this version does not include a backend. If you log out, your data will be lost. Despite this limitation, the complete recovery experience can still be explored, allowing users to understand the core idea behind Recovery Quest: turning the journey toward better well-being into an adventure worth returning to.", "repo": "https://github.com/medayedi123/Recvoery-Quest", "demo": "https://recoveryquest.netlify.app/"}]...
|
[{"post_id": 10982, "ts": "202 [{"post_id": 10982, "ts": "2026-06-18T00:24:36Z", "hours": 2.0, "text": "Pat I ch Notes: The “I Fixed That Annoying Stuff” UpdateHey everyone! I just rolled out a new update based on the feedback you gave me. I tackled the biggest pain points today:Security Upgrade: No more hardcoded keys! Quality of Life: Training Tab: Lookin’ cleaner and more organized. Nav Hover: Fixed that weird hover glitch that followed you between tabs.Check it out and let me know if you find anything else."}, {"post_id": 9035, "ts": "2026-06-15T02:21:35Z", "hours": 1.0, "text": "Recovery Quest — Devlog #1: the night this started making sense Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up. The thought that wouldn’t leave me alone I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI? In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time. That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan. The first version was straight up homework What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter. Nothing different from the five other apps I’d already downloaded and quit on. Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night. The dumb little rename that fixed everything I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words. But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me. That tiny change became the seed for everything else. Once that clicked, I couldn’t stop After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat. None of it was planned, it just kept clicking into place. I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about. And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?” The feature that hit harder than expected Memory Map started as a throwaway idea — one photo per day on a timeline. But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it. Claude was in the room for basically all of this I didn’t build this alone. That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?” It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled. I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of. Why I kept going Every time I added something, I’d get that “wait… this is actually a system now” feeling. Rare enough that I kept chasing it. Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics. Hard to go back once you see it that way. Devlog #1, done. More soon."}, {"post_id": 8078, "ts": "2026-06-13T14:18:24Z", "hours": 10.0, "text": "Recovery Quest — Devlog #1: the night this started making sense Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up. The thought that wouldn’t leave me alone I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI? In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time. That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan. The first version was straight up homework What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter. Nothing different from the five other apps I’d already downloaded and quit on. Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night. The dumb little rename that fixed everything I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words. But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me. That tiny change became the seed for everything else. Once that clicked, I couldn’t stop After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat. None of it was planned, it just kept clicking into place. I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about. And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?” The feature that hit harder than expected Memory Map started as a throwaway idea — one photo per day on a timeline. But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it. Claude was in the room for basically all of this I didn’t build this alone. That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?” It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled. I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of. Why I kept going Every time I added something, I’d get that “wait… this is actually a system now” feeling. Rare enough that I kept chasing it. Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics. Hard to go back once you see it that way. Devlog #1, done. More soon."}]...
|
Title: Frictionless by @Mohamed_Ayadi | Stardance
Title: Frictionless by @Mohamed_Ayadi | Stardance
Devlogs:
Recovery Quest — Devlog #1: the night this started making sense Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up. The thought that wouldn’t leave me alone I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI? In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time. That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan. The first version was straight up homework What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter. Nothing different from the five other apps I’d already downloaded and quit on. Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night. The dumb little rename that fixed everything I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words. But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me. That tiny change became the seed for everything else. Once that clicked, I couldn’t stop After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat. None of it was planned, it just kept clicking into place. I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about. And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?” The feature that hit harder than expected Memory Map started as a throwaway idea — one photo per day on a timeline. But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it. Claude was in the room for basically all of this I didn’t build this alone. That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?” It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled. I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of. Why I kept going Every time I added something, I’d get that “wait… this is actually a system now” feeling. Rare enough that I kept chasing it. Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics. Hard to go back once you see it that way. Devlog #1, done. More soon.
Recovery Quest — Devlog #1: the night this started making sense Before Recovery Quest was Recovery Quest, it was just a mess on my screen at 1am. Idk how else to put it. Let me back up. The thought that wouldn’t leave me alone I was lying in bed, half scrolling, half thinking about nothing, when this question hit me: why does real life not have a UI? In games I always know exactly where I stand — health bar, stamina, XP, buffs, debuffs. In real life? Nothing. You wake up and wonder “am I tired or just overthinking it” with no number to check. You’re just guessing your own state all the time. That bugged me more than it should’ve. So I got up, opened my editor, and started typing with zero plan. The first version was straight up homework What I had after that session was, with love, extremely boring: a sleep input, a workout log, a nutrition counter. Nothing different from the five other apps I’d already downloaded and quit on. Next day I looked at it and realized I’d just rebuilt what I was trying to escape. Cool. Great use of a night. The dumb little rename that fixed everything I changed “sleep hours” to “recovery impact.” I changed “workout logged” to “training XP gained.” Same data, same numbers, just different words. But seeing “+40 training XP” instead of “workout logged” did something weird. It stopped feeling like filling a form and started feeling like leveling up a character. Who is also me. That tiny change became the seed for everything else. Once that clicked, I couldn’t stop After that night I started designing systems for my own life without meaning to. The dashboard became home base. Streaks became a combo system. Recovery score became a condition stat. None of it was planned, it just kept clicking into place. I kept things simple: vanilla HTML, CSS, JS, no backend, everything in local storage. I didn’t want infrastructure slowing down an idea I wasn’t even sure about. And I didn’t want another fitness tracker. There are too many, and most feel identical after week two. I wanted something else — not “what did you do today,” but “what happens if you keep doing this?” The feature that hit harder than expected Memory Map started as a throwaway idea — one photo per day on a timeline. But scrolling back through it later actually hit me. You can watch yourself change, not as stats, but as a person. I went back two weeks once and just stared at it. Claude was in the room for basically all of this I didn’t build this alone. That night I had a feeling and no idea how to turn it into code. So I talked it through with Claude like a senior dev sitting next to me at 1am asking, “okay, but how would this work?” It helped me figure out recovery scoring, XP scaling, and why my first streak logic kept breaking. Stuff I’d been stuck on just got untangled. I still wrote the code and made every decision about what this was. But that back-and-forth made me willing to try things I’d normally overthink out of. Why I kept going Every time I added something, I’d get that “wait… this is actually a system now” feeling. Rare enough that I kept chasing it. Recovery Quest was still rough and missing most of what it has now, but it already changed how I think about habits — not as a checklist, but as mechanics affecting other mechanics. Hard to go back once you see it that way. Devlog #1, done. More soon.
Pat I ch Notes: The “I Fixed That Annoying Stuff” UpdateHey everyone! I just rolled out a new update based on the feedback you gave me. I tackled the biggest pain points today:Security Upgrade: No more hardcoded keys! Quality of Life: Training Tab: Lookin’ cleaner and more organized. Nav Hover: Fixed that weird hover glitch that followed you between tabs.Check it out and let me know if you find anything else.
Ships:
What did you make? I built Recovery Quest, a web application that transforms recovery and healthy habits into an RPG-style experience. The idea started with a simple observation: taking care of ourselves often feels invisible. You sleep well, eat better, stay active, and make healthier choices, yet it’s hard to see the impact of those small decisions from day to day. Without visible progress, motivation fades. Recovery Quest changes that. Users log information related to their sleep, nutrition, and exercise, and the system evaluates their overall recovery state. Instead of just displaying numbers, the app presents meaningful feedback through game-inspired progression systems. Healthy choices contribute to a sense of growth, turning recovery from an abstract concept into a journey users can actively follow. The goal is simple: make taking care of yourself feel rewarding instead of repetitive. What was challenging? The biggest challenge was designing a system that felt encouraging without oversimplifying recovery. Recovery isn’t determined by a single factor. Sleep, nutrition, and physical activity all influence how someone feels, and I had to think carefully about how these elements should work together to generate useful feedback. Another challenge was balancing the RPG elements. I didn’t want Recovery Quest to become just another game with health-themed decorations. The progression systems had to support the main purpose of the app: helping users understand and improve their recovery habits. Finding that balance between engagement and meaningful feedback required a lot of experimentation and refinement. What are you proud of? I’m proud that Recovery Quest makes something invisible feel visible. Recovery is difficult to measure in everyday life. Most people don’t notice the cumulative effect of sleeping better, eating more consistently, or exercising regularly until weeks later. Recovery Quest highlights those small victories. Users can see how their habits influence their recovery state and receive feedback that encourages them to continue building healthier routines. I’m also proud that I built the entire experience as a fully functional front-end application using HTML, CSS, and JavaScript, combining recovery tracking with engaging progression mechanics into one cohesive experience. Most of all, I’m proud of creating something that encourages people to take care of themselves through positive reinforcement rather than guilt or pressure. What should people know so they can test your project? To test Recovery Quest, simply explore the app by entering information related to your sleep, nutrition, and exercise habits. The system will evaluate your recovery state and provide feedback based on the choices you make. One important thing to note is that this version does not include a backend. If you log out, your data will be lost. Despite this limitation, the complete recovery experience can still be explored, allowing users to understand the core idea behind Recovery Quest: turning the journey toward better well-being into an adventure worth returning to....
|
1793775292.3418562
|
1794639292.3418562
|
|
24530
|
Scientific Calculator by @naman0410 | Stardance
|
naman0410
|
2
|
3.0
|
5
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-04T17:14:58Z", "hours": 1.0, "multiplier": 1.69, "payout": 2, "blessing": "neutral", "text": "I built this Advanced Scientific Calculator to go beyond the basic calculator you find on most websites. Along with standard arithmetic operations, it includes a wide range of scientific functions, memory operations, calculation history, theme switching, and a live currency converter.", "repo": "https://github.com/modinaman099/Scientific-Calculator-", "demo": "https://thunderous-kheer-a7432c.netlify.app/"}, {"ship_num": 2, "ts": "2026-06-23T22:24:06Z", "hours": 2.0, "multiplier": 1.19, "payout": 3, "blessing": "neutral", "text": "I have designed a scientific calculator with all the necessary functions . It has an option to switch between scientific (advnaced) calculator and normal calculator . It can change themes . It also has a history page that can store calculations and you on your own can clear it to .", "repo": "https://github.com/modinaman099/Scientific-Calculator-", "demo": "https://thunderous-kheer-a7432c.netlify.app/"}]...
|
[{"post_id": 18191, "ts": "202 [{"post_id": 18191, "ts": "2026-06-29T08:02:26Z", "hours": 0.0, "text": "I have now added a currency converter to my calculator to give the calculator a bit of my touch . It also tells the current rate of each currency as compared to Indian rupees . I have reworked the css , java part of the code . I have also added a few colours to the calculator so that it doesnt looks dull and colourless ."}, {"post_id": 14659, "ts": "2026-06-23T21:01:16Z", "hours": 0.0, "text": "I have added all the scientific values and working on the UI Interface of the calculator that how will its functions appear"}, {"post_id": 14593, "ts": "2026-06-23T19:15:19Z", "hours": 1.0, "text": "i have added the scientific values that are to be added in the calculator"}, {"post_id": 14538, "ts": "2026-06-23T18:00:17Z", "hours": 0.0, "text": "im working on a scientific calculator with all the functions in a proper calculator"}]...
|
Title: Scientific Calculator by @naman0410 | Stard Title: Scientific Calculator by @naman0410 | Stardance
Devlogs:
im working on a scientific calculator with all the functions in a proper calculator
i have added the scientific values that are to be added in the calculator
I have added all the scientific values and working on the UI Interface of the calculator that how will its functions appear
I have now added a currency converter to my calculator to give the calculator a bit of my touch . It also tells the current rate of each currency as compared to Indian rupees . I have reworked the css , java part of the code . I have also added a few colours to the calculator so that it doesnt looks dull and colourless .
Ships:
I have designed a scientific calculator with all the necessary functions . It has an option to switch between scientific (advnaced) calculator and normal calculator . It can change themes . It also has a history page that can store calculations and you on your own can clear it to .
I built this Advanced Scientific Calculator to go beyond the basic calculator you find on most websites. Along with standard arithmetic operations, it includes a wide range of scientific functions, memory operations, calculation history, theme switching, and a live currency converter....
|
1793775291.4240468
|
1794639291.4240468
|
|
9340
|
Untitled project by @raj_raunit005 | Stardance
|
raj_raunit005
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @raj_raunit005 | Starda Title: Untitled project by @raj_raunit005 | Stardance...
|
1793775290.4892893
|
1794380090.4892893
|
|
25209
|
Partner Compatibility Evaluator by @naman0410 | St Partner Compatibility Evaluator by @naman0410 | Stardance...
|
naman0410
|
2
|
7.0
|
23
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-05T01:36:42Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "This project is a fun Love Compatibility Calculator that estimates how compatible two people are by combining different factors instead of relying on a single random score. It considers multiple aspects to generate a result that feels more engaging and personalized. While building it, one of the biggest challenges was deciding how to balance different calculations so that the results remained interesting without feeling completely unrealistic. I also spent time improving the user interface, making it simpler to use, and updating the songs and preferences based on user feedback to create a better overall experience. Another challenge was ensuring that all the calculations worked together smoothly and produced consistent results. The goal is for people to use this project as a light-hearted and entertaining experience rather than a serious prediction of relationships. I hope users enjoy comparing results with friends, exploring different matches, and having fun while interacting with the application.", "repo": "https://github.com/modinaman099/Love-compatibility-Calculator-", "demo": "https://agent-6a3d0091dfe7cb239d1e0--dapper-genie-1ea83f.netlify.app/"}, {"ship_num": 2, "ts": "2026-06-25T16:46:04Z", "hours": 5.0, "multiplier": 4.73, "payout": 23, "blessing": "neutral", "text": "First of all, this project is not only for you and your girlfriend, but also you and your bros . If you don’t have a girlfriend, you feel me. Now let’s talk about work, I have made this calculator based on the theory that people with same taste, personality and interest tend to have good time together. Through this project, you can analyze with whom do you suit the best, because this includes songs, real-life experiences and food. Aspects like date of birth and difference between the ages of the people also matters in this calculator because this defines the gap of generations that can create problems in the relationship. I hope you like my work and use it with your bros (or girlfriend, if you have one 😜)", "repo": "https://github.com/modinaman099/Love-compatibility-Calculator-", "demo": "https://agent-6a3d0091dfe7cb239d1e0--dapper-genie-1ea83f.netlify.app/"}]...
|
[{"post_id": 41086, "ts": "202 [{"post_id": 41086, "ts": "2026-08-05T01:33:52Z", "hours": 2.0, "text": "This time, I focused on improving the overall user experience based on the feedback I received. I updated the UI to make it cleaner, more intuitive, and visually appealing. I also changed the song preferences to include tracks that are more popular and recognizable to people around the world, making the project feel more inclusive. These changes were made to ensure the application is easier to use and better suited for a global audience."}, {"post_id": 15734, "ts": "2026-06-25T16:31:02Z", "hours": 3.0, "text": "I just have to make some changes in the UI of the website . Also i have to clean up my code from unwanted comments"}, {"post_id": 15567, "ts": "2026-06-25T09:47:30Z", "hours": 1.0, "text": "Most the things to be asked from the both are inputed . The UI design and debugging is left"}, {"post_id": 15235, "ts": "2026-06-24T18:56:03Z", "hours": 0.0, "text": "I have decided the factors that will be taken for the relationship compatibility predictor"}]...
|
Title: Partner Compatibility Evaluator by @naman04 Title: Partner Compatibility Evaluator by @naman0410 | Stardance
Devlogs:
I have decided the factors that will be taken for the relationship compatibility predictor
Most the things to be asked from the both are inputed . The UI design and debugging is left
I just have to make some changes in the UI of the website . Also i have to clean up my code from unwanted comments
This time, I focused on improving the overall user experience based on the feedback I received. I updated the UI to make it cleaner, more intuitive, and visually appealing. I also changed the song preferences to include tracks that are more popular and recognizable to people around the world, making the project feel more inclusive. These changes were made to ensure the application is easier to use and better suited for a global audience.
Ships:
First of all, this project is not only for you and your girlfriend, but also you and your bros . If you don’t have a girlfriend, you feel me. Now let’s talk about work, I have made this calculator based on the theory that people with same taste, personality and interest tend to have good time together. Through this project, you can analyze with whom do you suit the best, because this includes songs, real-life experiences and food. Aspects like date of birth and difference between the ages of the people also matters in this calculator because this defines the gap of generations that can create problems in the relationship. I hope you like my work and use it with your bros (or girlfriend, if you have one 😜)
This project is a fun Love Compatibility Calculator that estimates how compatible two people are by combining different factors instead of relying on a single random score. It considers multiple aspects to generate a result that feels more engaging and personalized. While building it, one of the biggest challenges was deciding how to balance different calculations so that the results remained interesting without feeling completely unrealistic. I also spent time improving the user interface, making it simpler to use, and updating the songs and preferences based on user feedback to create a better overall experience. Another challenge was ensuring that all the calculations worked together smoothly and produced consistent results. The goal is for people to use this project as a light-hearted and entertaining experience rather than a serious prediction of relationships. I hope users enjoy comparing results with friends, exploring different matches, and having fun while interacting with the application....
|
1793775287.2856026
|
1794639287.2856026
|
|
25082
|
hyprpwr by @jacobjuneau | Stardance
|
jacobjuneau
|
1
|
1.0
|
1
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-24T09:25:56Z", "hours": 1.0, "multiplier": 1.1, "payout": 1, "blessing": "neutral", "text": "HyprPwr A minimal power/session menu for Hyprland written in Python and GTK3. HyprPwr provides a small keyboard-friendly popup for common session management actions: Logout Shutdown Restart Suspend Features Lightweight GTK3 interface Keyboard navigation (↑/↓, j/k) Mouse support Clean floating window design Designed specifically for Hyprland No external menu launcher required", "repo": "https://github.com/jacobjuneau6/hyprpwr", "demo": "https://github.com/jacobjuneau6/hyprpwr/releases/tag/V1"}]...
|
[{"post_id": 14965, "ts": "202 [{"post_id": 14965, "ts": "2026-06-24T09:24:48Z", "hours": 0.6494, "text": "This was just kind of a quick little project that i am doing because i am tired of having to open my terminal to perform power actions."}]...
|
Title: hyprpwr by @jacobjuneau | Stardance
Devlog Title: hyprpwr by @jacobjuneau | Stardance
Devlogs:
This was just kind of a quick little project that i am doing because i am tired of having to open my terminal to perform power actions.
Ships:
HyprPwr A minimal power/session menu for Hyprland written in Python and GTK3. HyprPwr provides a small keyboard-friendly popup for common session management actions: Logout Shutdown Restart Suspend Features Lightweight GTK3 interface Keyboard navigation (↑/↓, j/k) Mouse support Clean floating window design Designed specifically for Hyprland No external menu launcher required...
|
1793775284.4168906
|
1794639284.4168906
|
|
17271
|
VinylBot by @F3rro_32 | Stardance
|
F3rro_32
|
2
|
20.12
|
98
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-23T11:44:07Z", "hours": 7.0, "multiplier": 14.66, "payout": 98, "blessing": "neutral", "text": "This project contains three microprojects, all related. There’s the slack_bot, already shipped for the mission. There’ s the ds_bot, improved from it’s first version in flavortown. And there’s a newborn, a website, containing everything necessary for the bot, with also docs, for hosting the bot locally. For making the design of the website, since I’m not that great with graphics, I used v0, which generated mockups for me. That’s why the website Ui seems so AI.", "repo": "https://github.com/AlessioFerrari8/VinylBot", "demo": "https://vinylbot.alessio.hackclub.app/"}, {"ship_num": 2, "ts": "2026-07-22T10:28:10Z", "hours": 12.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "This ship is just for the slack bot. For now ignore the rest, it will come later.", "repo": "https://github.com/AlessioFerrari8/VinylBot", "demo": "https://vinylbot.alessio.hackclub.app/"}]...
|
[{"post_id": 37595, "ts": "202 [{"post_id": 37595, "ts": "2026-07-30T13:05:14Z", "hours": 1.1175, "text": "Just fixed a little bug, the same songs kept coming back whenever you played the same artist twice. That’s because the artist track pool was too small, so every game used it up entirely. I fixed this and also added a nice thing, suggested by @stef . I improved the hints, now it’s easier to guess a song after hints 2 and 3. I hope you enjoy playing"}, {"post_id": 33430, "ts": "2026-07-23T11:23:02Z", "hours": 6.7158, "text": "Spent today hardening VinylBot for production: fixed a crash bug where an unhandled ffmpeg/stream error in the audio player could take down the entire bot for every server at once, added global uncaughtException/unhandledRejection handlers to both bots, fixed a race condition in the Slack round timer, and cleaned up leaked temp mp3 files on failed downloads. Also dockerized the Angular website (nginx + multi-stage build) and got all three services (Discord bot, Slack bot, website) live on their own subdomains behind the VPS firewall. For the problem of the streaming on server or vps I decided to add two methods for gathering audio mp3s. The first time it will try with spotify, searching for the preview_url. After that it will try deezer and Itunes, that represents a valid alternative."}, {"post_id": 31798, "ts": "2026-07-20T14:02:13Z", "hours": 1.9744, "text": "Hey guys, today I’m working on fixing the ds bot. First of all I had to review the method of streaming the song. I was first using yt-dlp for everything, but I noted that putting it on a server was making it not working anymore. I discovered that is because yt blocks certain ips and certain requests, so this was an impossible choice. The solution was spotify preview, which are basically like 20 seconds of a song. That’s perfect for me, since I don’t have to stream the whole song, but instead just a little part. The approach is this. I created a variable in the env, called DEPLOY_ENV. This specifies if we’re running the bot locally, or on a server or vps. If the variable is vps, first the bot is gonna try finding the song on spotify. If it’s not present, it’s gonna search for local files, as alternative. If the variable is local, the first alternative remains spotify, but as a second there’s also yt-dlp, since locally it works fine. I also adjusted the cards of some commands, as you can see from the screens, along with testing out the bot. I still have some more work to do, but I think soon the ds bot will be ready."}, {"post_id": 31299, "ts": "2026-07-19T16:19:19Z", "hours": 1.9647, "text": "As you can see, I’m currently working on fixing some minor details, like improving the card. This card is displayed whenever you use the commands play, nowplaying, pause, skip, previous. In this card you can see the song, the album it comes from, who requested to see the card and also the timing. Additionaly there are buttons for pausing, skipping and level up or down the button by 10 units. I also discovered something I didn’t know. Recently you can use your own emojis, so I generated this one with chatgpt and used them for the commands, as you can see in the card. Really useful"}, {"post_id": 30709, "ts": "2026-07-18T14:46:33Z", "hours": 4.5936, "text": "Hey guys, so I decided to improve this project. I created another repo, containing both the bot in slack, made in this “session”, and the bot made for discord, made in Flavortown. Along with those two projects, I added a website. So now the repo contains the two bots, and the website. I just built the website, it’s a simple landing page. For generating mockups for the design I used v0 by vercel, which is really useful for people like me, who aren’t able to produce anything graceful without a designer. So, as I was saying, the website it’s just a simple landing page, containing infos about the bots, allowing to download the bots and more. I also added two routes /status and /docs. The names explain the function. The first oen contains the status of each bots. The second one contains well-written docs, very useful for people who want to host the bot locally."}, {"post_id": 9194, "ts": "2026-06-15T13:13:08Z", "hours": 1.8275, "text": "Adapted everything to slack, now it’s quite working. The only problem is that I have still to fix the gain of the music resource, but it’s processing in my mind right now. /vinylbot-stop"}, {"post_id": 8689, "ts": "2026-06-14T13:10:00Z", "hours": 1.5108, "text": "I’m currently working on VinylBot, a Slack bot with two main features. Imagine you’re chatting with friends on Slack: with VinylBot, you can manage your music directly from Slack without having to open Spotify every time. The main feature, though, is the Vinyl Game, a music guessing game where players have to identify a song based on just a few seconds of playback. I’ve already built a Discord version of the project, which is available on my GitHub. However, bringing it to Slack is becoming a challenge, since a lot of the logic has to be reworked due to the differences between Discord and Slack and the way they handle interactions. I hope you’ll like it."}]...
|
Title: VinylBot by @F3rro_32 | Stardance
Devlogs: Title: VinylBot by @F3rro_32 | Stardance
Devlogs:
I’m currently working on VinylBot, a Slack bot with two main features. Imagine you’re chatting with friends on Slack: with VinylBot, you can manage your music directly from Slack without having to open Spotify every time. The main feature, though, is the Vinyl Game, a music guessing game where players have to identify a song based on just a few seconds of playback. I’ve already built a Discord version of the project, which is available on my GitHub. However, bringing it to Slack is becoming a challenge, since a lot of the logic has to be reworked due to the differences between Discord and Slack and the way they handle interactions. I hope you’ll like it.
Adapted everything to slack, now it’s quite working. The only problem is that I have still to fix the gain of the music resource, but it’s processing in my mind right now. /vinylbot-stop
Hey guys, so I decided to improve this project. I created another repo, containing both the bot in slack, made in this “session”, and the bot made for discord, made in Flavortown. Along with those two projects, I added a website. So now the repo contains the two bots, and the website. I just built the website, it’s a simple landing page. For generating mockups for the design I used v0 by vercel, which is really useful for people like me, who aren’t able to produce anything graceful without a designer. So, as I was saying, the website it’s just a simple landing page, containing infos about the bots, allowing to download the bots and more. I also added two routes /status and /docs. The names explain the function. The first oen contains the status of each bots. The second one contains well-written docs, very useful for people who want to host the bot locally.
As you can see, I’m currently working on fixing some minor details, like improving the card. This card is displayed whenever you use the commands play, nowplaying, pause, skip, previous. In this card you can see the song, the album it comes from, who requested to see the card and also the timing. Additionaly there are buttons for pausing, skipping and level up or down the button by 10 units. I also discovered something I didn’t know. Recently you can use your own emojis, so I generated this one with chatgpt and used them for the commands, as you can see in the card. Really useful
Hey guys, today I’m working on fixing the ds bot. First of all I had to review the method of streaming the song. I was first using yt-dlp for everything, but I noted that putting it on a server was making it not working anymore. I discovered that is because yt blocks certain ips and certain requests, so this was an impossible choice. The solution was spotify preview, which are basically like 20 seconds of a song. That’s perfect for me, since I don’t have to stream the whole song, but instead just a little part. The approach is this. I created a variable in the env, called DEPLOY_ENV. This specifies if we’re running the bot locally, or on a server or vps. If the variable is vps, first the bot is gonna try finding the song on spotify. If it’s not present, it’s gonna search for local files, as alternative. If the variable is local, the first alternative remains spotify, but as a second there’s also yt-dlp, since locally it works fine. I also adjusted the cards of some commands, as you can see from the screens, along with testing out the bot. I still have some more work to do, but I think soon the ds bot will be ready.
Spent today hardening VinylBot for production: fixed a crash bug where an unhandled ffmpeg/stream error in the audio player could take down the entire bot for every server at once, added global uncaughtException/unhandledRejection handlers to both bots, fixed a race condition in the Slack round timer, and cleaned up leaked temp mp3 files on failed downloads. Also dockerized the Angular website (nginx + multi-stage build) and got all three services (Discord bot, Slack bot, website) live on their own subdomains behind the VPS firewall. For the problem of the streaming on server or vps I decided to add two methods for gathering audio mp3s. The first time it will try with spotify, searching for the preview_url. After that it will try deezer and Itunes, that represents a valid alternative.
Just fixed a little bug, the same songs kept coming back whenever you played the same artist twice. That’s because the artist track pool was too small, so every game used it up entirely. I fixed this and also added a nice thing, suggested by @stef . I improved the hints, now it’s easier to guess a song after hints 2 and 3. I hope you enjoy playing
Ships:
This ship is just for the slack bot. For now ignore the rest, it will come later.
This project contains three microprojects, all related. There’s the slack_bot, already shipped for the mission. There’ s the ds_bot, improved from it’s first version in flavortown. And there’s a newborn, a website, containing everything necessary for the bot, with also docs, for hosting the bot locally. For making the design of the website, since I’m not that great with graphics, I used v0, which generated mockups for me. That’s why the website Ui seems so AI....
|
1793775280.956418
|
1793861680.956418
|
|
26064
|
To do list by @y4r4 | Stardance
|
y4r4
|
1
|
2.0
|
3
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-26T11:46:17Z", "hours": 2.0, "multiplier": 1.38, "payout": 3, "blessing": "neutral", "text": "If you need to write down your tasks in order to achieve them this website is for you! This is a ( beautiful ) to do list website where you can write and check off your tasks. The most challenging part of this project was probably the java script since i’m not that familiar with it.", "repo": "https://github.com/y4r4a/todo", "demo": "https://y4r4a.github.io/todo/"}]...
|
[{"post_id": 16002, "ts": "202 [{"post_id": 16002, "ts": "2026-06-26T00:01:08Z", "hours": 2.0, "text": "i just finished coding this to do list website!"}]...
|
Title: To do list by @y4r4 | Stardance
Devlogs:
i Title: To do list by @y4r4 | Stardance
Devlogs:
i just finished coding this to do list website!
Ships:
If you need to write down your tasks in order to achieve them this website is for you! This is a ( beautiful ) to do list website where you can write and check off your tasks. The most challenging part of this project was probably the java script since i’m not that familiar with it....
|
1793775278.2712464
|
1794639278.2712464
|
|
1809
|
DAMNN BOT ! by @aditya_msra | Stardance
|
aditya_msra
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: DAMNN BOT ! by @aditya_msra | Stardance
|
1793775276.1466491
|
1794380076.1466491
|
|
35239
|
CORES Runtime by @ravi10 | Stardance
|
ravi10
|
2
|
61.0
|
58
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-31T19:08:41Z", "hours": 33.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "CORES Runtime is an open-source cognitive runtime for autonomous robots. Instead of controlling robot hardware directly, it manages the software systems that sit between perception, planning, scheduling, memory, and execution. Its goal is to help robots decide what to run, when to run it, and how to manage limited compute and energy while remaining deterministic and predictable. This ship focuses on a major redesign of the memory subsystem. I replaced the previous learning architecture with a new memory pipeline built around Episodic Memory, Semantic Memory, and a Logger that compresses experiences into long-term knowledge. During development, I discovered and fixed a consolidation bug through the demo itself, added regression tests, benchmarked the full compression pipeline, and documented a known scaling limitation for future optimization.", "repo": "https://github.com/Cores-Runtime/cores", "demo": "https://cores-rust.vercel.app/"}, {"ship_num": 2, "ts": "2026-07-16T09:43:26Z", "hours": 8.0, "multiplier": 7.72, "payout": 58, "blessing": "neutral", "text": "CORES is a research project exploring how autonomous robots can schedule cognition instead of simply executing tasks. This update introduces the first public version of the CORES experience. I built and deployed a homepage that explains the runtime architecture, scheduling, benchmark overview, and cognitive module system. A major focus was making a complex robotics runtime understandable through clean visual design rather than long technical documentation. The next milestone is an interactive runtime simulator where visitors will be able to inject hazards, change mission conditions, and watch the scheduler reprioritize cognitive modules in real time. Exact visualizations and benchmark charts will be added. I’d love feedback on: Is the core idea easy to understand? Does the homepage clearly communicate the purpose of CORES? What sections are confusing or missing?", "repo": "https://github.com/Cores-Runtime/cores", "demo": "https://cores-rust.vercel.app/"}]...
|
[{"post_id": 40760, "ts": "202 [{"post_id": 40760, "ts": "2026-08-04T14:30:40Z", "hours": 10.0, "text": "Devlog #10 Meet the Mission Manager “What should the robot work on right now?” Planning already knows how to achieve a goal, but it doesn’t decide which goal is the most important. The Mission Manager sits one level above Planning, keeps track of every mission, chooses the active goal, and hands only that goal to the planner. Spent most of the day building the Mission Manager. The idea sounds simple: a mission is a list of goals, the manager picks the active one, hands it to Planning, and waits for the result. The details were anything but simple. I started with the mission lifecycle. Every mission begins in NEW , becomes READY , then ACTIVE , and eventually reaches a terminal state: COMPLETED , FAILED , or CANCELLED . A mission can also be PAUSED and resumed later. The transition rules are strict. You can’t jump from CANCELLED back to ACTIVE , and you can’t skip directly from NEW to COMPLETED . Every transition has to make sense. I spent much longer than I expected getting the state diagram and all the transitions right. Preemption was probably the most interesting part. When a higher-priority mission arrives, the current one moves back to READY , not PAUSED . That distinction took a while to figure out. PAUSED means someone intentionally stopped the mission. Preemption means the system decided something more important needs attention first. Different reasons, different states. Goals also execute one at a time. A goal can depend on another goal, so a task like Drop Package won’t begin until Pick Package has finished. Goal completion works in two independent ways. You can either call complete_goal() directly, or use a constraint evaluator that checks the robot’s state automatically. Neither depends on the other, and a goal never completes simply because it has no constraints. That felt like the safest design. A bug the dashboard exposed Near the end, I ran into a strange bug. As soon as a mission finished, the manager immediately wrote \"idle\" into the robot state, clearing the mission ID and progress. If you were watching the dashboard, the mission simply disappeared the moment it completed. The fix was straightforward: keep the final mission state visible until another mission becomes active. Now the homepage trace finishes at 100% Complete instead of dropping back to idle immediately. It was a small issue, but it made the runtime feel much more polished. Integration The cleanest part of this phase was the integration. Nothing else needed to change. The Scheduler still schedules. The Planner still plans. The Mission Manager simply runs earlier in the runtime cycle, selects the active goal, and passes it to Planning. Even the original way of giving a mission directly to the Runtime still works, so existing code remains compatible. Some Cleanups The rest of the session went into polishing the project. Updated documentation and runtime diagrams Refreshed test and strategy counts Replaced the remaining banned terminology Renamed the HTN primitive class across seven files for consistency Fixed benchmark test collection by adding import fallbacks for script execution Nothing particularly exciting, but it leaves the project in a much healthier state. I think this phase is finally complete."}, {"post_id": 39637, "ts": "2026-08-02T19:20:21Z", "hours": 10.0, "text": "Devlog #9 Meet the Planning Module The Planning Module answers one simple question: “What should we do next?” It looks at the goal and the current state, proposes candidate plans, and picks the best one. The module has one interface and five planners. You hand it a mission, which is a collection of goals. Each goal is something the robot wants to be true. Every planner produces candidate plans with a confidence, estimated cost, duration, and utility score. The module returns all candidates and the one it selects as the best. The five planners are: GoalPlanner searches forward using action pre-conditions and effects. HTNPlanner breaks high-level tasks into smaller actions using authored methods. UtilityPlanner scores candidates and picks the highest. ReactivePlanner reacts immediately to simple conditions. BehaviorTreePlanner executes authored behavior trees. All of them implement the same PlannerStrategy interface, so they can be swapped without changing the rest of the runtime. The planner learned to adapt its own plans Before today, whenever something changed during a mission, the planner threw away the entire plan and started again. Now it walks through the existing plan step by step. If the beginning of the plan is still valid, it keeps it. As soon as it reaches a step that can no longer be completed, it rebuilds only the remaining part. This means the robot no longer repeats work it has already finished. Both the Goal Planner and HTN Planner now support this. Every repaired plan also records where the original plan became invalid. The Runtime handles this automatically. If the environment changes, it first tries to update the existing plan. Only if that fails does it generate a completely new one. The planner learned to notice change The next challenge was deciding when to update a plan. The solution was a planning snapshot: a small summary of the robot and world containing only the information planning actually cares about. Objects, flags, payloads, and sensor-health keys are sorted. Battery is grouped into critical , low , medium , or high instead of using the exact percentage. Temperatures and positions are rounded, while noisy values like timestamps and raw pose are ignored. This keeps the snapshot deterministic, so identical worlds always produce identical snapshots and unnecessary replanning is avoided. The planner learned from experience The second big change was teaching the planner to use previous experiences. Before today, it only looked at the current situation. Now it asks Memory for a summary of previous successes and failures before making a decision. A new wrapper called MemoryAwarePlanner works with any existing planner. It lets the original planner create a plan, then adjusts the choices based on previous outcomes. Plans that failed before become less attractive, while successful ones get a small boost. The selected plan is stored back into Memory so future missions can learn from it as well. If there is no previous experience, the planner behaves exactly as it did before. The demo ties everything together. First, Door A becomes blocked, so the planner updates the existing plan and switches to Door B instead of starting over. Then, on the next run, Memory remembers that Door A failed twice while Door B succeeded once, so the planner chooses Door B from the beginning."}, {"post_id": 38154, "ts": "2026-07-31T12:17:53Z", "hours": 11.0, "text": "Devlog #8 The demo found a bug before I did. I had that type of day where, you think every feature is working correctly and when you test, you find out its not. The standalone Learning subsystem was deleted a while back. In its place I added the Logger, which uses a compression algorithm living inside Memory. SPSCA, the Semantic Pointer State Compression Algorithm, moved out of the memory strategies and into the Logger where it belonged. The new module: logger it only had one job and that was to summarize long memories and log it and somehow it still failed in demo. 😑 Then demo_memory.py ended with a summary that read: Episodic records: 7 | Semantic narratives: 0 If you watched that demo as an outsider, you would walk away thinking the Logger was a sticker on the box. It looked broken, because it was idle. The records I stored were all too important to archive, but the default trigger needed 50 new records to even consider firing. So I just re-wrote the pipeline and tested it. The bug was just one line Then the demo did something embarrassing. It caught a real bug. The source IDs in the second narrative overlapped with the first. Records that had already been summarized were showing up to be summarized again. Imagine a robot checking the same doorway every patrol because it never recorded that it had already inspected the doorway. The culprit was mark_consolidated checker. It was asked to flip a batch of records to CONSOLIDATED, and it did the polite thing of fetching one record per id. Except every single fetch returned the same record. The top one. So one record got filed, and the other ten stayed on the desk, waiting to be processed forever. A one-line fix and a regression test later, no record is ever re-compressed. Caught the bug by reading my own demo output, which is the cheapest way to find a bug on earth. (≧▽≦) The benchmark that revealed the hidden cost Then I measured the whole pipeline. Not the Logger in isolation, the full journey. Store, archive, trigger, compress, file into semantic memory. The numbers looked fine and then slowly stopped being fine:- 100 records: about 0.66 ms each 1000 records: about 0.83 ms each 5000 records: about 1.77 ms each Every cycle, archiving and consolidation scan the whole store to find what changed. That is a classic hidden O(n^2), the kind that is invisible at demo size and painful at robot lifetime size. It is fine for now. It is written down. It will be fixed before anyone deploys a robot that lives for a year. 😓 The interesting part wasn’t fixing the bug. It was realizing that a good demo isn’t just there to impress people. It’s another test. Unlike unit tests, it exercises the system the way a user would, and today it caught a bug that hundreds of automated tests never did. Sometimes the fastest debugger is simply watching your own software run."}, {"post_id": 36393, "ts": "2026-07-28T13:56:17Z", "hours": 10.0, "text": "Devlog #7 Today’s session was dedicated to a very big architectural refactor in the project. The goal was to simplify the memory and reasoning pipeline by redesigning how memory is represented and consolidated while preserving compatibility with the existing runtime. Session Goals Redesigning the memory architecture Removing old unnecessary learning subsystem Introducing Logger Migrating SPSCA Preserving runtime compatibility Keeping full test suite passing Architecture Design I went back to the basics and reviewed the entire architecture. I wanted to make it cleaner by identifying overlapping responsibilities between Memory and Learning. It was very time consuming as there were too many responsibilities and modules to simplify and distinguish here. This resulted in a new architecture: EpisodicStore SemanticStore Logger Since I believe learning will be taken care of in future updates. Implementation Implemented: Memory redesign Logger subsystem Trigger policies SPSCA migration Runtime integration Memory now internally composes Episodic Memory, Semantic Memory, and Logger while exposing a single interface to the runtime. Refactoring Performed a full project-wide migration: replaced string record types with enums updated runtime integration updated imports removed old unnecessary learning components updated public exports Testing & Validation Refactored the testing suite: New module integration tests SPSCA tests Trigger policy tests Updated memory tests Removed old unnecessary tests Final result: 590 / 590 tests passing Lint clean I was happy that the refactor didn’t break anything! (^///^) Documentation Updated: Memory documentation Benchmarks Demo programs Outcome The runtime now has a significantly cleaner architecture: State Estimation → Memory Episodic Semantic Logger → Planning → Scheduler → Execution This refactor was very important as it redefined the whole runtime(base) on which the whole project was built on. This will help to build future phases, secondly dividing memory types was one of the best decisions."}, {"post_id": 33975, "ts": "2026-07-24T10:58:42Z", "hours": 3.0, "text": "Devlog #6 👋 I just wanted to add a way for robot to effectively store and fetch its memory. I expected this phase to be fairly straightforward. The runtime already had State Estimation, Planning and Scheduling. Memory sounded like another subsystem to plug into the pipeline, expose a few interfaces and move on. It didn’t quite go that way. I started with what seemed like the obvious design: A common memory interface with multiple interchangeable strategies. Instead of committing to a single implementation, I built: FIFO Time Decay Priority Episodic SPSCA behind the same abstraction. I knew I’d want to compare different approaches later, so making them interchangeable from the beginning felt like the right decision. Most of the implementation went smoothly 🔥. Then I reached Sparse Principal Component Analysis (SPSCA). Unlike the other strategies, SPSCA wasn’t just storing records. It was trying to represent them. My first implementation followed the algorithm closely. Every piece of content was recursively encoded using semantic pointer operations before being stored. At the time, I was pretty happy with it. Then I ran the benchmarks. The larger scenarios became painfully slow. Some didn’t even finish. I was upset that this whole work and time for nothing and just ruining the project? :-( At this point, I feel like giving up on this and do the next thing or just implement this in the simplest way possible. I actually started making the next phase idea and then while doing that, suddenly out of nowhere, I got an idea about how to find the exact cause of failure 🥹. So, I just went to see that was my hypothesis was correct about the error. I spent a whole evening looking for small optimizations. Once I did, I found the issue with it!. The encoding stage itself had become the bottleneck. That forced me to see the bigger picture of what’s happening during that stage. Instead of trying to optimize the existing implementation, I redesigned the encoding pipeline completely. Memory content is now serialized into a deterministic representation and converted into fixed-length vectors using SHA-256 before participating in similarity operations. The semantic pointer operations are still implemented, but they’re no longer part of every storage operation. That one decision simplified the whole implementation very much. Watching the benchmarks finally finish without timing out was a huge relief. 😭 With the implementation stable again, I turned my attention to testing. I added benchmarks for insertion, retrieval latency, sustained memory growth and strategy comparisons, along with a much larger test suite covering storage, retrieval, forgetting behaviour, vector operations and runtime integration. By the end of the phase, the runtime could finally retain experiences across execution cycles. But, stopped myself from immediately moving on to the next feature as there were still a few loose ends I wanted to clean up before building anything on top of Memory. Nothing in the runtime actually depends on memory yet. Planning doesn’t query it, scheduling doesn’t use it, and no module learns from previous experience. I considered pushing further, but decided against it. Changing the foundation becomes much harder once other components start depending on it. As a small side quest during this phase, I also redesigned the project homepage. Hopefully it finally looks the way I originally imagined it. For now, memory exists for one reason: to give the runtime a place to store or fetch it in a very efficient way."}, {"post_id": 31622, "ts": "2026-07-20T05:20:32Z", "hours": 4.0, "text": "Devlog #5 I thought it would be an interesting day today, as I was going to add something important that will help a robot perceive and predict the world. Instead, I spent most of my time reading research papers. At first I thought I could just implement a World Model and move on. After reading more robotics papers, I realised everyone seems to solve the problem differently. Some approaches use occupancy grids. Some track objects. Some build semantic maps. Some focus almost entirely on probabilistic state estimation. I couldn’t find a single approach that worked well across every scenario. That changed my view of how I wanted to build this part of CORES. Instead of picking one approach that works only in one scenario, I started implementing multiple approaches instead of one. The plan Implement them. Benchmark them. See where each one performs well. Let the results decide which one should become the default. One thing I realised While doing this, I also realised that calling everything a “World Model” was a bit misleading. The runtime isn’t trying to store the world. It’s trying to estimate what the world currently looks like based on observations. That made “State Estimation” feel like a much better name for the implementation. The architecture didn’t really change. Only the implementation became clearer. It was mostly about changing how I think about this part of the project. I think spending a day reading papers and redesigning things will save me weeks of rewriting later. I’ve mentioned this before, but I think it’s important to build the clearest picture possible of a feature before implementing it. About the papers Just to be clear, the papers and images below are existing robotics research. I’m not claiming them as my own. I’m studying different approaches before deciding how to implement this part of CORES. Progress today Surveyed different robotics approaches Planned multiple State Estimation strategies Started implementing competing approaches Added benchmark framework Wrote more tests Refactored the architecture Renamed the implementation to State Estimation"}, {"post_id": 30532, "ts": "2026-07-18T05:46:20Z", "hours": 3.0, "text": "Devlog #4 Today was a difficult day as i was working on too many things but i tried to simulate what i have implemented till now. It was all about making it easier to understand. Until now I had graphs, benchmark results and logs. They were useful for me, but if someone else looked at them, they probably wouldn’t understand why the runtime made a particular decision. That made me think. If a robot suddenly stops or changes its plan, how do I show why that happened instead of just showing numbers? So today I spent most of my time working on the replay system. Building a mission To test everything, I created a simple Mars mission. The rover starts driving normally. Halfway through the mission a rockslide blocks the path. Instead of continuing, the runtime reacts. The rover stops. Safety takes priority. Navigation calculates another path. Then the mission continues. Watching that happen felt much better than looking at benchmark graphs. For the first time it actually felt like I was watching the runtime make decisions. I was happy at this point that all this work actually getting showed in a sim (┬┬﹏┬┬) Making it easier to understand I also spent time improving the replay itself. The rover now has moving wheels, suspension, antenna, brake lights, warning lights and dust effects. I also added different camera angles to make it easier to follow what is happening. One feature I enjoyed building was the cognition timeline. Instead of showing every module sitting there doing nothing, I can now see when modules become active, when they pause and when another module takes over. That made the scheduler much easier to understand, while replaying a mission. One thing I realised The most difficult part was finding a simple way to show what the runtime was thinking. Trust me it was difficult, putting everything into a presentable demo, Trying to fit weeks of work into a small demo meant deciding what to show and what to hide. I had to remove a lot of unnecessary details while still making it clear how the runtime actually works. I think that’s something I’ll keep improving as the project grows. What’s next Right now the replay still uses temporary modules. The next step is replacing them with actual runtime components like Perception, Planning, Navigation, State Estimation and Safety Monitor. After that I’ll connect the replay directly to the Python runtime so every event comes from the real scheduler instead of prerecorded data. Progress today Built the first replay system Added a Mars mission Added dynamic hazards Added cinematic camera modes Added rover animations Added cognition timeline Improved replay visualisation The replay is still pretty simple, but it finally feels like the project is becoming something people can interact with instead of just reading about. I finally achieved something what i wanted to when i started the project, a simulation that is demoable. It’s still far from finished, but seeing the runtime make decisions inside a simulation feels like a huge milestone for me."}, {"post_id": 29382, "ts": "2026-07-16T09:35:41Z", "hours": 3.0, "text": "Devlog #3 hmm, So when i started the project i thought i would build an actual simulation where i could show everyone how it works, its still far from that. So i focused on doing that, I took a break from working on the runtime itself and started building the website. Until now, everything was happening inside the codebase. The runtime was working, benchmarks were running, and tests were passing, but if someone visited the repository they still wouldn’t understand what CORES actually does. I just wanted it to explain the project. Building the homepage I started building the first version of the website using Next.js. Most of the time today went into trying different layouts and figuring out how to present the project in a simple way. The homepage now has: Hero section Navigation Runtime statistics Benchmark summary cards Cognitive architecture visualization Responsive layout One sentence stayed with me while building the page: The project should focus on making robots think better in emergency situations and have actual knowlege of their resources and their environment. I think it explains the project much better than a long paragraph. Designing to match my thinking After changing the layout a few times, I removed most of the unnecessary elements and kept the design much simpler. I’d rather have a clean page that explains the project than something flashy that distracts from it. Deployment Getting the website online wasn’t completely straightforward. Since the repository contains both the Python runtime and the Next.js frontend, I had to configure Vercel to build only the frontend. A couple of module import issues also showed up during deployment. After fixing those, the website finally deployed successfully. Thinking about the project differently While working on the homepage, I realised something. The website shouldn’t just tell people what CORES is. It should help them understand it. Instead of reading pages of documentation, I want someone to interact with the runtime and see how scheduling decisions change under different situations. That’s probably where I’ll spend most of my time next. Testing I also added around 80 more tests while working on the project. The runtime is getting bigger every day, so I’d rather spend extra time writing tests now than spend hours debugging later. End of the day Today wasn’t about adding another algorithm. It was about making the project easier to understand. The runtime is only useful if people can understand what it’s trying to do, and I think the homepage is a good first step toward that. Progress today Built the first version of the CORES homepage Added runtime overview and benchmark cards Added cognitive architecture visualization Simplified the website design Deployed the frontend on Vercel Fixed deployment and module import issues Added around 80 new tests Tomorrow I’ll start working on the simulator so visitors can interact with the runtime instead of only reading about it."}, {"post_id": 28872, "ts": "2026-07-15T13:19:25Z", "hours": 3.0, "text": "Devlog #2 Welcome to my another devlog!! Today was all about the scheduler. Yesterday I finished a greedy scheduler, but I wasn’t convinced it was the best option. So today I implemented an exact 0/1 Knapsack scheduler expecting it to perform much better. After running benchmarks, it honestly wasn’t what I expected. Most of the time both schedulers produced almost the same schedule. For a while I thought I had implemented something incorrectly, so I kept checking the code and rerunning the benchmarks. Turns out the implementation wasn’t the problem. The greedy scheduler was already finding the optimal solution in most of the scenarios I generated. The only noticeable differences appeared when resources became really limited. That’s where I found something that bothered me. During a simulated sensor failure, the Knapsack scheduler decided to stop localization because it increased the optimization score. From a mathematical point of view, that decision was correct. From a robotics point of view, it was terrible. A robot shouldn’t sacrifice safety just because it saves a little more battery. That’s when I stopped thinking about improving the algorithm itself and started thinking about what I was actually asking it to optimize. Instead of using one objective function, I switched to a lexicographic approach. Now scheduling decisions happen in this order: Safety Mission progress Energy Execution time This means lower priorities can never override higher ones. While changing the scheduler, I also realised I had been treating every module exactly the same. That didn’t make much sense. A battery monitor shouldn’t be treated the same way as an exploration module. So I divided modules into three groups. Mandatory Safety Critical Mission Those groups are now used directly by the scheduler. I also added a module dependency graph so relationships between modules can be represented instead of assuming every module is independent. After finishing the scheduler changes, I spent quite a bit of time expanding the benchmarks. I added more scenarios, an ablation framework, and graphs so I could compare different scheduling policies instead of relying on a few manual examples. The result I cared about the most was the original failure case. The previous scheduler reduced safety coverage during a sensor failure. The new scheduler kept safety at 100%. That was enough to convince me this direction makes more sense. Progress today Compared Greedy and Knapsack scheduling Built benchmark scenarios Implemented Lexicographic Scheduler Added module categories Added module dependency graph Created ablation framework Added benchmark visualizations Wrote research experiment documentation 83 tests passing. Today was a good day, I completed and learned so many things from different algorithms and how each behave differently from other in eveyr situation. And it was fun. Not anything cool yet but it felt like i achieved something here."}, {"post_id": 28595, "ts": "2026-07-14T22:48:05Z", "hours": 1.0, "text": "Devlog #1: Building the Foundation Date: July 15, 2026 Just started the project and it already feels ike theres too much too learn beofre starting. I know it would be hard designing the whole architecture and system and oh god it was! So as I was saying, I started with the most important steps designing the whole system and architecture of the project. The usual stufff!! : Setting up the project The first few commits were just getting the project into a shape where I could actually start building. Initial repository Project structure Cleaning up the directory layout .gitignore Removing unnecessary cache files Till this point I hadn’t really started implementing the actual idea. It was just a setup, that was going to be base of the whole project. Getting modules to communicate The first actual component I worked on was the event system. I didn’t want modules calling each other directly because that would make everything tightly coupled very quickly. Instead, I added an event-based communication layer. At this point it was very simple, but it gave me something to build on. Scheduler and Runtime Once events were working, I moved on to the scheduler. At first I wasn’t sure how much responsibility the scheduler should have. After a few iterations I settled on keeping it responsible only for deciding what runs next. The ExecutionLayer should only execute that plan. I wanted scheduling decisions to exist independently from execution, so I introduced an ExecutionPlan instead of letting the runtime decide everything on the fly. After that I implemented the runtime itself along with the execution layer. The runtime finally had a complete execution cycle. Too late feeling sleepyyy (┬┬﹏┬┬) however i moved on from my sleep with a coffee but the headache wasnot over yet. First redesign While connecting everything together I realised one part of the architecture wasn’t sitting right. ModuleResult was trying to do too much. Instead of letting it continue to grow, I redesigned it into a cleaner boundary between modules and the runtime. That change also let me decouple the ExecutionLayer from the EventBus . The code became much easier to understand what it does. Here i learned before coding any feature you have to have clearest picture of the feature you want to implement or you will end up debugging and redesigning the architecture whole night like me ಥ_ಥ I’m pretty sure this won’t be the last redesign, but it already feels cleaner than the first version. Testing After getting the runtime working, I didn’t want to assume it was correct. I added integration tests for the runtime cycle instead of only testing individual classes. It’s still a very small project, but having tests this early makes me much more comfortable refactoring things later. Documentation I’ve never really documented architectural decisions properly before. Usually I only remember what I changed. A month later I completely forget why I changed it. So this time I documented everything. End of the day By the end of today, System Design and Architecture was complete. There isn’t much to show visually yet. No robot. No simulator. No fancy AI. Just a runtime that can execute modules, schedule work, and pass integration tests. Honestly, I’m happy with that. The interesting features can wait. I’d rather spend time getting the foundation right than spend the next few months constantly rewriting it. Progress today Project structure Event system Scheduler ExecutionPlan Runtime ExecutionLayer Runtime integration tests ModuleResult redesign ExecutionLayer decoupled from EventBus So at last I went to sleep ofcourse it was important to me, I love my sleep. GoodNight ;-)"}]...
|
Title: CORES Runtime by @ravi10 | Stardance
Devlo Title: CORES Runtime by @ravi10 | Stardance
Devlogs:
Devlog #1: Building the Foundation Date: July 15, 2026 Just started the project and it already feels ike theres too much too learn beofre starting. I know it would be hard designing the whole architecture and system and oh god it was! So as I was saying, I started with the most important steps designing the whole system and architecture of the project. The usual stufff!! : Setting up the project The first few commits were just getting the project into a shape where I could actually start building. Initial repository Project structure Cleaning up the directory layout .gitignore Removing unnecessary cache files Till this point I hadn’t really started implementing the actual idea. It was just a setup, that was going to be base of the whole project. Getting modules to communicate The first actual component I worked on was the event system. I didn’t want modules calling each other directly because that would make everything tightly coupled very quickly. Instead, I added an event-based communication layer. At this point it was very simple, but it gave me something to build on. Scheduler and Runtime Once events were working, I moved on to the scheduler. At first I wasn’t sure how much responsibility the scheduler should have. After a few iterations I settled on keeping it responsible only for deciding what runs next. The ExecutionLayer should only execute that plan. I wanted scheduling decisions to exist independently from execution, so I introduced an ExecutionPlan instead of letting the runtime decide everything on the fly. After that I implemented the runtime itself along with the execution layer. The runtime finally had a complete execution cycle. Too late feeling sleepyyy (┬┬﹏┬┬) however i moved on from my sleep with a coffee but the headache wasnot over yet. First redesign While connecting everything together I realised one part of the architecture wasn’t sitting right. ModuleResult was trying to do too much. Instead of letting it continue to grow, I redesigned it into a cleaner boundary between modules and the runtime. That change also let me decouple the ExecutionLayer from the EventBus . The code became much easier to understand what it does. Here i learned before coding any feature you have to have clearest picture of the feature you want to implement or you will end up debugging and redesigning the architecture whole night like me ಥ_ಥ I’m pretty sure this won’t be the last redesign, but it already feels cleaner than the first version. Testing After getting the runtime working, I didn’t want to assume it was correct. I added integration tests for the runtime cycle instead of only testing individual classes. It’s still a very small project, but having tests this early makes me much more comfortable refactoring things later. Documentation I’ve never really documented architectural decisions properly before. Usually I only remember what I changed. A month later I completely forget why I changed it. So this time I documented everything. End of the day By the end of today, System Design and Architecture was complete. There isn’t much to show visually yet. No robot. No simulator. No fancy AI. Just a runtime that can execute modules, schedule work, and pass integration tests. Honestly, I’m happy with that. The interesting features can wait. I’d rather spend time getting the foundation right than spend the next few months constantly rewriting it. Progress today Project structure Event system Scheduler ExecutionPlan Runtime ExecutionLayer Runtime integration tests ModuleResult redesign ExecutionLayer decoupled from EventBus So at last I went to sleep ofcourse it was important to me, I love my sleep. GoodNight ;-)
Devlog #2 Welcome to my another devlog!! Today was all about the scheduler. Yesterday I finished a greedy scheduler, but I wasn’t convinced it was the best option. So today I implemented an exact 0/1 Knapsack scheduler expecting it to perform much better. After running benchmarks, it honestly wasn’t what I expected. Most of the time both schedulers produced almost the same schedule. For a while I thought I had implemented something incorrectly, so I kept checking the code and rerunning the benchmarks. Turns out the implementation wasn’t the problem. The greedy scheduler was already finding the optimal solution in most of the scenarios I generated. The only noticeable differences appeared when resources became really limited. That’s where I found something that bothered me. During a simulated sensor failure, the Knapsack scheduler decided to stop localization because it increased the optimization score. From a mathematical point of view, that decision was correct. From a robotics point of view, it was terrible. A robot shouldn’t sacrifice safety just because it saves a little more battery. That’s when I stopped thinking about improving the algorithm itself and started thinking about what I was actually asking it to optimize. Instead of using one objective function, I switched to a lexicographic approach. Now scheduling decisions happen in this order: Safety Mission progress Energy Execution time This means lower priorities can never override higher ones. While changing the scheduler, I also realised I had been treating every module exactly the same. That didn’t make much sense. A battery monitor shouldn’t be treated the same way as an exploration module. So I divided modules into three groups. Mandatory Safety Critical Mission Those groups are now used directly by the scheduler. I also added a module dependency graph so relationships between modules can be represented instead of assuming every module is independent. After finishing the scheduler changes, I spent quite a bit of time expanding the benchmarks. I added more scenarios, an ablation framework, and graphs so I could compare different scheduling policies instead of relying on a few manual examples. The result I cared about the most was the original failure case. The previous scheduler reduced safety coverage during a sensor failure. The new scheduler kept safety at 100%. That was enough to convince me this direction makes more sense. Progress today Compared Greedy and Knapsack scheduling Built benchmark scenarios Implemented Lexicographic Scheduler Added module categories Added module dependency graph Created ablation framework Added benchmark visualizations Wrote research experiment documentation 83 tests passing. Today was a good day, I completed and learned so many things from different algorithms and how each behave differently from other in eveyr situation. And it was fun. Not anything cool yet but it felt like i achieved something here.
Devlog #3 hmm, So when i started the project i thought i would build an actual simulation where i could show everyone how it works, its still far from that. So i focused on doing that, I took a break from working on the runtime itself and started building the website. Until now, everything was happening inside the codebase. The runtime was working, benchmarks were running, and tests were passing, but if someone visited the repository they still wouldn’t understand what CORES actually does. I just wanted it to explain the project. Building the homepage I started building the first version of the website using Next.js. Most of the time today went into trying different layouts and figuring out how to present the project in a simple way. The homepage now has: Hero section Navigation Runtime statistics Benchmark summary cards Cognitive architecture visualization Responsive layout One sentence stayed with me while building the page: The project should focus on making robots think better in emergency situations and have actual knowlege of their resources and their environment. I think it explains the project much better than a long paragraph. Designing to match my thinking After changing the layout a few times, I removed most of the unnecessary elements and kept the design much simpler. I’d rather have a clean page that explains the project than something flashy that distracts from it. Deployment Getting the website online wasn’t completely straightforward. Since the repository contains both the Python runtime and the Next.js frontend, I had to configure Vercel to build only the frontend. A couple of module import issues also showed up during deployment. After fixing those, the website finally deployed successfully. Thinking about the project differently While working on the homepage, I realised something. The website shouldn’t just tell people what CORES is. It should help them understand it. Instead of reading pages of documentation, I want someone to interact with the runtime and see how scheduling decisions change under different situations. That’s probably where I’ll spend most of my time next. Testing I also added around 80 more tests while working on the project. The runtime is getting bigger every day, so I’d rather spend extra time writing tests now than spend hours debugging later. End of the day Today wasn’t about adding another algorithm. It was about making the project easier to understand. The runtime is only useful if people can understand what it’s trying to do, and I think the homepage is a good first step toward that. Progress today Built the first version of the CORES homepage Added runtime overview and benchmark cards Added cognitive architecture visualization Simplified the website design Deployed the frontend on Vercel Fixed deployment and module import issues Added around 80 new tests Tomorrow I’ll start working on the simulator so visitors can interact with the runtime instead of only reading about it.
Devlog #4 Today was a difficult day as i was working on too many things but i tried to simulate what i have implemented till now. It was all about making it easier to understand. Until now I had graphs, benchmark results and logs. They were useful for me, but if someone else looked at them, they probably wouldn’t understand why the runtime made a particular decision. That made me think. If a robot suddenly stops or changes its plan, how do I show why that happened instead of just showing numbers? So today I spent most of my time working on the replay system. Building a mission To test everything, I created a simple Mars mission. The rover starts driving normally. Halfway through the mission a rockslide blocks the path. Instead of continuing, the runtime reacts. The rover stops. Safety takes priority. Navigation calculates another path. Then the mission continues. Watching that happen felt much better than looking at benchmark graphs. For the first time it actually felt like I was watching the runtime make decisions. I was happy at this point that all this work actually getting showed in a sim (┬┬﹏┬┬) Making it easier to understand I also spent time improving the replay itself. The rover now has moving wheels, suspension, antenna, brake lights, warning lights and dust effects. I also added different camera angles to make it easier to follow what is happening. One feature I enjoyed building was the cognition timeline. Instead of showing every module sitting there doing nothing, I can now see when modules become active, when they pause and when another module takes over. That made the scheduler much easier to understand, while replaying a mission. One thing I realised The most difficult part was finding a simple way to show what the runtime was thinking. Trust me it was difficult, putting everything into a presentable demo, Trying to fit weeks of work into a small demo meant deciding what to show and what to hide. I had to remove a lot of unnecessary details while still making it clear how the runtime actually works. I think that’s something I’ll keep improving as the project grows. What’s next Right now the replay still uses temporary modules. The next step is replacing them with actual runtime components like Perception, Planning, Navigation, State Estimation and Safety Monitor. After that I’ll connect the replay directly to the Python runtime so every event comes from the real scheduler instead of prerecorded data. Progress today Built the first replay system Added a Mars mission Added dynamic hazards Added cinematic camera modes Added rover animations Added cognition timeline Improved replay visualisation The replay is still pretty simple, but it finally feels like the project is becoming something people can interact with instead of just reading about. I finally achieved something what i wanted to when i started the project, a simulation that is demoable. It’s still far from finished, but seeing the runtime make decisions inside a simulation feels like a huge milestone for me.
Devlog #5 I thought it would be an interesting day today, as I was going to add something important that will help a robot perceive and predict the world. Instead, I spent most of my time reading research papers. At first I thought I could just implement a World Model and move on. After reading more robotics papers, I realised everyone seems to solve the problem differently. Some approaches use occupancy grids. Some track objects. Some build semantic maps. Some focus almost entirely on probabilistic state estimation. I couldn’t find a single approach that worked well across every scenario. That changed my view of how I wanted to build this part of CORES. Instead of picking one approach that works only in one scenario, I started implementing multiple approaches instead of one. The plan Implement them. Benchmark them. See where each one performs well. Let the results decide which one should become the default. One thing I realised While doing this, I also realised that calling everything a “World Model” was a bit misleading. The runtime isn’t trying to store the world. It’s trying to estimate what the world currently looks like based on observations. That made “State Estimation” feel like a much better name for the implementation. The architecture didn’t really change. Only the implementation became clearer. It was mostly about changing how I think about this part of the project. I think spending a day reading papers and redesigning things will save me weeks of rewriting later. I’ve mentioned this before, but I think it’s important to build the clearest picture possible of a feature before implementing it. About the papers Just to be clear, the papers and images below are existing robotics research. I’m not claiming them as my own. I’m studying different approaches before deciding how to implement this part of CORES. Progress today Surveyed different robotics approaches Planned multiple State Estimation strategies Started implementing competing approaches Added benchmark framework Wrote more tests Refactored the architecture Renamed the implementation to State Estimation
Devlog #6 👋 I just wanted to add a way for robot to effectively store and fetch its memory. I expected this phase to be fairly straightforward. The runtime already had State Estimation, Planning and Scheduling. Memory sounded like another subsystem to plug into the pipeline, expose a few interfaces and move on. It didn’t quite go that way. I started with what seemed like the obvious design: A common memory interface with multiple interchangeable strategies. Instead of committing to a single implementation, I built: FIFO Time Decay Priority Episodic SPSCA behind the same abstraction. I knew I’d want to compare different approaches later, so making them interchangeable from the beginning felt like the right decision. Most of the implementation went smoothly 🔥. Then I reached Sparse Principal Component Analysis (SPSCA). Unlike the other strategies, SPSCA wasn’t just storing records. It was trying to represent them. My first implementation followed the algorithm closely. Every piece of content was recursively encoded using semantic pointer operations before being stored. At the time, I was pretty happy with it. Then I ran the benchmarks. The larger scenarios became painfully slow. Some didn’t even finish. I was upset that this whole work and time for nothing and just ruining the project? :-( At this point, I feel like giving up on this and do the next thing or just implement this in the simplest way possible. I actually started making the next phase idea and then while doing that, suddenly out of nowhere, I got an idea about how to find the exact cause of failure 🥹. So, I just went to see that was my hypothesis was correct about the error. I spent a whole evening looking for small optimizations. Once I did, I found the issue with it!. The encoding stage itself had become the bottleneck. That forced me to see the bigger picture of what’s happening during that stage. Instead of trying to optimize the existing implementation, I redesigned the encoding pipeline completely. Memory content is now serialized into a deterministic representation and converted into fixed-length vectors using SHA-256 before participating in similarity operations. The semantic pointer operations are still implemented, but they’re no longer part of every storage operation. That one decision simplified the whole implementation very much. Watching the benchmarks finally finish without timing out was a huge relief. 😭 With the implementation stable again, I turned my attention to testing. I added benchmarks for insertion, retrieval latency, sustained memory growth and strategy comparisons, along with a much larger test suite covering storage, retrieval, forgetting behaviour, vector operations and runtime integration. By the end of the phase, the runtime could finally retain experiences across execution cycles. But, stopped myself from immediately moving on to the next feature as there were still a few loose ends I wanted to clean up before building anything on top of Memory. Nothing in the runtime actually depends on memory yet. Planning doesn’t query it, scheduling doesn’t use it, and no module learns from previous experience. I considered pushing further, but decided against it. Changing the foundation becomes much harder once other components start depending on it. As a small side quest during this phase, I also redesigned the project homepage. Hopefully it finally looks the way I originally imagined it. For now, memory exists for one reason: to give the runtime a place to store or fetch it in a very efficient way.
Devlog #7 Today’s session was dedicated to a very big architectural refactor in the project. The goal was to simplify the memory and reasoning pipeline by redesigning how memory is represented and consolidated while preserving compatibility with the existing runtime. Session Goals Redesigning the memory architecture Removing old unnecessary learning subsystem Introducing Logger Migrating SPSCA Preserving runtime compatibility Keeping full test suite passing Architecture Design I went back to the basics and reviewed the entire architecture. I wanted to make it cleaner by identifying overlapping responsibilities between Memory and Learning. It was very time consuming as there were too many responsibilities and modules to simplify and distinguish here. This resulted in a new architecture: EpisodicStore SemanticStore Logger Since I believe learning will be taken care of in future updates. Implementation Implemented: Memory redesign Logger subsystem Trigger policies SPSCA migration Runtime integration Memory now internally composes Episodic Memory, Semantic Memory, and Logger while exposing a single interface to the runtime. Refactoring Performed a full project-wide migration: replaced string record types with enums updated runtime integration updated imports removed old unnecessary learning components updated public exports Testing & Validation Refactored the testing suite: New module integration tests SPSCA tests Trigger policy tests Updated memory tests Removed old unnecessary tests Final result: 590 / 590 tests passing Lint clean I was happy that the refactor didn’t break anything! (^///^) Documentation Updated: Memory documentation Benchmarks Demo programs Outcome The runtime now has a significantly cleaner architecture: State Estimation → Memory Episodic Semantic Logger → Planning → Scheduler → Execution This refactor was very important as it redefined the whole runtime(base) on which the whole project was built on. This will help to build future phases, secondly dividing memory types was one of the best decisions.
Devlog #8 The demo found a bug before I did. I had that type of day where, you think every feature is working correctly and when you test, you find out its not. The standalone Learning subsystem was deleted a while back. In its place I added the Logger, which uses a compression algorithm living inside Memory. SPSCA, the Semantic Pointer State Compression Algorithm, moved out of the memory strategies and into the Logger where it belonged. The new module: logger it only had one job and that was to summarize long memories and log it and somehow it still failed in demo. 😑 Then demo_memory.py ended with a summary that read: Episodic records: 7 | Semantic narratives: 0 If you watched that demo as an outsider, you would walk away thinking the Logger was a sticker on the box. It looked broken, because it was idle. The records I stored were all too important to archive, but the default trigger needed 50 new records to even consider firing. So I just re-wrote the pipeline and tested it. The bug was just one line Then the demo did something embarrassing. It caught a real bug. The source IDs in the second narrative overlapped with the first. Records that had already been summarized were showing up to be summarized again. Imagine a robot checking the same doorway every patrol because it never recorded that it had already inspected the doorway. The culprit was mark_consolidated checker. It was asked to flip a batch of records to CONSOLIDATED, and it did the polite thing of fetching one record per id. Except every single fetch returned the same record. The top one. So one record got filed, and the other ten stayed on the desk, waiting to be processed forever. A one-line fix and a regression test later, no record is ever re-compressed. Caught the bug by reading my own demo output, which is the cheapest way to find a bug on earth. (≧▽≦) The benchmark that revealed the hidden cost Then I measured the whole pipeline. Not the Logger in isolation, the full journey. Store, archive, trigger, compress, file into semantic memory. The numbers looked fine and then slowly stopped being fine:- 100 records: about 0.66 ms each 1000 records: about 0.83 ms each 5000 records: about 1.77 ms each Every cycle, archiving and consolidation scan the whole store to find what changed. That is a classic hidden O(n^2), the kind that is invisible at demo size and painful at robot lifetime size. It is fine for now. It is written down. It will be fixed before anyone deploys a robot that lives for a year. 😓 The interesting part wasn’t fixing the bug. It was realizing that a good demo isn’t just there to impress people. It’s another test. Unlike unit tests, it exercises the system the way a user would, and today it caught a bug that hundreds of automated tests never did. Sometimes the fastest debugger is simply watching your own software run.
Devlog #9 Meet the Planning Module The Planning Module answers one simple question: “What should we do next?” It looks at the goal and the current state, proposes candidate plans, and picks the best one. The module has one interface and five planners. You hand it a mission, which is a collection of goals. Each goal is something the robot wants to be true. Every planner produces candidate plans with a confidence, estimated cost, duration, and utility score. The module returns all candidates and the one it selects as the best. The five planners are: GoalPlanner searches forward using action pre-conditions and effects. HTNPlanner breaks high-level tasks into smaller actions using authored methods. UtilityPlanner scores candidates and picks the highest. ReactivePlanner reacts immediately to simple conditions. BehaviorTreePlanner executes authored behavior trees. All of them implement the same PlannerStrategy interface, so they can be swapped without changing the rest of the runtime. The planner learned to adapt its own plans Before today, whenever something changed during a mission, the planner threw away the entire plan and started again. Now it walks through the existing plan step by step. If the beginning of the plan is still valid, it keeps it. As soon as it reaches a step that can no longer be completed, it rebuilds only the remaining part. This means the robot no longer repeats work it has already finished. Both the Goal Planner and HTN Planner now support this. Every repaired plan also records where the original plan became invalid. The Runtime handles this automatically. If the environment changes, it first tries to update the existing plan. Only if that fails does it generate a completely new one. The planner learned to notice change The next challenge was deciding when to update a plan. The solution was a planning snapshot: a small summary of the robot and world containing only the information planning actually cares about. Objects, flags, payloads, and sensor-health keys are sorted. Battery is grouped into critical , low , medium , or high instead of using the exact percentage. Temperatures and positions are rounded, while noisy values like timestamps and raw pose are ignored. This keeps the snapshot deterministic, so identical worlds always produce identical snapshots and unnecessary replanning is avoided. The planner learned from experience The second big change was teaching the planner to use previous experiences. Before today, it only looked at the current situation. Now it asks Memory for a summary of previous successes and failures before making a decision. A new wrapper called MemoryAwarePlanner works with any existing planner. It lets the original planner create a plan, then adjusts the choices based on previous outcomes. Plans that failed before become less attractive, while successful ones get a small boost. The selected plan is stored back into Memory so future missions can learn from it as well. If there is no previous experience, the planner behaves exactly as it did before. The demo ties everything together. First, Door A becomes blocked, so the planner updates the existing plan and switches to Door B instead of starting over. Then, on the next run, Memory remembers that Door A failed twice while Door B succeeded once, so the planner chooses Door B from the beginning.
Devlog #10 Meet the Mission Manager “What should the robot work on right now?” Planning already knows how to achieve a goal, but it doesn’t decide which goal is the most important. The Mission Manager sits one level above Planning, keeps track of every mission, chooses the active goal, and hands only that goal to the planner. Spent most of the day building the Mission Manager. The idea sounds simple: a mission is a list of goals, the manager picks the active one, hands it to Planning, and waits for the result. The details were anything but simple. I started with the mission lifecycle. Every mission begins in NEW , becomes READY , then ACTIVE , and eventually reaches a terminal state: COMPLETED , FAILED , or CANCELLED . A mission can also be PAUSED and resumed later. The transition rules are strict. You can’t jump from CANCELLED back to ACTIVE , and you can’t skip directly from NEW to COMPLETED . Every transition has to make sense. I spent much longer than I expected getting the state diagram and all the transitions right. Preemption was probably the most interesting part. When a higher-priority mission arrives, the current one moves back to READY , not PAUSED . That distinction took a while to figure out. PAUSED means someone intentionally stopped the mission. Preemption means the system decided something more important needs attention first. Different reasons, different states. Goals also execute one at a time. A goal can depend on another goal, so a task like Drop Package won’t begin until Pick Package has finished. Goal completion works in two independent ways. You can either call complete_goal() directly, or use a constraint evaluator that checks the robot’s state automatically. Neither depends on the other, and a goal never completes simply because it has no constraints. That felt like the safest design. A bug the dashboard exposed Near the end, I ran into a strange bug. As soon as a mission finished, the manager immediately wrote "idle" into the robot state, clearing the mission ID and progress. If you were watching the dashboard, the mission simply disappeared the moment it completed. The fix was straightforward: keep the final mission state visible until another mission becomes active. Now the homepage trace finishes at 100% Complete instead of dropping back to idle immediately. It was a small issue, but it made the runtime feel much more polished. Integration The cleanest part of this phase was the integration. Nothing else needed to change. The Scheduler still schedules. The Planner still plans. The Mission Manager simply runs earlier in the runtime cycle, selects the active goal, and passes it to Planning. Even the original way of giving a mission directly to the Runtime still works, so existing code remains compatible. Some Cleanups The rest of the session went into polishing the project. Updated documentation and runtime diagrams Refreshed test and strategy counts Replaced the remaining banned terminology Renamed the HTN primitive class across seven files for consistency Fixed benchmark test collection by adding import fallbacks for script execution Nothing particularly exciting, but it leaves the project in a much healthier state. I think this phase is finally complete.
Ships:
CORES is a research project exploring how autonomous robots can schedule cognition instead of simply executing tasks. This update introduces the first public version of the CORES experience. I built and deployed a homepage that explains the runtime architecture, scheduling, benchmark overview, and cognitive module system. A major focus was making a complex robotics runtime understandable through clean visual design rather than long technical documentation. The next milestone is an interactive runtime simulator where visitors will be able to inject hazards, change mission conditions, and watch the scheduler reprioritize cognitive modules in real time. Exact visualizations and benchmark charts will be added. I’d love feedback on: Is the core idea easy to understand? Does the homepage clearly communicate the purpose of CORES? What sections are confusing or missing?
CORES Runtime is an open-source cognitive runtime for autonomous robots. Instead of controlling robot hardware directly, it manages the software systems that sit between perception, planning, scheduling, memory, and execution. Its goal is to help robots decide what to run, when to run it, and how to manage limited compute and energy while remaining deterministic and predictable. This ship focuses on a major redesign of the memory subsystem. I replaced the previous learning architecture with a new memory pipeline built around Episodic Memory, Semantic Memory, and a Logger that compresses experiences into long-term knowledge. During development, I discovered and fixed a consolidation bug through the demo itself, added regression tests, benchmarked the full compression pipeline, and documented a known scaling limitation for future optimization....
|
1793775275.2420752
|
1794639275.2420752
|
|
21119
|
Frictionless by @t13437304 | Stardance
|
t13437304
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Frictionless by @t13437304 | Stardance
|
1793775274.2290735
|
1794380074.2290735
|
|
25473
|
Rereader by @jacobjuneau | Stardance
|
jacobjuneau
|
1
|
1.0
|
1
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-25T14:03:30Z", "hours": 1.0, "multiplier": 1.83, "payout": 1, "blessing": "neutral", "text": "A terminal-based ebook reader with automatic progress saving. Read EPUB and MOBI files, pick up right where you left off. Right Now we only support EPUB and Decrypted MOBI files as I cannot ship a DRM stripper along with the program.", "repo": "https://github.com/jacobjuneau6/rereader", "demo": "https://crates.io/crates/rereader"}]...
|
[{"post_id": 15340, "ts": "202 [{"post_id": 15340, "ts": "2026-06-24T22:34:00Z", "hours": 0.5706, "text": "I just kind of made this. i have already written a rust ereader for my kindle so this was pretty easy."}]...
|
Title: Rereader by @jacobjuneau | Stardance
Devlo Title: Rereader by @jacobjuneau | Stardance
Devlogs:
I just kind of made this. i have already written a rust ereader for my kindle so this was pretty easy.
Ships:
A terminal-based ebook reader with automatic progress saving. Read EPUB and MOBI files, pick up right where you left off. Right Now we only support EPUB and Decrypted MOBI files as I cannot ship a DRM stripper along with the program....
|
1793775273.3260953
|
1794639273.3260953
|
|
33878
|
Breakdown by @f | Stardance
|
f
|
1
|
37.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-16T12:09:50Z", "hours": 37.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made Breakdown, a privacy-first Chrome extension that turns giant Terms of Service and Privacy Policies into a quick, readable summary. One click gives you a risk score, the biggest red flags, what data is collected, your rights, and the clauses you should actually care about. The best part: everything runs locally on your device. No accounts, no API keys, no cloud, and no tracking. The biggest challenge was making it accurate without relying on AI. My first version used a local LLM, but it was slow, huge, and sometimes confidently made things up. I replaced it with my own rule-based NLP engine that detects legal clauses, handles things like “we do not sell your data”, and shows the exact sentence that triggered each result. I’m most proud that Breakdown became better by removing AI, it went from a 1-2GB model download to an instant 18KB offline analyzer. To test it, open any Terms of Service or Privacy Policy page, click the extension, and see what companies are actually asking you to agree to.", "repo": "https://github.com/pefia/Breakdown", "demo": "https://github.com/pefia/Breakdown/releases/tag/v1.0.0"}]...
|
[{"post_id": 29442, "ts": "202 [{"post_id": 29442, "ts": "2026-07-16T12:02:28Z", "hours": 6.0, "text": "Bringing everything together Today was mostly about merging all five feature branches back into main and making sure everything still worked afterwards. I also managed to speed up the summaries to near instant so the user experience is way better. (Screenshots are from Anthropic ToS) Most of the merges happened automatically, but I still went through the UI files manually to make sure nothing had been overwritten and the new components all fit together properly. New features Radial risk gauge around the score. Risk category breakdown card. Background analysis using a Web Worker. Faster debounced search. Confidence chips and skeleton loading. Final checks After merging everything I: Ran all 24 unit tests . Built the extension from scratch. Verified the worker bundled correctly. Checked the UI for duplicate styles or merge issues. Cleaned up the temporary branches and worktrees. Everything passed, so the project is now back on a single branch with all five features fully integrated."}, {"post_id": 29038, "ts": "2026-07-15T18:08:01Z", "hours": 10.0, "text": "Goodbye AI, hello NLP This update completely changed how Breakdown works. The screenshots are from review of the Meta (Facebook) ToS and the Hack Club ToS, see if you can tell which one is which and comment it 😉 Originally it used a 1-2 GB language model running through WebLLM. It worked, but startup was slow, downloads were huge, and it could still hallucinate clauses that weren’t actually in a policy. I replaced the entire pipeline with a deterministic rule-based NLP engine that runs fully on-device. I briefly kept a small embedding model to catch unusual wording, but testing showed it was responsible for almost every false positive, so I removed that too. What changed Removed all AI models and embeddings. No downloads or GPU required. Fully offline and deterministic. Analyzer shrunk to just 18 KB . Biggest challenge The hardest part was keeping the results accurate without relying on AI. I rewrote detection around sentence-level rules, proper negation handling, and much stricter legal clause matching, then built a new test suite using real-world policies to make sure false positives stayed gone. The result Removed 49 npm packages . Deleted the entire AI pipeline. Faster analysis with no waiting. More reliable results than the original AI version."}, {"post_id": 27666, "ts": "2026-07-13T13:11:12Z", "hours": 11.0, "text": "bugs bugs bugs. this devlog is just about bugs there were soooooooo many bugs bug 1: ai models giving up - there were instances where the model timed out for one reason or another but didnt throw an error to the extension so you could’ve waited 20 minutes with the same loading screen.. bug 2: inaccuracies and hallucinations - with such a small AI model that runs locally, it isn’t as good as the latest ChatGPT or Claude, so the answers tended to be of a lower quality and sometimes just plain lies feature add! : instead of a static loading screen there is now stages, with the word count of the summary also being updated in real time, with some added facts to keep the user interested! next, i hope to improve model quality further and fix a bug where transformers.js/ONNX runtime is trying to cache a chrome-extension:// WASM URL leading to an error."}, {"post_id": 26961, "ts": "2026-07-12T01:49:59Z", "hours": 8.0, "text": "I am working on a Chrome Extension called Breakdown. What is Breakdown? Breakdown is a Chrome Extension that summarises Terms of Services and Privacy Policies, so you can really see what companies are collecting from you. My Progress so far: I have made a working prototype, which has a 65% accuracy, with the categories being right like 50% of the time… Struggles: It was very difficult to get WebLLM working with a Local AI Model that didn’t frequently hallucinate but can still run on bad specs (no GPU, etc.) To do: Redo UI, i hate it so much Try and add cool loading animations when downloading AI Models for first time Make AI Model way more accurate"}]...
|
Title: Breakdown by @f | Stardance
Devlogs:
I am Title: Breakdown by @f | Stardance
Devlogs:
I am working on a Chrome Extension called Breakdown. What is Breakdown? Breakdown is a Chrome Extension that summarises Terms of Services and Privacy Policies, so you can really see what companies are collecting from you. My Progress so far: I have made a working prototype, which has a 65% accuracy, with the categories being right like 50% of the time… Struggles: It was very difficult to get WebLLM working with a Local AI Model that didn’t frequently hallucinate but can still run on bad specs (no GPU, etc.) To do: Redo UI, i hate it so much Try and add cool loading animations when downloading AI Models for first time Make AI Model way more accurate
bugs bugs bugs. this devlog is just about bugs there were soooooooo many bugs bug 1: ai models giving up - there were instances where the model timed out for one reason or another but didnt throw an error to the extension so you could’ve waited 20 minutes with the same loading screen.. bug 2: inaccuracies and hallucinations - with such a small AI model that runs locally, it isn’t as good as the latest ChatGPT or Claude, so the answers tended to be of a lower quality and sometimes just plain lies feature add! : instead of a static loading screen there is now stages, with the word count of the summary also being updated in real time, with some added facts to keep the user interested! next, i hope to improve model quality further and fix a bug where transformers.js/ONNX runtime is trying to cache a chrome-extension:// WASM URL leading to an error.
Goodbye AI, hello NLP This update completely changed how Breakdown works. The screenshots are from review of the Meta (Facebook) ToS and the Hack Club ToS, see if you can tell which one is which and comment it 😉 Originally it used a 1-2 GB language model running through WebLLM. It worked, but startup was slow, downloads were huge, and it could still hallucinate clauses that weren’t actually in a policy. I replaced the entire pipeline with a deterministic rule-based NLP engine that runs fully on-device. I briefly kept a small embedding model to catch unusual wording, but testing showed it was responsible for almost every false positive, so I removed that too. What changed Removed all AI models and embeddings. No downloads or GPU required. Fully offline and deterministic. Analyzer shrunk to just 18 KB . Biggest challenge The hardest part was keeping the results accurate without relying on AI. I rewrote detection around sentence-level rules, proper negation handling, and much stricter legal clause matching, then built a new test suite using real-world policies to make sure false positives stayed gone. The result Removed 49 npm packages . Deleted the entire AI pipeline. Faster analysis with no waiting. More reliable results than the original AI version.
Bringing everything together Today was mostly about merging all five feature branches back into main and making sure everything still worked afterwards. I also managed to speed up the summaries to near instant so the user experience is way better. (Screenshots are from Anthropic ToS) Most of the merges happened automatically, but I still went through the UI files manually to make sure nothing had been overwritten and the new components all fit together properly. New features Radial risk gauge around the score. Risk category breakdown card. Background analysis using a Web Worker. Faster debounced search. Confidence chips and skeleton loading. Final checks After merging everything I: Ran all 24 unit tests . Built the extension from scratch. Verified the worker bundled correctly. Checked the UI for duplicate styles or merge issues. Cleaned up the temporary branches and worktrees. Everything passed, so the project is now back on a single branch with all five features fully integrated.
Ships:
I made Breakdown, a privacy-first Chrome extension that turns giant Terms of Service and Privacy Policies into a quick, readable summary. One click gives you a risk score, the biggest red flags, what data is collected, your rights, and the clauses you should actually care about. The best part: everything runs locally on your device. No accounts, no API keys, no cloud, and no tracking. The biggest challenge was making it accurate without relying on AI. My first version used a local LLM, but it was slow, huge, and sometimes confidently made things up. I replaced it with my own rule-based NLP engine that detects legal clauses, handles things like “we do not sell your data”, and shows the exact sentence that triggered each result. I’m most proud that Breakdown became better by removing AI, it went from a 1-2GB model download to an instant 18KB offline analyzer. To test it, open any Terms of Service or Privacy Policy page, click the extension, and see what companies are actually asking you to agree to....
|
1793775272.3389857
|
1794639272.3389857
|
|
3005
|
APEX Rocket by @gavbfarrell_041409 | Stardance
|
gavbfarrell_041409
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: APEX Rocket by @gavbfarrell_041409 | Starda Title: APEX Rocket by @gavbfarrell_041409 | Stardance...
|
1793775271.157984
|
1794380071.157984
|
|
13992
|
My very own WebOS by @chaitanya57313 | Stardance
|
chaitanya57313
|
1
|
6.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-11T08:26:14Z", "hours": 6.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a working webos. I face challenges with creating the workflow of the webos which i overcame with the help of google’s gemini. anyways i hope yall like!!", "repo": "https://github.com/Chaitanya1956/WebOS---Chaos-OS", "demo": "https://bagesai.me/WebOS---Chaos-OS/index.html"}]...
|
[{"post_id": 6727, "ts": "2026 [{"post_id": 6727, "ts": "2026-06-11T08:24:30Z", "hours": 0.0, "text": "gave final touches and published it on a public site"}, {"post_id": 6715, "ts": "2026-06-11T07:48:44Z", "hours": 2.0, "text": "completed webos."}, {"post_id": 6258, "ts": "2026-06-10T14:51:01Z", "hours": 3.0, "text": "made the css. cool stuff inc 🔥🔥"}]...
|
Title: My very own WebOS by @chaitanya57313 | Star Title: My very own WebOS by @chaitanya57313 | Stardance
Devlogs:
made the css. cool stuff inc 🔥🔥
completed webos.
gave final touches and published it on a public site
Ships:
I made a working webos. I face challenges with creating the workflow of the webos which i overcame with the help of google’s gemini. anyways i hope yall like!!...
|
1793775270.2914233
|
1794639270.2914233
|
|
30862
|
Psync by @jacobjuneau | Stardance
|
jacobjuneau
|
1
|
93.0
|
1577
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-11T22:18:47Z", "hours": 93.0, "multiplier": 16.94, "payout": 1577, "blessing": "neutral", "text": "Note: Very untested, only try with projects you have backups of! Psync was designed to solve the problem of my laptop having limited storage and my with to be able to use my nas semi-transparently without the use of automountd or fuse both of which I have tried and deployed in other scenarios and neither of which are resiliant to not being able to contact the NFS server when on different networks. So i made Psync which uses encryption which make me feel secure enough to open it up to the internet instead of unauthenticated NFS.", "repo": "https://github.com/jacobjuneau6/Psync", "demo": "https://crates.io/crates/pwr-cli"}]...
|
[{"post_id": 26707, "ts": "202 [{"post_id": 26707, "ts": "2026-07-11T17:33:03Z", "hours": 2.0, "text": "Add bash tab completion script for pwr CLI commands Provide a bash completion function for all pwr subcommands and their flags. The completion script maps each subcommand to its valid arguments: init completes –server-host, –server-port, –psk, and –local-root; archive, restore, and ensure complete directory paths; status and list offer –recursive/-r; log provides –errors/-e and –project; shell completes bash, zsh, fish, and –init. The completion is installed via ‘source <(pwr completions bash)’ in .bashrc."}, {"post_id": 26622, "ts": "2026-07-11T15:31:34Z", "hours": 2.0, "text": "Document required parentheses around impl Trait syntax in handler signatures The Rust 2024 edition requires explicit parentheses around compound trait bounds in function argument position. Without them, ‘&mut impl Read + Write’ is ambiguous: it could parse as ‘(&mut impl Read) + Write’ (a mutable reference to a type implementing Read, with an additional Write bound) or ‘&mut (impl Read + Write)’ (a mutable reference to a type implementing both). The compiler requires the latter to be written with parentheses. Add a module-level doc comment explaining this so future maintainers do not attempt to remove the parentheses."}, {"post_id": 26556, "ts": "2026-07-11T13:30:09Z", "hours": 2.0, "text": "Add end-to-end integration tests for full client-server lifecycle Implement two end-to-end tests using paired in-memory byte streams (Pipe struct implementing Read+Write via Arc<Mutex<Vec») that simulate a complete client-server interaction without network dependencies. test_full_client_server_archive_restore_cycle creates a multi-file project directory, generates age encryption keys and a PSK, runs the archive pipeline to produce an encrypted blob, then spawns two threads for client and server communicating through paired pipes. The client performs the full protocol sequence: Handshake with HMAC-SHA256 proof, ArchiveRequest with project metadata, chunked data transfer with 1 MiB chunks and zero-length EOF marker, and ArchiveComplete with SHA-256 hash. The server thread receives the Handshake, verifies the client proof, responds with its own server proof for mutual authentication, reads the ArchiveRequest, receives all chunks via the 4-byte length-prefixed streaming protocol, and acknowledges ArchiveComplete. After both threads join, assertions verify the server received the exact encrypted blob, decryption succeeds, and the local project metadata transitions correctly through local → archived → placeholder states with .project.toml file survival. test_end_to_end_hash_verification_prevents_corruption validates that tampering with a single byte of the encrypted archive produces a different SHA-256 hash, ensuring integrity violations are detectable before extraction."}, {"post_id": 26393, "ts": "2026-07-11T04:56:13Z", "hours": 2.0, "text": "Add operation progress overlay to TUI and wire pwr tui subcommand in CLI Implement an OperationOverlay screen for the ratatui-based TUI that renders a centered modal dialog with a progress gauge, transfer statistics, and a cancel prompt during archive and restore operations. The overlay displays the operation name and project name in the title bar, a cyan progress gauge driven by the bytes_done/bytes_total ratio, a statistics line showing human-readable byte counts with percentage, and a status line that changes between ‘Press Esc to cancel’ during transfer, ‘Transfer complete’ on success, and red error text on failure. The format_size helper converts byte counts to GB/MB/KB/B with one decimal place. The handle_input method maps Escape to cancellation and Enter to dismissal after completion. Wire the pwr tui subcommand into the CLI behind the tui feature flag. The Commands enum gains a Tui variant gated by #[cfg(feature = “tui”)], the dispatch match arm calls cmd_tui(), and the tui module is conditionally compiled. Building without –features tui produces a CLI-only binary; building with the flag includes the ratatui and crossterm dependencies and the tui module, enabling pwr tui to launch the interactive interface."}, {"post_id": 26352, "ts": "2026-07-11T02:54:46Z", "hours": 1.9667, "text": "Annotate session state structs with allow(dead_code) for future use The ArchiveSession and RestoreSession structs in the handler state machine contain fields (session_id, file_count, compression, bytes_received, bytes_sent) that are stored for future use in resume-after-interruption logic and detailed transfer statistics. Currently they are only written during state transitions but not yet read back. Add #[allow(dead_code)] annotations to suppress compiler warnings while keeping the fields available for the planned transfer progress tracking and interrupted archive resume features."}, {"post_id": 26283, "ts": "2026-07-11T00:05:32Z", "hours": 2.0333, "text": "Fix warning: remove unused variable and clean up imports Remove the unused config variable clone from the listener accept loop where it was captured by the thread closure but never referenced. Remove the unused PrivateKeyDer import from rustls pki_types. Prefix the catch-all match variable with underscore to suppress the unused variable warning in the dispatch function. Keep the required parentheses around impl Trait syntax in argument position as required by Rust 2024 edition for disambiguation. Add MIT LICENSE file."}, {"post_id": 26236, "ts": "2026-07-10T22:03:06Z", "hours": 2.0, "text": "Add systemd service unit and deployment guides for server and client Create a hardened systemd service unit for pwr-server with security directives including NoNewPrivileges, PrivateTmp, ProtectSystem=strict, ProtectHome=yes, and read-only access to config and certificate paths with read-write access only to the project storage directory. The service runs as the pwr system user, restarts on failure with a 5-second delay, and logs to journald. Resource limits cap file descriptors at 4096 and memory at 512 MB. Add docs/server-setup.md covering the complete Debian 12 deployment workflow: installing build dependencies, compiling with cargo, initializing the server to generate TLS certificates and PSK, creating the storage directory with correct ownership, installing and enabling the systemd service, verifying the listener with ss, configuring firewall rules for nftables and iptables, and troubleshooting common issues. Add docs/client-setup.md covering the Arch Linux client workflow: building the binary, running pwr init with server host and PSK, setting up shell integration for bash, zsh, and fish, performing the first archive and restore, launching the TUI, and troubleshooting configuration and authentication errors. Include a full configuration file reference."}, {"post_id": 26145, "ts": "2026-07-10T19:28:04Z", "hours": 2.0, "text": "Fix client integration tests and add retry-aware connect test Repair the client integration test suite after the retry logic and library target additions. The connect_to_nonexistent_server test now uses a match statement instead of unwrap_err to work with the ClientResult type. The connect_timeout_is_respected test is marked #[ignore] because OS-level TCP timeout behavior varies across platforms, making sub-second timeout assertions unreliable in CI environments. Unused imports (TcpListener, Duration) are removed from the test file."}, {"post_id": 26055, "ts": "2026-07-10T17:19:39Z", "hours": 2.0, "text": "Add progress bar integration to CLI with empty-archive edge case handling also add 0-byte transfer file size."}, {"post_id": 25987, "ts": "2026-07-10T15:17:01Z", "hours": 1.9667, "text": "Add progress callback support to client archive and restore methods Extend archive_project and restore_project with optional progress callbacks that report bytes transferred against total size. The existing methods become thin wrappers calling the new archive_project_with_progress and restore_project_with_progress variants with None for backward compatibility. During archive, the callback fires after each 1 MiB chunk is written to the TCP stream, reporting cumulative bytes sent. During restore, the callback fires after each received chunk is appended to the buffer, reporting cumulative bytes received. The callback signature is fn(u64, u64) where the first argument is current progress and the second is the total, suitable for driving indicatif progress bars or TUI progress displays without coupling the client module to any specific UI library."}, {"post_id": 25938, "ts": "2026-07-10T13:15:41Z", "hours": 1.9667, "text": "Add exponential backoff retry logic to PwrClient connection Implement connect_with_retry in PwrClient that wraps the existing connection logic with up to 3 retry attempts using exponential backoff starting at 1 second and doubling to 2 and 4 seconds. The existing connect method is renamed to connect_once and made private, with the public connect method now calling it in a retry loop. Transient network failures such as TCP connection refused or TLS handshake timeouts are retried, while authentication failures are not (they propagate immediately since retrying with the same credentials would produce the same result). Each retry attempt is logged at WARN level with the error and delay, and a successful retry is logged at INFO level. The connect_timeout_secs from the client config is applied to each individual TCP connection attempt within the retry loop."}, {"post_id": 25722, "ts": "2026-07-10T04:53:07Z", "hours": 2.0, "text": "Implement TLS transport with custom certificate verifier and fingerprint pinning Replace the TLS-not-yet-implemented stub in the PwrClient with a working rustls-based TLS 1.3 connection layer. The connect_tls function builds a ClientConfig using the dangerous API with a custom certificate verifier (CertVerifier) that accepts self-signed server certificates — necessary because pwr-server generates its own ECDSA P-256 certificate during init rather than obtaining one from a public CA. Authentication is provided by the PSK handshake running over the encrypted channel, so the TLS layer provides confidentiality while the application layer handles mutual authentication. The verifier supports optional SHA-256 certificate fingerprint pinning. When a server_fingerprint is present in the client config, the verifier computes the SHA-256 hash of the server’s end-entity certificate and compares it against the pinned value, rejecting the connection on mismatch. When no fingerprint is configured, the verifier accepts any certificate but logs the observed fingerprint for the user to pin later, enabling a trust-on-first-use workflow. Signature verification in the verifier accepts all TLS 1.2 and 1.3 signatures without checking against a root CA. This is intentional: the security model relies on PSK-based mutual authentication at the application layer combined with certificate pinning for defense-in-depth, rather than on the Web PKI trust infrastructure which would reject self-signed certificates. The supported_verify_schemes list advertises ECDSA and RSA schemes to maximize compatibility."}, {"post_id": 25674, "ts": "2026-07-10T02:47:59Z", "hours": 1.9667, "text": "Add server address display to status command output Extend the status command to print the configured server host and port after the project count summary, giving users a quick reminder of which NAS their projects are archived to."}, {"post_id": 25619, "ts": "2026-07-10T00:28:40Z", "hours": 2.0333, "text": "Fix server handler and listener warnings: remove unnecessary parentheses and unused imports Clean up compilation warnings in the pwr-server crate. In handler.rs, the send_server_msg function signature used unnecessary parentheses around impl Write which triggered the unused_parens lint. In listener.rs, the PrivateKeyDer import was unused since the key is loaded via rustls_pemfile::private_key which returns a generic PrivateKeyDer type that does not need to be explicitly imported."}, {"post_id": 25572, "ts": "2026-07-09T22:06:58Z", "hours": 2.0, "text": "Clean up unused imports and fix compilation warnings in client TLS module Remove unused Arc import from the top-level client scope (it is only needed inside the connect_tls function where it is imported locally). Replace TrustAnchor with the correct ServerName import from rustls::pki_types. Remove the unnecessary mut qualifier from the ClientConnection binding in connect_tls."}, {"post_id": 25494, "ts": "2026-07-09T20:05:53Z", "hours": 2.0, "text": "Add –tls flag to all network commands, –limit to log, –auto-install to shell init Extend the CLI with connection and usability flags across all subcommands. Every command that contacts the server (archive, restore, ensure, status, list) now accepts a –tls flag that is passed through to PwrClient::connect, controlling whether the connection uses TLS with certificate pinning or plaintext for local testing. The log command gains a –limit flag defaulting to 50 entries, with a summary line showing how many entries were truncated. The shell init command supports –auto-install which opens the shell rc file in append mode and writes the eval line directly, providing a one-command setup experience. Function signatures throughout main.rs are updated to thread the new boolean parameter. The ensure command passes tls=false through to its internal restore call since ensure is triggered from the shell wrapper where TLS may not be configured. The list command delegates to cmd_status with tls=false for local-only directory scanning."}, {"post_id": 25418, "ts": "2026-07-09T18:04:28Z", "hours": 2.0, "text": "Wire progress bars and retry logic into CLI archive and restore commands Integrate the progress reporting module and retry logic into the two main CLI workflows. The archive command now creates a progress bar before the packaging pipeline and passes it to create_archive_with_progress via a ProgressFn callback that maps ArchiveStage values to status messages and fractional bar position. A second progress bar tracks the upload phase. Both bars are finished and cleared on completion. The restore command similarly uses a download progress bar keyed to the stored project size and an extraction progress bar sized to the received encrypted blob. Connection attempts now use with_retry wrapping PwrClient::connect with 3 retries and a 1-second base delay, retrying only on transient network errors as classified by is_retryable_error. This provides resilience against momentary server unavailability without masking fatal errors like authentication failures."}, {"post_id": 25343, "ts": "2026-07-09T16:03:49Z", "hours": 2.0, "text": "Add client integration test suite with handshake, streaming, retry, and progress tests Create 14 integration tests in pwr-cli/tests/client_integration.rs covering the client-side protocol layer. Handshake tests verify that ClientMessage frames encode with correct magic bytes, version, and type discriminants, and that decode_client_message recovers the original Handshake struct with client_id and nonce intact. Archive flow tests exercise ArchiveRequest and ArchiveComplete serialization round-trips with all fields including UUID, name, total_size, file_count, compression, and hash. Restore flow tests verify RestoreRequest encoding and decoding. Server response parsing tests validate that HandshakeAck, Error, and StatusResponse messages are correctly deserialized from framed payloads, including success flags, error codes, and project info vectors with UUID and file_count fields. Chunk streaming tests cover five size boundaries from zero bytes (EOF detection) through 1 MiB, plus standalone EOF marker encoding. Retry logic tests verify is_retryable_error correctly classifies connection failures, timeouts, and broken pipes as transient while treating authentication and not-found errors as fatal. with_retry is tested for immediate success, maximum retry exhaustion (initial + 3 retries = 4 calls), and early termination on non-retryable errors after 1 call. A progress stage test confirms all five ArchiveStage variants are distinct."}, {"post_id": 25289, "ts": "2026-07-09T14:02:25Z", "hours": 1.9667, "text": "Add progress reporting module with indicatif integration and stage callbacks Introduce a progress module in the pwr CLI crate that provides two display modes for long-running operations. The archive_progress_bar and restore_progress_bar functions create indicatif ProgressBar instances with styled templates showing a spinner, progress bar, byte counter, and ETA. The update_archive_progress function maps ArchiveStage enum values to human-readable status messages displayed in the bar. For non-interactive terminals or quiet mode, print_stage emits a simple line to stderr for each stage transition during archive or extract operations. This provides visibility into long-running operations without requiring a TTY."}, {"post_id": 25182, "ts": "2026-07-09T07:46:17Z", "hours": 2.0333, "text": "Implement TLS connector with certificate pinning and retry logic for the client Add a complete TLS connection path to PwrClient, replacing the previous stub that returned a not-yet-implemented error. The connect_tls function builds a rustls ClientConfig with webpki root certificates for standard PKI validation. When a server_fingerprint is set in the client config, a custom FingerprintVerifier replaces the default verifier. This verifier computes the SHA-256 hash of the server’s end-entity certificate DER bytes and compares it against the pinned hex fingerprint, implementing trust-on-first-use style certificate pinning without requiring a private CA. The verifier supports TLS 1.2 and 1.3 signature schemes including RSA and ECDSA P-256. The PwrClient struct gains server_addr, psk, and pinned_fingerprint fields, enabling a reconnect method that re-establishes a TCP connection to the same server and re-runs the PSK handshake without reloading the config file. The connect method now branches on use_tls, routing to either the TLS path with certificate validation or the plaintext path for local testing. Add retry logic via the with_retry helper, a generic function that wraps any fallible operation with exponential backoff. The caller provides a retryable-error predicate; is_retryable_error recognizes connection refused, timeout, connection closed, connection reset, broken pipe, and unexpected EOF as transient errors worth retrying. The base delay doubles each attempt, with a configurable maximum number of retries."}, {"post_id": 25150, "ts": "2026-07-09T05:35:05Z", "hours": 2.0, "text": "Add server integration test suite and library target for external testing Create 17 integration tests in pwr-server/tests/server_integration.rs covering the full server subsystem. Storage CRUD tests (6) verify project creation with duplicate rejection, removal, archive read/write round-trips through the storage layer, persistence across re-opens via registry JSON, and size limit enforcement rejecting archives exceeding the configured max_project_size_gb. PSK handshake tests (3) validate the full mutual authentication flow with correct proof verification and wrong-PSK rejection. Frame-level integration tests (3) exercise the complete serialization pipeline: Handshake framing round-trip with client_id and nonce preservation, ArchiveRequest framing with all fields intact, and server message decode direction checking. File chunk streaming tests (2) simulate the chunk protocol by encoding 250 KB of cyclical data across 4 KB chunks with 4-byte length prefixes and EOF markers, reassembling on the receiver side and verifying content equality. An empty archive test confirms that a standalone EOF marker produces zero bytes of received data. Rate limiter tests (3) verify the 6th attempt is blocked after 5 allowed, success resets the window, and different IPs are tracked independently. A full archive-restore simulation test writes 500 KB of data through the storage layer, reads it back, and verifies byte-exact restoration plus metadata persistence. A cleanup test confirms that removing a project after a failed archive deletes both the archive file and registry entry. To support external integration tests, a library target (lib.rs) is added to pwr-server, re-exporting all modules as public while the binary target (main.rs) retains its own private module declarations."}, {"post_id": 25104, "ts": "2026-07-09T02:58:05Z", "hours": 2.0, "text": "Add file chunk streaming to archive and restore handlers Implement the raw chunk streaming protocol in both directions on the server side. After accepting an ArchiveRequest, the handler enters a chunk receive loop (handle_archive_chunks) that reads 4-byte big-endian length prefixes followed by that many bytes of data, appending each chunk to the project’s archive file on disk via append-mode file I/O. A zero-length chunk signals EOF. The total bytes received is logged for monitoring. On the restore side, handle_restore_chunks reads the complete archive file from disk through the storage layer, then streams it back to the client in 1 MiB chunks with the same 4-byte length-prefixed format, followed by a zero-length EOF marker and a flush. This mirrors the client’s restore_project method which reads chunks in the same format. The dispatch function now chains the chunk streaming phase after the initial request acceptance: ArchiveRequest dispatch calls handle_archive_start followed by handle_archive_chunks, and RestoreRequest calls handle_restore_start followed by handle_restore_chunks. The ArchiveComplete and RestoreComplete messages are received as framed messages after the chunk phase completes, handled by the existing finish functions."}, {"post_id": 24986, "ts": "2026-07-08T21:34:40Z", "hours": 2.0, "text": "Add IP-based authentication rate limiter and integrate into handshake handler Implement a per-IP rate limiter in the server’s auth module that tracks failed authentication attempts within a sliding 60-second window. Each IP is allowed up to 5 failed handshake attempts before being banned for 300 seconds. The RateLimiter maintains an in-memory HashMap<IpAddr, RateLimitEntry> with periodic cleanup of expired entries to prevent unbounded memory growth. The check_attempt method atomically increments the attempt counter, resets the window if it has expired, checks whether the IP is currently banned, and returns false if the attempt should be rejected. record_success resets the counter and clears any ban on successful authentication, allowing legitimate clients that temporarily misconfigured their PSK to recover. The rate limiter is shared across all connections via Arc<Mutex<» and passed through HandlerContext. The handshake handler calls check_attempt before validating the PSK proof, ensuring brute-force attempts are blocked before any cryptographic work is performed. If the rate limit is exceeded, a HandshakeAck with a descriptive error is sent and the connection is closed. On successful authentication, record_success is called to clear the counter. Four unit tests verify that the first five attempts are allowed, the sixth is blocked, record_success resets the counter, and different IPs are tracked independently."}, {"post_id": 24904, "ts": "2026-07-08T19:20:56Z", "hours": 2.0, "text": "Implement server main entry point with clap CLI and fix listener/handler compilation Add a complete main.rs for pwr-server with three clap subcommands. The init subcommand detects or accepts a hostname, delegates to cert::init_server for TLS certificate generation, PSK creation, and config file writing, then prints the start command. The start subcommand locates the config file via the standard search path, loads and validates the ServerConfig, logs the bind address and storage path via tracing, and calls listener::run to begin accepting connections (blocks until shutdown). The status subcommand loads the config and prints a summary of all settings plus a connectivity check by attempting a brief TCP connection to the configured port, reporting whether the server appears to be running. Logging is configured via tracing-subscriber with an env-filter defaulting to pwr_server=info, controllable via the RUST_LOG environment variable. The –foreground flag on the start subcommand is accepted but daemonization is not yet implemented. Fix two compilation errors discovered during integration. The listener’s TLS setup incorrectly pattern-matched rustls::StreamOwned::new as if it returned a Result; it returns the stream directly in rustls 0.23. The handler’s handle_archive_finish had a borrow conflict where the session reference from the Archiving state match arm prevented reassigning *state; the fix extracts project_uuid and project_name into local variables before the state transition."}, {"post_id": 24827, "ts": "2026-07-08T17:13:43Z", "hours": 2.0, "text": "Add comprehensive crypto integration test suite with 26 tests Introduce crypto_integration.rs exercising the full security subsystem across four categories. PSK tests (8) verify 256-bit key generation across ten iterations, hex round-trip preservation including case insensitivity, rejection of odd-length and wrong-length hex strings, deterministic client proof computation, the complete mutual authentication flow with distinct client and server proofs, and PSK binding where different keys produce different proofs. Age encryption tests (6) cover small, empty, and 1 MB large payload round-trips, ephemeral key non-determinism (same plaintext produces different ciphertext but both decrypt correctly), wrong identity rejection, and corrupted ciphertext detection via single-byte flipping mid-payload. HKDF tests (4) verify 256-bit output length, deterministic derivation for same PSK and UUID, cross-project key uniqueness for different UUIDs, and a known-UUID stability test confirming the derived key is neither all-zeros nor all-PSK-bytes. Integrity tests (3) confirm streaming hasher equivalence with oneshot hashing across 5 MB of 64 KB chunks, empty file hashing matching the well-known empty SHA-256 digest, and proper I/O error propagation for nonexistent files. Archive round-trip tests (3) create a multi-file project with README, two Rust sources, a design doc, and Cargo.toml, run through create_archive → extract_archive, verify all file contents match exactly and .project.toml is excluded. Hash verification rejection confirms wrong hashes prevent extraction. A progress callback test records all stage transitions during archive creation and verifies the final progress fraction reaches 1.0."}, {"post_id": 24701, "ts": "2026-07-08T13:51:58Z", "hours": 2.0, "text": "Add progress callback support to archive and extract pipelines Introduce progress reporting to the archive packaging and extraction functions through an optional callback parameter. The ProgressFn type is a boxed closure receiving an ArchiveStage enum and a fractional progress value from 0.0 to 1.0. Eight stages cover the full lifecycle: Scanning, Tarring, Compressing, Encrypting, Hashing, Decrypting, Decompressing, and Extracting. The original create_archive and extract_archive signatures are preserved as convenience wrappers that call the new create_archive_with_progress and extract_archive_with_progress variants with None for the callback, maintaining backward compatibility for callers that do not need progress reporting. Progress granularity is coarse but meaningful: the archive pipeline reports six transitions (Scanning at 0.0, Tarring at 0.1, Compressing at 0.3, Encrypting at 0.5, Hashing at 0.9 and 1.0). The extract pipeline reports eight transitions (Hashing at 0.0 and 0.2, Decrypting at 0.3 and 0.5, Decompressing at 0.6, Extracting at 0.7 and 1.0). Future refinements could report per-file progress during the tar stage by tracking bytes written against the pre-computed directory size."}, {"post_id": 24514, "ts": "2026-07-08T03:32:17Z", "hours": 2.0, "text": "Add HKDF-SHA256 per-project key derivation from master PSK Implement derive_project_key in the crypto module using ring’s HKDF implementation with SHA-256. The function takes the 256-bit master PSK as the HKDF salt and the project UUID bytes as the info parameter, producing a deterministic 256-bit per-project key. This design means per-project encryption keys are never stored on disk — they are re-derived from the master PSK and project UUID on each archive or restore operation. If the PSK is rotated, all existing projects become inaccessible, which is documented as a deliberate security property rather than a bug. The HKDF-Extract step uses the PSK as the salt with an empty initial key material, producing a pseudorandom key. HKDF-Expand then derives 32 bytes of output key material bound to the project UUID via the info parameter, preventing cross-project key reuse even if an attacker learns one project’s derived key. Four tests verify deterministic derivation, UUID binding, PSK binding, and correct 256-bit output length."}, {"post_id": 24448, "ts": "2026-07-08T00:35:04Z", "hours": 1.9667, "text": "Implement complete integrity verification module with streaming hasher Replace the stub hash_file function with a full implementation that reads files in 64 KiB chunks through std::io::copy into a SHA-256 hasher, avoiding memory pressure for arbitrarily large inputs. Add hash_bytes_raw for callers that need the 32-byte binary digest rather than a hex string. hash_reader accepts any io::Read source, enabling hash computation on network streams or in-memory buffers without materializing intermediate files. Introduce StreamingHasher for incremental hash computation across multiple update calls. This is designed for chunked network reception where the full data is never in memory at once: the receiver calls update on each chunk as it arrives, then finalize or finalize_raw to obtain the digest. The struct wraps sha2::Sha256 and implements Default. Verification helpers verify_hash and verify_file_hash compare computed hashes against expected hex strings, returning bool rather than Result for use in assert-style checks. The crypto module’s sha256_hex and sha256_file functions are updated to delegate to the integrity module, making it the single canonical location for SHA-256 operations. Ten tests cover known-answer vectors for the empty string and ‘hello world’, raw hash byte length, file hashing including a 10 MB large-file path to exercise chunked I/O, hash verification for both match and mismatch cases, file verification, streaming hasher correctness against a known answer, streaming-vs-oneshot equivalence across four chunks, and hash_reader with an in-memory source."}, {"post_id": 24339, "ts": "2026-07-07T20:58:46Z", "hours": 2.0, "text": "Add comprehensive protocol integration test suite Introduce 20 integration tests in pwr-core/tests/protocol_integration.rs that exercise the full protocol layer without network dependencies, operating entirely on in-memory frame buffers and byte streams. Frame encode/decode round-trips validate that ArchiveRequest, RestoreRequest, and Handshake messages survive serialization through the full pipeline: typed ClientMessage enum to JSON payload to framed bytes with magic and length prefix through decode_frame back to typed enum with correct field values. FrameDecoder buffering tests cover two edge cases: byte-by-byte arrival where the decoder correctly reports None for incomplete frames across dozens of individual push_bytes calls until the full frame is available, and multi-frame reads where two concatenated frames in a single buffer are decoded sequentially without leftover bytes. Error injection tests verify that bad magic bytes produce errors, truncated frame headers (fewer than 10 bytes) return None rather than errors, payloads exceeding the 16 MiB limit are rejected, unsupported protocol versions are detected, and unknown message type bytes trigger framing errors. File chunk streaming tests cover exact 1 MiB chunks, zero-length data (which is indistinguishable from the EOF marker by design since empty chunks serve no purpose), EOF detection, and reassembly of 500 KB of cyclical data across 4 KB chunks with content verification. Serialization coverage iterates over all five ClientMessage variants and all seven ServerMessage variants, verifying each round-trips through JSON and preserves its message_type discriminant. Boundary tests handle empty ProjectInfo lists, near-max-size payloads with u64::MAX size_bytes and u32::MAX file_count, and direction-mismatch rejection where decode_client_message and decode_server_message refuse payloads from the wrong direction."}, {"post_id": 24259, "ts": "2026-07-07T18:26:22Z", "hours": 2.0, "text": "Refactor client to use typed ClientMessage/ServerMessage enums and protocol builders Replace raw struct construction and manual frame encoding in the archive, restore, and status methods with protocol builder functions and typed message enums. archive_project now calls protocol::build_archive_request and protocol::build_archive_complete. restore_project uses protocol::build_restore_request. The send_client_msg and recv_server_msg helpers replace the generic send_frame and recv_frame functions, providing type-safe serialization for ClientMessage enums and typed deserialization via protocol::decode_server_message for ServerMessage responses. The handshake function is updated to construct the Handshake message as a ClientMessage::Handshake variant and match the response as a ServerMessage::HandshakeAck variant, with error handling for ServerMessage::Error responses. Response parsing in all methods uses match on ServerMessage variants instead of serde_json::from_slice with unwrapped payloads, catching unexpected message types at the call site rather than failing silently with deserialization errors. The import list is reduced from a wildcard protocol::* to explicit imports for ClientMessage, Handshake, ProjectInfo, ServerMessage, and the protocol module itself for builder function access."}, {"post_id": 24168, "ts": "2026-07-07T15:49:02Z", "hours": 2.0, "text": "Refactor server handler to use ClientMessage/ServerMessage enums and protocol builders Rewrite the connection handler’s dispatch function to decode raw frame payloads through protocol::decode_client_message, which returns a typed ClientMessage enum. The match statement now patterns on the enum variant directly rather than matching MessageType discriminants and manually deserializing individual structs. This eliminates redundant deserialization code and catches direction mismatches at the protocol boundary. All server response construction now uses the protocol builder functions: build_handshake_ack_success, build_handshake_ack_failed, build_archive_accept, build_restore_accept, build_status_response, and build_error. The send_server_msg helper takes a ServerMessage enum, calls message_type() for the frame header discriminant, and serializes through encode_frame. This replaces scattered struct literal construction and manual frame encoding with a single call site. The handler functions (handle_handshake, handle_archive_start, handle_archive_finish, handle_restore_start, handle_status) are unchanged in logic but now operate on the inner payload structs extracted by the dispatch layer. Storage locking uses scoped blocks with read().unwrap() and write().unwrap() guards that drop before the next operation. Unused imports are cleaned up, including the removal of the deprecated ring::constant_time import."}, {"post_id": 24104, "ts": "2026-07-07T13:45:46Z", "hours": 2.0, "text": "Add typed builder functions for all protocol message flows Introduce convenience constructors in the protocol module that build ClientMessage and ServerMessage enums from their constituent fields, eliminating the need for callers to construct nested struct literals. For the archive flow, build_archive_request accepts a UUID, name, size, file count, and compression flag, while build_archive_complete and build_archive_failed produce the terminal ArchiveComplete variants. For the restore flow, build_restore_request wraps a project UUID, build_restore_accept bundles session metadata with size and hash, build_restore_complete signals success, and build_restore_failed attaches an error string. Handshake builders handle both success and failure Ack messages with the server nonce, proof, and optional reason. Additional helpers cover ArchiveAccept, StatusResponse, and generic Error messages. These builders centralize protocol message construction so handler and client code does not repeat struct literals and reduces the surface area for missing required fields."}, {"post_id": 23954, "ts": "2026-07-07T05:15:09Z", "hours": 2.0, "text": "Add ClientMessage and ServerMessage sum types with typed deserialization dispatch Introduce two unified enums to the protocol module that wrap all message variants for type-safe routing in the connection handler state machine. ClientMessage covers the five messages the client can send (Handshake, ArchiveRequest, ArchiveComplete, RestoreRequest, StatusRequest) and ServerMessage covers the six server responses (HandshakeAck, ArchiveAccept, RestoreAccept, RestoreComplete, StatusResponse, Error). Each variant delegates serialization to the inner struct via serde’s internally-tagged enum representation using a ‘type’ discriminator field. The message_type method on each enum maps variants to their MessageType discriminant byte, enabling the frame encoder to write the correct header without the caller tracking the mapping manually. Two deserialization functions, decode_client_message and decode_server_message, take a raw payload and a MessageType discriminant and return the typed enum. They validate that the discriminant matches the expected direction, rejecting client message types when a server message is expected and vice versa, catching protocol-level dispatch bugs at the decoding layer rather than deeper in handler logic. The MessageType enum is relocated from the frame module to the protocol module since it is a protocol concern, resolving a circular import between the two modules. Frame encoding continues to reference MessageType for the frame header type byte. The from_byte constructor maps all 13 assigned discriminants with explicit match arms for stability. Eight new tests cover ClientMessage and ServerMessage JSON round-trips, direction-mismatch rejection in decode_client_message and decode_server_message, and message_type discriminant mapping for both enums, adding to the existing serialization and discriminant tests."}, {"post_id": 23872, "ts": "2026-07-07T02:13:05Z", "hours": 2.0, "text": "Add comprehensive README with architecture overview, security model, and setup guides Document the complete pwr project covering the three-crate architecture, security model with its three layers (TLS transport, PSK authentication, and age at-rest encryption), quick-start guides for both Debian 12 server and Arch Linux client, the .project.toml file format specification, complete command reference table, configuration file reference for both client and server TOML files, and build-from-source instructions with feature flags for the optional TUI."}, {"post_id": 23820, "ts": "2026-07-06T23:56:22Z", "hours": 2.0, "text": "Add TLS certificate generation and server initialization utility Implement a certificate generation module in pwr-server that produces self-signed ECDSA P-256 certificates for TLS 1.3 via the rcgen crate. generate_certificate accepts a common name (typically the server hostname), creates certificate parameters with a distinguished name, generates a P-256 keypair, self-signs the certificate with a 365-day validity, and returns the PEM-encoded certificate, PEM-encoded private key, and a SHA-256 hex fingerprint of the certificate for client-side pinning. save_certificate writes the certificate and key to the configured paths with appropriate permissions: the certificate file is world-readable while the private key is restricted to owner-only (mode 0o600 on Unix). Parent directories are created automatically. The init_server function ties everything together for first-time setup. It generates the TLS certificate and key, saves them to /etc/pwr/, generates a random 256-bit PSK via ring’s CSPRNG, creates a ServerConfig with the PSK and certificate paths, and saves the config to /etc/pwr/server.toml. The PSK hex string and certificate fingerprint are printed to stdout with instructions for copying the PSK to the client config. This gives administrators a single command to bootstrap a new pwr-server instance with all security material generated fresh and properly permissioned."}, {"post_id": 23698, "ts": "2026-07-06T20:10:17Z", "hours": 2.0, "text": "Add ratatui-based TUI with project browser, creator, and log viewer screens Implement a terminal UI for interactive project management using ratatui 0.28 with the crossterm backend. The application shell provides a tabbed interface with three screens accessible via number keys (1-3) or Tab cycling. A status bar at the bottom displays global keybindings. The Project List screen renders a scrollable table of tracked projects discovered by scanning the local root directory for .project.toml files. Each row displays a color-coded status indicator (green for local, yellow for archived), project name, human-readable size, and last-sync date. Vim-style j/k and arrow key navigation is supported. Pressing r refreshes the list from disk. The screen is empty with an appropriate message when no projects are configured. The Project Creator screen provides a two-field form for interactively creating .project.toml files. The name field is pre-filled from the current directory name. Tab and Shift+Tab cycle focus between name and local path fields. Typing appends characters, backspace deletes. Ctrl+S validates that the path exists and is a directory, that the name is non-empty, then writes the .project.toml via the core library’s atomic write function. Status messages appear on success or validation failure. The Log Viewer screen reads the local JSONL transaction log and displays entries in a scrollable table with timestamp, operation type, project name, data size, and color-coded status (green OK, red FAILED, yellow in-progress). Supports refresh with r and j/k navigation. The TUI is enabled behind the tui Cargo feature flag which gates the ratatui and crossterm dependencies."}, {"post_id": 23620, "ts": "2026-07-06T18:02:51Z", "hours": 2.0, "text": "Implement full CLI command suite with shell integration and client networking"}, {"post_id": 23512, "ts": "2026-07-06T15:10:42Z", "hours": 2.0, "text": "Implement archive packaging pipeline and client networking module Add the archive packaging pipeline to pwr-core. The create_archive function builds an encrypted project archive through a four-stage streaming pipeline. First, the project directory is walked recursively and added to a tar archive via the tar crate, excluding .project.toml metadata files. Second, the tar stream is gzip-compressed using flate2 at default compression level and written to a temporary file to bound memory usage independent of project size. Third, the compressed tarball is read back and encrypted using the age X25519 public key from the project’s metadata, producing an opaque encrypted blob the server cannot read. Fourth, the SHA-256 hash of the encrypted blob is computed for integrity verification after transfer. Symlinks are preserved in the archive. The reverse pipeline, extract_archive, first verifies the SHA-256 hash against the expected value, then age-decrypts, gunzips, and untars into the target directory. Two tests verify create-extract round-trip fidelity (README.md, src/main.rs, and Cargo.toml are restored with correct content) and that hash mismatch prevents extraction. Add the protocol client module to the pwr binary. PwrClient manages a connection to pwr-server with TCP socket setup, configurable timeouts, PSK handshake authentication with mutual server proof verification, and framed message send/receive via the core frame module. The archive_project method sends an ArchiveRequest, receives acceptance, streams archive data in 1 MiB chunks with 4-byte length prefixes and a zero-length EOF marker, and sends ArchiveComplete with the SHA-256 hash. The restore_project method requests a project by UUID, receives a RestoreAccept with size metadata, streams chunks back from the server, and returns the complete encrypted blob. get_status queries the server for project listings with optional UUID filtering. The handshake helper generates a 32-byte CSPRNG nonce, computes the HMAC-SHA256 client proof, sends the Handshake message, verifies the server’s HandshakeAck success flag, and performs mutual authentication by validating the server proof against the expected value using constant-time comparison."}, {"post_id": 23258, "ts": "2026-07-06T03:13:55Z", "hours": 2.0, "text": "Implement pwr-server storage backend, connection handler, and TLS listener Add the three core server modules that together form the NAS-side daemon. The storage module (storage.rs) manages an on-disk project registry as a JSON index file mapping UUIDs to StoredProject entries containing name, size, file count, encryption flag, and timestamps. The registry is persisted atomically using a write-to-temp-then-rename pattern. Per-project directories under the configured storage base path hold data.enc (the encrypted archive blob) and meta.toml (per-project metadata). Methods provide CRUD operations on the registry, streaming archive read/write through buffered I/O, storage limit enforcement against the configured max_project_size_gb, and filesystem directory management. Five tests verify create-and-list, duplicate rejection, remove, archive write-read round-trip, and registry persistence across re-opens. The handler module (handler.rs) implements a per-connection state machine with five states: AwaitingHandshake, Authenticated, Archiving, Restoring, and Closed. The dispatch function routes decoded frames by state and message type. The handshake handler validates the client’s HMAC-SHA256 proof in constant time using ring::constant_time::verify_slices_are_equal, then generates a server nonce and server proof for mutual authentication. Archive start creates a project entry after checking the storage limit, archive finish updates the final size or rolls back on failure. Restore start looks up the project and verifies the archive file exists. Status queries support both single-UUID lookup and full listing. Storage is shared across connections via Arc<RwLock> with per-operation read or write locking. The listener module (listener.rs) loads PEM-encoded TLS certificates via rustls-pemfile, builds a rustls ServerConfig with TLS 1.3 and the application-level protocol negotiation tag “pwr/1”, binds a std::net TcpListener, and spawns each accepted connection on a dedicated OS thread with a rustls::StreamOwned wrapping the TCP stream for TLS encryption."}, {"post_id": 23204, "ts": "2026-07-06T00:55:44Z", "hours": 2.0, "text": "Implement cryptographic layer with PSK authentication, age encryption, and SHA-256 integrity Add the complete cryptographic subsystem to pwr-core, providing three layers of security for the protocol. The pre-shared key authentication layer uses HMAC-SHA256 to compute challenge-response proofs. The client proves knowledge of the PSK by sending HMAC(client_nonce || “pwr-auth-v1”, PSK). The server responds with HMAC(client_nonce || server_nonce || “pwr-auth-v1”, PSK), enabling mutual authentication. Both nonces are 32-byte CSPRNG values generated per-connection using ring’s SystemRandom. The PSK itself is a 256-bit random key stored as a hex string in both config files. Helper functions handle hex encoding and decoding. At-rest encryption uses age with X25519 key pairs. generate_age_identity creates a fresh keypair, stores the secret identity at ~/.config/pwr/identity with 0o600 permissions, and returns the Bech32 public key for inclusion in .project.toml. The age_encrypt function takes a public key string and plaintext, producing an age-format encrypted blob using the one-shot Encryptor API. age_decrypt reverses this with an identity, returning the original plaintext. Both functions propagate structured errors for wrong keys, corrupted data, and unsupported formats. Integrity verification uses SHA-256 via the sha2 crate. sha256_hex hashes an in-memory buffer. sha256_file streams through a file in 64 KiB chunks to support large projects without memory pressure. Ten tests verify PSK randomness and hex round-trips, deterministic proof computation (same inputs produce same outputs), mutual proof divergence (client and server proofs differ), age encrypt-decrypt round-trips for both empty and non-empty payloads, wrong-identity rejection, known-answer SHA-256 vectors, and file hashing against the same known answer."}, {"post_id": 23125, "ts": "2026-07-05T21:58:39Z", "hours": 2.0, "text": "Implement wire protocol message types and frame encoding layer Define the complete set of protocol messages shared between client and server in pwr-core. The MessageType enum assigns stable 1-byte discriminants to each message variant for routing in the frame header. Handshake messages carry 32-byte client and server nonces with HMAC-SHA256 proofs for mutual PSK authentication, plus a server version string and optional error reason for debugging failed handshakes. Archive flow messages coordinate project uploads: ArchiveRequest announces the project UUID, name, total size, file count, and compression flag; ArchiveAccept returns a session UUID for correlating subsequent chunks; ArchiveComplete reports the final SHA-256 hash and transfer size. Restore flow mirrors this with RestoreRequest, RestoreAccept (carrying size and hash so the client can pre-allocate), and RestoreComplete. File streaming uses FileHeader (relative path, size, Unix mode bits) sent before raw chunk data and FileEnd (SHA-256 checksum) sent after. Query messages provide StatusRequest with optional project UUID filter and StatusResponse with a ProjectInfo vector carrying UUID, name, size, file count, and timestamps. The frame module implements a 10-byte header format: 4 magic bytes (0x50575246, ASCII “PWRF”), 4-byte big-endian payload length, 1-byte protocol version, and 1-byte message type. Payloads are JSON-encoded for debuggability. encode_frame serializes and wraps a message; decode_frame validates magic, version, and length bounds, returning None when more data is needed. FrameDecoder maintains an internal buffer for incremental socket reads. File chunks use a separate 4-byte length-prefixed streaming format with a zero-length EOF marker, keeping large file data out of the JSON framing layer. Thirteen tests cover message type discriminants, serialization round-trips for ArchiveRequest and ProjectInfo, handshake nonce sizes, frame encode-decode with magic verification, partial-read buffering in FrameDecoder, oversized frame rejection, bad magic rejection, file chunk encode-decode, and EOF marker detection."}, {"post_id": 23041, "ts": "2026-07-05T19:34:43Z", "hours": 2.0, "text": "Implement project file I/O with atomic writes, placeholder detection, and directory utilities Add the complete project file management layer in pwr-core. The .project.toml file is the stable identity marker that persists on local disk regardless of whether project content is present (Local state) or stored on the server (Archived state). read_project_file returns Option, returning None when no .project.toml exists so callers can distinguish untracked directories from tracked projects. write_project_file uses an atomic write-through pattern: contents are serialized to a .tmp sibling file first, then renamed over the target, preventing readers from observing a partially written metadata file. remove_project_file deletes the marker without touching directory contents. State detection predicates cover all cases needed by the CLI and shell wrapper. is_archived_placeholder confirms that a directory contains only a .project.toml whose state field is Archived — the signal that triggers automatic restore in the ensure command. is_local_project checks for the opposite state. is_tracked simply tests file existence without parsing. Directory utilities support the archive and restore workflows. dir_size computes total bytes excluding the metadata file itself, with symlinks counted by their target path length rather than followed. file_count tallies regular files recursively for transfer progress estimation. remove_dir_contents_except_project strips a directory down to its .project.toml placeholder after a successful archive. Eleven tests cover round-trip I/O, atomic write behavior, placeholder and local state detection, tracking predicate, exact byte counting, file enumeration, directory stripping, and recursive discovery."}, {"post_id": 22950, "ts": "2026-07-05T16:44:00Z", "hours": 2.0, "text": "Implement server-side configuration management with validation and storage layout Add the ServerConfig struct to the pwr-server crate, controlling all aspects of the daemon’s operation. The configuration specifies the TCP bind address and port (defaulting to 0.0.0.0:9742), the filesystem root for project storage (defaulting to /srv/pwr/projects), paths to the TLS certificate and private key files, the hex-encoded 256-bit pre-shared authentication token that clients must present during the handshake, and operational limits including maximum concurrent connections (default 32), maximum project size in gigabytes (default 500), and an idle timeout for authenticated connections (default 300 seconds). Validation is performed at load time: the port must be non-zero, the auth token must be non-empty, and both max_project_size_gb and max_connections must be positive. The validate method returns a plain String error so the caller can present it directly to the user without depending on the shared pwr-core error types, keeping the server crate’s dependency surface minimal during early development. A config file search strategy checks four locations in order: an explicit –config CLI path, the current working directory (for development), the XDG config directory under ~/.config/pwr/, and the system-wide /etc/pwr/server.toml. Helper methods compute derived paths: project_dir returns the per-UUID storage subdirectory, registry_path returns the JSON index file location, and bind_addr formats the socket address for TcpListener::bind. Seven tests cover default validation, empty-token rejection, zero-port rejection, bind address formatting, project directory path generation, registry path naming, and a full save-load round-trip through TOML serialization and deserialization."}, {"post_id": 22866, "ts": "2026-07-05T14:19:16Z", "hours": 2.7561, "text": "Add client configuration management with server connection settings Refactor the PwrConfig struct to support the protocol-based architecture by replacing rsync-oriented fields (NAS hostname, SSH user, rsync options) with connection parameters for the pwr-server daemon. The new fields are server_host for the NAS hostname or IP address, server_port defaulting to 9742, and server_psk storing a hex-encoded 256-bit pre-shared key for HMAC-SHA256 authentication during the TLS handshake. Certificate pinning is supported through an optional server_fingerprint field that stores the SHA-256 hash of the server’s self-signed X.509 certificate. When set, the client rejects connections where the server presents a certificate with a different fingerprint, preventing man-in-the-middle attacks even if an attacker obtains a valid CA-signed certificate for the server’s hostname. Timeout configuration separates connection establishment (default 10 seconds) from long-running transfers (default 300 seconds) so users can tune them independently. Path helpers provide the standard XDG config directory layout: config.toml for connection settings, identity for the age encryption keypair, and transactions.log for the JSONL audit trail. The config_exists predicate lets callers check for prior initialization without triggering the NoConfig error path. The load_config function maps TOML parse errors into the TomlParse variant carrying the file path for actionable error messages. A server_addr convenience method joins host and port for use with TcpStream::connect. Three tests verify address formatting, config path construction, and port default values."}, {"post_id": 22680, "ts": "2026-07-05T07:23:29Z", "hours": 4.3908, "text": "The error module in pwr-core defines PwrError as a comprehensive thiserror enum covering I/O failures, TOML and bincode serialization errors, protocol framing violations, cryptographic operation failures, authentication rejections, network connectivity issues, storage-layer problems like missing or corrupted projects, and timeouts. Each variant carries contextual information: the TOML parse error includes the file path, protocol errors carry descriptive strings, and storage errors distinguish between not-found, already-exists, and corrupted states. Client configuration (PwrConfig) is rewritten with fields for server hostname, port, hex-encoded pre-shared key, optional TLS certificate fingerprint for pinning, local project root path, and configurable connect and transfer timeouts. The old rsync-oriented fields (NAS host, SSH user, rsync options) are removed. Server configuration is deferred to the pwr-server crate for a later commit. Stub modules for protocol message types, frame encoding, cryptographic key management, archive packaging, and integrity verification are placed in pwr-core so subsequent commits can fill them in without structural changes. Both binaries compile as minimal stubs printing their version. Ten tests pass covering config serialization, metadata state transitions, project file round-trips, transaction log JSONL format, and SHA-256 hash verification of known inputs."}]...
|
Title: Psync by @jacobjuneau | Stardance
Devlogs: Title: Psync by @jacobjuneau | Stardance
Devlogs:
The error module in pwr-core defines PwrError as a comprehensive thiserror enum covering I/O failures, TOML and bincode serialization errors, protocol framing violations, cryptographic operation failures, authentication rejections, network connectivity issues, storage-layer problems like missing or corrupted projects, and timeouts. Each variant carries contextual information: the TOML parse error includes the file path, protocol errors carry descriptive strings, and storage errors distinguish between not-found, already-exists, and corrupted states. Client configuration (PwrConfig) is rewritten with fields for server hostname, port, hex-encoded pre-shared key, optional TLS certificate fingerprint for pinning, local project root path, and configurable connect and transfer timeouts. The old rsync-oriented fields (NAS host, SSH user, rsync options) are removed. Server configuration is deferred to the pwr-server crate for a later commit. Stub modules for protocol message types, frame encoding, cryptographic key management, archive packaging, and integrity verification are placed in pwr-core so subsequent commits can fill them in without structural changes. Both binaries compile as minimal stubs printing their version. Ten tests pass covering config serialization, metadata state transitions, project file round-trips, transaction log JSONL format, and SHA-256 hash verification of known inputs.
Add client configuration management with server connection settings Refactor the PwrConfig struct to support the protocol-based architecture by replacing rsync-oriented fields (NAS hostname, SSH user, rsync options) with connection parameters for the pwr-server daemon. The new fields are server_host for the NAS hostname or IP address, server_port defaulting to 9742, and server_psk storing a hex-encoded 256-bit pre-shared key for HMAC-SHA256 authentication during the TLS handshake. Certificate pinning is supported through an optional server_fingerprint field that stores the SHA-256 hash of the server’s self-signed X.509 certificate. When set, the client rejects connections where the server presents a certificate with a different fingerprint, preventing man-in-the-middle attacks even if an attacker obtains a valid CA-signed certificate for the server’s hostname. Timeout configuration separates connection establishment (default 10 seconds) from long-running transfers (default 300 seconds) so users can tune them independently. Path helpers provide the standard XDG config directory layout: config.toml for connection settings, identity for the age encryption keypair, and transactions.log for the JSONL audit trail. The config_exists predicate lets callers check for prior initialization without triggering the NoConfig error path. The load_config function maps TOML parse errors into the TomlParse variant carrying the file path for actionable error messages. A server_addr convenience method joins host and port for use with TcpStream::connect. Three tests verify address formatting, config path construction, and port default values.
Implement server-side configuration management with validation and storage layout Add the ServerConfig struct to the pwr-server crate, controlling all aspects of the daemon’s operation. The configuration specifies the TCP bind address and port (defaulting to 0.0.0.0:9742), the filesystem root for project storage (defaulting to /srv/pwr/projects), paths to the TLS certificate and private key files, the hex-encoded 256-bit pre-shared authentication token that clients must present during the handshake, and operational limits including maximum concurrent connections (default 32), maximum project size in gigabytes (default 500), and an idle timeout for authenticated connections (default 300 seconds). Validation is performed at load time: the port must be non-zero, the auth token must be non-empty, and both max_project_size_gb and max_connections must be positive. The validate method returns a plain String error so the caller can present it directly to the user without depending on the shared pwr-core error types, keeping the server crate’s dependency surface minimal during early development. A config file search strategy checks four locations in order: an explicit –config CLI path, the current working directory (for development), the XDG config directory under ~/.config/pwr/, and the system-wide /etc/pwr/server.toml. Helper methods compute derived paths: project_dir returns the per-UUID storage subdirectory, registry_path returns the JSON index file location, and bind_addr formats the socket address for TcpListener::bind. Seven tests cover default validation, empty-token rejection, zero-port rejection, bind address formatting, project directory path generation, registry path naming, and a full save-load round-trip through TOML serialization and deserialization.
Implement project file I/O with atomic writes, placeholder detection, and directory utilities Add the complete project file management layer in pwr-core. The .project.toml file is the stable identity marker that persists on local disk regardless of whether project content is present (Local state) or stored on the server (Archived state). read_project_file returns Option, returning None when no .project.toml exists so callers can distinguish untracked directories from tracked projects. write_project_file uses an atomic write-through pattern: contents are serialized to a .tmp sibling file first, then renamed over the target, preventing readers from observing a partially written metadata file. remove_project_file deletes the marker without touching directory contents. State detection predicates cover all cases needed by the CLI and shell wrapper. is_archived_placeholder confirms that a directory contains only a .project.toml whose state field is Archived — the signal that triggers automatic restore in the ensure command. is_local_project checks for the opposite state. is_tracked simply tests file existence without parsing. Directory utilities support the archive and restore workflows. dir_size computes total bytes excluding the metadata file itself, with symlinks counted by their target path length rather than followed. file_count tallies regular files recursively for transfer progress estimation. remove_dir_contents_except_project strips a directory down to its .project.toml placeholder after a successful archive. Eleven tests cover round-trip I/O, atomic write behavior, placeholder and local state detection, tracking predicate, exact byte counting, file enumeration, directory stripping, and recursive discovery.
Implement wire protocol message types and frame encoding layer Define the complete set of protocol messages shared between client and server in pwr-core. The MessageType enum assigns stable 1-byte discriminants to each message variant for routing in the frame header. Handshake messages carry 32-byte client and server nonces with HMAC-SHA256 proofs for mutual PSK authentication, plus a server version string and optional error reason for debugging failed handshakes. Archive flow messages coordinate project uploads: ArchiveRequest announces the project UUID, name, total size, file count, and compression flag; ArchiveAccept returns a session UUID for correlating subsequent chunks; ArchiveComplete reports the final SHA-256 hash and transfer size. Restore flow mirrors this with RestoreRequest, RestoreAccept (carrying size and hash so the client can pre-allocate), and RestoreComplete. File streaming uses FileHeader (relative path, size, Unix mode bits) sent before raw chunk data and FileEnd (SHA-256 checksum) sent after. Query messages provide StatusRequest with optional project UUID filter and StatusResponse with a ProjectInfo vector carrying UUID, name, size, file count, and timestamps. The frame module implements a 10-byte header format: 4 magic bytes (0x50575246, ASCII “PWRF”), 4-byte big-endian payload length, 1-byte protocol version, and 1-byte message type. Payloads are JSON-encoded for debuggability. encode_frame serializes and wraps a message; decode_frame validates magic, version, and length bounds, returning None when more data is needed. FrameDecoder maintains an internal buffer for incremental socket reads. File chunks use a separate 4-byte length-prefixed streaming format with a zero-length EOF marker, keeping large file data out of the JSON framing layer. Thirteen tests cover message type discriminants, serialization round-trips for ArchiveRequest and ProjectInfo, handshake nonce sizes, frame encode-decode with magic verification, partial-read buffering in FrameDecoder, oversized frame rejection, bad magic rejection, file chunk encode-decode, and EOF marker detection.
Implement cryptographic layer with PSK authentication, age encryption, and SHA-256 integrity Add the complete cryptographic subsystem to pwr-core, providing three layers of security for the protocol. The pre-shared key authentication layer uses HMAC-SHA256 to compute challenge-response proofs. The client proves knowledge of the PSK by sending HMAC(client_nonce || “pwr-auth-v1”, PSK). The server responds with HMAC(client_nonce || server_nonce || “pwr-auth-v1”, PSK), enabling mutual authentication. Both nonces are 32-byte CSPRNG values generated per-connection using ring’s SystemRandom. The PSK itself is a 256-bit random key stored as a hex string in both config files. Helper functions handle hex encoding and decoding. At-rest encryption uses age with X25519 key pairs. generate_age_identity creates a fresh keypair, stores the secret identity at ~/.config/pwr/identity with 0o600 permissions, and returns the Bech32 public key for inclusion in .project.toml. The age_encrypt function takes a public key string and plaintext, producing an age-format encrypted blob using the one-shot Encryptor API. age_decrypt reverses this with an identity, returning the original plaintext. Both functions propagate structured errors for wrong keys, corrupted data, and unsupported formats. Integrity verification uses SHA-256 via the sha2 crate. sha256_hex hashes an in-memory buffer. sha256_file streams through a file in 64 KiB chunks to support large projects without memory pressure. Ten tests verify PSK randomness and hex round-trips, deterministic proof computation (same inputs produce same outputs), mutual proof divergence (client and server proofs differ), age encrypt-decrypt round-trips for both empty and non-empty payloads, wrong-identity rejection, known-answer SHA-256 vectors, and file hashing against the same known answer.
Implement pwr-server storage backend, connection handler, and TLS listener Add the three core server modules that together form the NAS-side daemon. The storage module (storage.rs) manages an on-disk project registry as a JSON index file mapping UUIDs to StoredProject entries containing name, size, file count, encryption flag, and timestamps. The registry is persisted atomically using a write-to-temp-then-rename pattern. Per-project directories under the configured storage base path hold data.enc (the encrypted archive blob) and meta.toml (per-project metadata). Methods provide CRUD operations on the registry, streaming archive read/write through buffered I/O, storage limit enforcement against the configured max_project_size_gb, and filesystem directory management. Five tests verify create-and-list, duplicate rejection, remove, archive write-read round-trip, and registry persistence across re-opens. The handler module (handler.rs) implements a per-connection state machine with five states: AwaitingHandshake, Authenticated, Archiving, Restoring, and Closed. The dispatch function routes decoded frames by state and message type. The handshake handler validates the client’s HMAC-SHA256 proof in constant time using ring::constant_time::verify_slices_are_equal, then generates a server nonce and server proof for mutual authentication. Archive start creates a project entry after checking the storage limit, archive finish updates the final size or rolls back on failure. Restore start looks up the project and verifies the archive file exists. Status queries support both single-UUID lookup and full listing. Storage is shared across connections via Arc<RwLock> with per-operation read or write locking. The listener module (listener.rs) loads PEM-encoded TLS certificates via rustls-pemfile, builds a rustls ServerConfig with TLS 1.3 and the application-level protocol negotiation tag “pwr/1”, binds a std::net TcpListener, and spawns each accepted connection on a dedicated OS thread with a rustls::StreamOwned wrapping the TCP stream for TLS encryption.
Implement archive packaging pipeline and client networking module Add the archive packaging pipeline to pwr-core. The create_archive function builds an encrypted project archive through a four-stage streaming pipeline. First, the project directory is walked recursively and added to a tar archive via the tar crate, excluding .project.toml metadata files. Second, the tar stream is gzip-compressed using flate2 at default compression level and written to a temporary file to bound memory usage independent of project size. Third, the compressed tarball is read back and encrypted using the age X25519 public key from the project’s metadata, producing an opaque encrypted blob the server cannot read. Fourth, the SHA-256 hash of the encrypted blob is computed for integrity verification after transfer. Symlinks are preserved in the archive. The reverse pipeline, extract_archive, first verifies the SHA-256 hash against the expected value, then age-decrypts, gunzips, and untars into the target directory. Two tests verify create-extract round-trip fidelity (README.md, src/main.rs, and Cargo.toml are restored with correct content) and that hash mismatch prevents extraction. Add the protocol client module to the pwr binary. PwrClient manages a connection to pwr-server with TCP socket setup, configurable timeouts, PSK handshake authentication with mutual server proof verification, and framed message send/receive via the core frame module. The archive_project method sends an ArchiveRequest, receives acceptance, streams archive data in 1 MiB chunks with 4-byte length prefixes and a zero-length EOF marker, and sends ArchiveComplete with the SHA-256 hash. The restore_project method requests a project by UUID, receives a RestoreAccept with size metadata, streams chunks back from the server, and returns the complete encrypted blob. get_status queries the server for project listings with optional UUID filtering. The handshake helper generates a 32-byte CSPRNG nonce, computes the HMAC-SHA256 client proof, sends the Handshake message, verifies the server’s HandshakeAck success flag, and performs mutual authentication by validating the server proof against the expected value using constant-time comparison.
Implement full CLI command suite with shell integration and client networking
Add ratatui-based TUI with project browser, creator, and log viewer screens Implement a terminal UI for interactive project management using ratatui 0.28 with the crossterm backend. The application shell provides a tabbed interface with three screens accessible via number keys (1-3) or Tab cycling. A status bar at the bottom displays global keybindings. The Project List screen renders a scrollable table of tracked projects discovered by scanning the local root directory for .project.toml files. Each row displays a color-coded status indicator (green for local, yellow for archived), project name, human-readable size, and last-sync date. Vim-style j/k and arrow key navigation is supported. Pressing r refreshes the list from disk. The screen is empty with an appropriate message when no projects are configured. The Project Creator screen provides a two-field form for interactively creating .project.toml files. The name field is pre-filled from the current directory name. Tab and Shift+Tab cycle focus between name and local path fields. Typing appends characters, backspace deletes. Ctrl+S validates that the path exists and is a directory, that the name is non-empty, then writes the .project.toml via the core library’s atomic write function. Status messages appear on success or validation failure. The Log Viewer screen reads the local JSONL transaction log and displays entries in a scrollable table with timestamp, operation type, project name, data size, and color-coded status (green OK, red FAILED, yellow in-progress). Supports refresh with r and j/k navigation. The TUI is enabled behind the tui Cargo feature flag which gates the ratatui and crossterm dependencies.
Add TLS certificate generation and server initialization utility Implement a certificate generation module in pwr-server that produces self-signed ECDSA P-256 certificates for TLS 1.3 via the rcgen crate. generate_certificate accepts a common name (typically the server hostname), creates certificate parameters with a distinguished name, generates a P-256 keypair, self-signs the certificate with a 365-day validity, and returns the PEM-encoded certificate, PEM-encoded private key, and a SHA-256 hex fingerprint of the certificate for client-side pinning. save_certificate writes the certificate and key to the configured paths with appropriate permissions: the certificate file is world-readable while the private key is restricted to owner-only (mode 0o600 on Unix). Parent directories are created automatically. The init_server function ties everything together for first-time setup. It generates the TLS certificate and key, saves them to /etc/pwr/, generates a random 256-bit PSK via ring’s CSPRNG, creates a ServerConfig with the PSK and certificate paths, and saves the config to /etc/pwr/server.toml. The PSK hex string and certificate fingerprint are printed to stdout with instructions for copying the PSK to the client config. This gives administrators a single command to bootstrap a new pwr-server instance with all security material generated fresh and properly permissioned.
Add comprehensive README with architecture overview, security model, and setup guides Document the complete pwr project covering the three-crate architecture, security model with its three layers (TLS transport, PSK authentication, and age at-rest encryption), quick-start guides for both Debian 12 server and Arch Linux client, the .project.toml file format specification, complete command reference table, configuration file reference for both client and server TOML files, and build-from-source instructions with feature flags for the optional TUI.
Add ClientMessage and ServerMessage sum types with typed deserialization dispatch Introduce two unified enums to the protocol module that wrap all message variants for type-safe routing in the connection handler state machine. ClientMessage covers the five messages the client can send (Handshake, ArchiveRequest, ArchiveComplete, RestoreRequest, StatusRequest) and ServerMessage covers the six server responses (HandshakeAck, ArchiveAccept, RestoreAccept, RestoreComplete, StatusResponse, Error). Each variant delegates serialization to the inner struct via serde’s internally-tagged enum representation using a ‘type’ discriminator field. The message_type method on each enum maps variants to their MessageType discriminant byte, enabling the frame encoder to write the correct header without the caller tracking the mapping manually. Two deserialization functions, decode_client_message and decode_server_message, take a raw payload and a MessageType discriminant and return the typed enum. They validate that the discriminant matches the expected direction, rejecting client message types when a server message is expected and vice versa, catching protocol-level dispatch bugs at the decoding layer rather than deeper in handler logic. The MessageType enum is relocated from the frame module to the protocol module since it is a protocol concern, resolving a circular import between the two modules. Frame encoding continues to reference MessageType for the frame header type byte. The from_byte constructor maps all 13 assigned discriminants with explicit match arms for stability. Eight new tests cover ClientMessage and ServerMessage JSON round-trips, direction-mismatch rejection in decode_client_message and decode_server_message, and message_type discriminant mapping for both enums, adding to the existing serialization and discriminant tests.
Add typed builder functions for all protocol message flows Introduce convenience constructors in the protocol module that build ClientMessage and ServerMessage enums from their constituent fields, eliminating the need for callers to construct nested struct literals. For the archive flow, build_archive_request accepts a UUID, name, size, file count, and compression flag, while build_archive_complete and build_archive_failed produce the terminal ArchiveComplete variants. For the restore flow, build_restore_request wraps a project UUID, build_restore_accept bundles session metadata with size and hash, build_restore_complete signals success, and build_restore_failed attaches an error string. Handshake builders handle both success and failure Ack messages with the server nonce, proof, and optional reason. Additional helpers cover ArchiveAccept, StatusResponse, and generic Error messages. These builders centralize protocol message construction so handler and client code does not repeat struct literals and reduces the surface area for missing required fields.
Refactor server handler to use ClientMessage/ServerMessage enums and protocol builders Rewrite the connection handler’s dispatch function to decode raw frame payloads through protocol::decode_client_message, which returns a typed ClientMessage enum. The match statement now patterns on the enum variant directly rather than matching MessageType discriminants and manually deserializing individual structs. This eliminates redundant deserialization code and catches direction mismatches at the protocol boundary. All server response construction now uses the protocol builder functions: build_handshake_ack_success, build_handshake_ack_failed, build_archive_accept, build_restore_accept, build_status_response, and build_error. The send_server_msg helper takes a ServerMessage enum, calls message_type() for the frame header discriminant, and serializes through encode_frame. This replaces scattered struct literal construction and manual frame encoding with a single call site. The handler functions (handle_handshake, handle_archive_start, handle_archive_finish, handle_restore_start, handle_status) are unchanged in logic but now operate on the inner payload structs extracted by the dispatch layer. Storage locking uses scoped blocks with read().unwrap() and write().unwrap() guards that drop before the next operation. Unused imports are cleaned up, including the removal of the deprecated ring::constant_time import.
Refactor client to use typed ClientMessage/ServerMessage enums and protocol builders Replace raw struct construction and manual frame encoding in the archive, restore, and status methods with protocol builder functions and typed message enums. archive_project now calls protocol::build_archive_request and protocol::build_archive_complete. restore_project uses protocol::build_restore_request. The send_client_msg and recv_server_msg helpers replace the generic send_frame and recv_frame functions, providing type-safe serialization for ClientMessage enums and typed deserialization via protocol::decode_server_message for ServerMessage responses. The handshake function is updated to construct the Handshake message as a ClientMessage::Handshake variant and match the response as a ServerMessage::HandshakeAck variant, with error handling for ServerMessage::Error responses. Response parsing in all methods uses match on ServerMessage variants instead of serde_json::from_slice with unwrapped payloads, catching unexpected message types at the call site rather than failing silently with deserialization errors. The import list is reduced from a wildcard protocol::* to explicit imports for ClientMessage, Handshake, ProjectInfo, ServerMessage, and the protocol module itself for builder function access.
Add comprehensive protocol integration test suite Introduce 20 integration tests in pwr-core/tests/protocol_integration.rs that exercise the full protocol layer without network dependencies, operating entirely on in-memory frame buffers and byte streams. Frame encode/decode round-trips validate that ArchiveRequest, RestoreRequest, and Handshake messages survive serialization through the full pipeline: typed ClientMessage enum to JSON payload to framed bytes with magic and length prefix through decode_frame back to typed enum with correct field values. FrameDecoder buffering tests cover two edge cases: byte-by-byte arrival where the decoder correctly reports None for incomplete frames across dozens of individual push_bytes calls until the full frame is available, and multi-frame reads where two concatenated frames in a single buffer are decoded sequentially without leftover bytes. Error injection tests verify that bad magic bytes produce errors, truncated frame headers (fewer than 10 bytes) return None rather than errors, payloads exceeding the 16 MiB limit are rejected, unsupported protocol versions are detected, and unknown message type bytes trigger framing errors. File chunk streaming tests cover exact 1 MiB chunks, zero-length data (which is indistinguishable from the EOF marker by design since empty chunks serve no purpose), EOF detection, and reassembly of 500 KB of cyclical data across 4 KB chunks with content verification. Serialization coverage iterates over all five ClientMessage variants and all seven ServerMessage variants, verifying each round-trips through JSON and preserves its message_type discriminant. Boundary tests handle empty ProjectInfo lists, near-max-size payloads with u64::MAX size_bytes and u32::MAX file_count, and direction-mismatch rejection where decode_client_message and decode_server_message refuse payloads from the wrong direction.
Implement complete integrity verification module with streaming hasher Replace the stub hash_file function with a full implementation that reads files in 64 KiB chunks through std::io::copy into a SHA-256 hasher, avoiding memory pressure for arbitrarily large inputs. Add hash_bytes_raw for callers that need the 32-byte binary digest rather than a hex string. hash_reader accepts any io::Read source, enabling hash computation on network streams or in-memory buffers without materializing intermediate files. Introduce StreamingHasher for incremental hash computation across multiple update calls. This is designed for chunked network reception where the full data is never in memory at once: the receiver calls update on each chunk as it arrives, then finalize or finalize_raw to obtain the digest. The struct wraps sha2::Sha256 and implements Default. Verification helpers verify_hash and verify_file_hash compare computed hashes against expected hex strings, returning bool rather than Result for use in assert-style checks. The crypto module’s sha256_hex and sha256_file functions are updated to delegate to the integrity module, making it the single canonical location for SHA-256 operations. Ten tests cover known-answer vectors for the empty string and ‘hello world’, raw hash byte length, file hashing including a 10 MB large-file path to exercise chunked I/O, hash verification for both match and mismatch cases, file verification, streaming hasher correctness against a known answer, streaming-vs-oneshot equivalence across four chunks, and hash_reader with an in-memory source.
Add HKDF-SHA256 per-project key derivation from master PSK Implement derive_project_key in the crypto module using ring’s HKDF implementation with SHA-256. The function takes the 256-bit master PSK as the HKDF salt and the project UUID bytes as the info parameter, producing a deterministic 256-bit per-project key. This design means per-project encryption keys are never stored on disk — they are re-derived from the master PSK and project UUID on each archive or restore operation. If the PSK is rotated, all existing projects become inaccessible, which is documented as a deliberate security property rather than a bug. The HKDF-Extract step uses the PSK as the salt with an empty initial key material, producing a pseudorandom key. HKDF-Expand then derives 32 bytes of output key material bound to the project UUID via the info parameter, preventing cross-project key reuse even if an attacker learns one project’s derived key. Four tests verify deterministic derivation, UUID binding, PSK binding, and correct 256-bit output length.
Add progress callback support to archive and extract pipelines Introduce progress reporting to the archive packaging and extraction functions through an optional callback parameter. The ProgressFn type is a boxed closure receiving an ArchiveStage enum and a fractional progress value from 0.0 to 1.0. Eight stages cover the full lifecycle: Scanning, Tarring, Compressing, Encrypting, Hashing, Decrypting, Decompressing, and Extracting. The original create_archive and extract_archive signatures are preserved as convenience wrappers that call the new create_archive_with_progress and extract_archive_with_progress variants with None for the callback, maintaining backward compatibility for callers that do not need progress reporting. Progress granularity is coarse but meaningful: the archive pipeline reports six transitions (Scanning at 0.0, Tarring at 0.1, Compressing at 0.3, Encrypting at 0.5, Hashing at 0.9 and 1.0). The extract pipeline reports eight transitions (Hashing at 0.0 and 0.2, Decrypting at 0.3 and 0.5, Decompressing at 0.6, Extracting at 0.7 and 1.0). Future refinements could report per-file progress during the tar stage by tracking bytes written against the pre-computed directory size.
Add comprehensive crypto integration test suite with 26 tests Introduce crypto_integration.rs exercising the full security subsystem across four categories. PSK tests (8) verify 256-bit key generation across ten iterations, hex round-trip preservation including case insensitivity, rejection of odd-length and wrong-length hex strings, deterministic client proof computation, the complete mutual authentication flow with distinct client and server proofs, and PSK binding where different keys produce different proofs. Age encryption tests (6) cover small, empty, and 1 MB large payload round-trips, ephemeral key non-determinism (same plaintext produces different ciphertext but both decrypt correctly), wrong identity rejection, and corrupted ciphertext detection via single-byte flipping mid-payload. HKDF tests (4) verify 256-bit output length, deterministic derivation for same PSK and UUID, cross-project key uniqueness for different UUIDs, and a known-UUID stability test confirming the derived key is neither all-zeros nor all-PSK-bytes. Integrity tests (3) confirm streaming hasher equivalence with oneshot hashing across 5 MB of 64 KB chunks, empty file hashing matching the well-known empty SHA-256 digest, and proper I/O error propagation for nonexistent files. Archive round-trip tests (3) create a multi-file project with README, two Rust sources, a design doc, and Cargo.toml, run through create_archive → extract_archive, verify all file contents match exactly and .project.toml is excluded. Hash verification rejection confirms wrong hashes prevent extraction. A progress callback test records all stage transitions during archive creation and verifies the final progress fraction reaches 1.0.
Implement server main entry point with clap CLI and fix listener/handler compilation Add a complete main.rs for pwr-server with three clap subcommands. The init subcommand detects or accepts a hostname, delegates to cert::init_server for TLS certificate generation, PSK creation, and config file writing, then prints the start command. The start subcommand locates the config file via the standard search path, loads and validates the ServerConfig, logs the bind address and storage path via tracing, and calls listener::run to begin accepting connections (blocks until shutdown). The status subcommand loads the config and prints a summary of all settings plus a connectivity check by attempting a brief TCP connection to the configured port, reporting whether the server appears to be running. Logging is configured via tracing-subscriber with an env-filter defaulting to pwr_server=info, controllable via the RUST_LOG environment variable. The –foreground flag on the start subcommand is accepted but daemonization is not yet implemented. Fix two compilation errors discovered during integration. The listener’s TLS setup incorrectly pattern-matched rustls::StreamOwned::new as if it returned a Result; it returns the stream directly in rustls 0.23. The handler’s handle_archive_finish had a borrow conflict where the session reference from the Archiving state match arm prevented reassigning *state; the fix extracts project_uuid and project_name into local variables before the state transition.
Add IP-based authentication rate limiter and integrate into handshake handler Implement a per-IP rate limiter in the server’s auth module that tracks failed authentication attempts within a sliding 60-second window. Each IP is allowed up to 5 failed handshake attempts before being banned for 300 seconds. The RateLimiter maintains an in-memory HashMap<IpAddr, RateLimitEntry> with periodic cleanup of expired entries to prevent unbounded memory growth. The check_attempt method atomically increments the attempt counter, resets the window if it has expired, checks whether the IP is currently banned, and returns false if the attempt should be rejected. record_success resets the counter and clears any ban on successful authentication, allowing legitimate clients that temporarily misconfigured their PSK to recover. The rate limiter is shared across all connections via Arc<Mutex<» and passed through HandlerContext. The handshake handler calls check_attempt before validating the PSK proof, ensuring brute-force attempts are blocked before any cryptographic work is performed. If the rate limit is exceeded, a HandshakeAck with a descriptive error is sent and the connection is closed. On successful authentication, record_success is called to clear the counter. Four unit tests verify that the first five attempts are allowed, the sixth is blocked, record_success resets the counter, and different IPs are tracked independently.
Add file chunk streaming to archive and restore handlers Implement the raw chunk streaming protocol in both directions on the server side. After accepting an ArchiveRequest, the handler enters a chunk receive loop (handle_archive_chunks) that reads 4-byte big-endian length prefixes followed by that many bytes of data, appending each chunk to the project’s archive file on disk via append-mode file I/O. A zero-length chunk signals EOF. The total bytes received is logged for monitoring. On the restore side, handle_restore_chunks reads the complete archive file from disk through the storage layer, then streams it back to the client in 1 MiB chunks with the same 4-byte length-prefixed format, followed by a zero-length EOF marker and a flush. This mirrors the client’s restore_project method which reads chunks in the same format. The dispatch function now chains the chunk streaming phase after the initial request acceptance: ArchiveRequest dispatch calls handle_archive_start followed by handle_archive_chunks, and RestoreRequest calls handle_restore_start followed by handle_restore_chunks. The ArchiveComplete and RestoreComplete messages are received as framed messages after the chunk phase completes, handled by the existing finish functions.
Add server integration test suite and library target for external testing Create 17 integration tests in pwr-server/tests/server_integration.rs covering the full server subsystem. Storage CRUD tests (6) verify project creation with duplicate rejection, removal, archive read/write round-trips through the storage layer, persistence across re-opens via registry JSON, and size limit enforcement rejecting archives exceeding the configured max_project_size_gb. PSK handshake tests (3) validate the full mutual authentication flow with correct proof verification and wrong-PSK rejection. Frame-level integration tests (3) exercise the complete serialization pipeline: Handshake framing round-trip with client_id and nonce preservation, ArchiveRequest framing with all fields intact, and server message decode direction checking. File chunk streaming tests (2) simulate the chunk protocol by encoding 250 KB of cyclical data across 4 KB chunks with 4-byte length prefixes and EOF markers, reassembling on the receiver side and verifying content equality. An empty archive test confirms that a standalone EOF marker produces zero bytes of received data. Rate limiter tests (3) verify the 6th attempt is blocked after 5 allowed, success resets the window, and different IPs are tracked independently. A full archive-restore simulation test writes 500 KB of data through the storage layer, reads it back, and verifies byte-exact restoration plus metadata persistence. A cleanup test confirms that removing a project after a failed archive deletes both the archive file and registry entry. To support external integration tests, a library target (lib.rs) is added to pwr-server, re-exporting all modules as public while the binary target (main.rs) retains its own private module declarations.
Implement TLS connector with certificate pinning and retry logic for the client Add a complete TLS connection path to PwrClient, replacing the previous stub that returned a not-yet-implemented error. The connect_tls function builds a rustls ClientConfig with webpki root certificates for standard PKI validation. When a server_fingerprint is set in the client config, a custom FingerprintVerifier replaces the default verifier. This verifier computes the SHA-256 hash of the server’s end-entity certificate DER bytes and compares it against the pinned hex fingerprint, implementing trust-on-first-use style certificate pinning without requiring a private CA. The verifier supports TLS 1.2 and 1.3 signature schemes including RSA and ECDSA P-256. The PwrClient struct gains server_addr, psk, and pinned_fingerprint fields, enabling a reconnect method that re-establishes a TCP connection to the same server and re-runs the PSK handshake without reloading the config file. The connect method now branches on use_tls, routing to either the TLS path with certificate validation or the plaintext path for local testing. Add retry logic via the with_retry helper, a generic function that wraps any fallible operation with exponential backoff. The caller provides a retryable-error predicate; is_retryable_error recognizes connection refused, timeout, connection closed, connection reset, broken pipe, and unexpected EOF as transient errors worth retrying. The base delay doubles each attempt, with a configurable maximum number of retries.
Add progress reporting module with indicatif integration and stage callbacks Introduce a progress module in the pwr CLI crate that provides two display modes for long-running operations. The archive_progress_bar and restore_progress_bar functions create indicatif ProgressBar instances with styled templates showing a spinner, progress bar, byte counter, and ETA. The update_archive_progress function maps ArchiveStage enum values to human-readable status messages displayed in the bar. For non-interactive terminals or quiet mode, print_stage emits a simple line to stderr for each stage transition during archive or extract operations. This provides visibility into long-running operations without requiring a TTY.
Add client integration test suite with handshake, streaming, retry, and progress tests Create 14 integration tests in pwr-cli/tests/client_integration.rs covering the client-side protocol layer. Handshake tests verify that ClientMessage frames encode with correct magic bytes, version, and type discriminants, and that decode_client_message recovers the original Handshake struct with client_id and nonce intact. Archive flow tests exercise ArchiveRequest and ArchiveComplete serialization round-trips with all fields including UUID, name, total_size, file_count, compression, and hash. Restore flow tests verify RestoreRequest encoding and decoding. Server response parsing tests validate that HandshakeAck, Error, and StatusResponse messages are correctly deserialized from framed payloads, including success flags, error codes, and project info vectors with UUID and file_count fields. Chunk streaming tests cover five size boundaries from zero bytes (EOF detection) through 1 MiB, plus standalone EOF marker encoding. Retry logic tests verify is_retryable_error correctly classifies connection failures, timeouts, and broken pipes as transient while treating authentication and not-found errors as fatal. with_retry is tested for immediate success, maximum retry exhaustion (initial + 3 retries = 4 calls), and early termination on non-retryable errors after 1 call. A progress stage test confirms all five ArchiveStage variants are distinct.
Wire progress bars and retry logic into CLI archive and restore commands Integrate the progress reporting module and retry logic into the two main CLI workflows. The archive command now creates a progress bar before the packaging pipeline and passes it to create_archive_with_progress via a ProgressFn callback that maps ArchiveStage values to status messages and fractional bar position. A second progress bar tracks the upload phase. Both bars are finished and cleared on completion. The restore command similarly uses a download progress bar keyed to the stored project size and an extraction progress bar sized to the received encrypted blob. Connection attempts now use with_retry wrapping PwrClient::connect with 3 retries and a 1-second base delay, retrying only on transient network errors as classified by is_retryable_error. This provides resilience against momentary server unavailability without masking fatal errors like authentication failures.
Add –tls flag to all network commands, –limit to log, –auto-install to shell init Extend the CLI with connection and usability flags across all subcommands. Every command that contacts the server (archive, restore, ensure, status, list) now accepts a –tls flag that is passed through to PwrClient::connect, controlling whether the connection uses TLS with certificate pinning or plaintext for local testing. The log command gains a –limit flag defaulting to 50 entries, with a summary line showing how many entries were truncated. The shell init command supports –auto-install which opens the shell rc file in append mode and writes the eval line directly, providing a one-command setup experience. Function signatures throughout main.rs are updated to thread the new boolean parameter. The ensure command passes tls=false through to its internal restore call since ensure is triggered from the shell wrapper where TLS may not be configured. The list command delegates to cmd_status with tls=false for local-only directory scanning.
Clean up unused imports and fix compilation warnings in client TLS module Remove unused Arc import from the top-level client scope (it is only needed inside the connect_tls function where it is imported locally). Replace TrustAnchor with the correct ServerName import from rustls::pki_types. Remove the unnecessary mut qualifier from the ClientConnection binding in connect_tls.
Fix server handler and listener warnings: remove unnecessary parentheses and unused imports Clean up compilation warnings in the pwr-server crate. In handler.rs, the send_server_msg function signature used unnecessary parentheses around impl Write which triggered the unused_parens lint. In listener.rs, the PrivateKeyDer import was unused since the key is loaded via rustls_pemfile::private_key which returns a generic PrivateKeyDer type that does not need to be explicitly imported.
Add server address display to status command output Extend the status command to print the configured server host and port after the project count summary, giving users a quick reminder of which NAS their projects are archived to.
Implement TLS transport with custom certificate verifier and fingerprint pinning Replace the TLS-not-yet-implemented stub in the PwrClient with a working rustls-based TLS 1.3 connection layer. The connect_tls function builds a ClientConfig using the dangerous API with a custom certificate verifier (CertVerifier) that accepts self-signed server certificates — necessary because pwr-server generates its own ECDSA P-256 certificate during init rather than obtaining one from a public CA. Authentication is provided by the PSK handshake running over the encrypted channel, so the TLS layer provides confidentiality while the application layer handles mutual authentication. The verifier supports optional SHA-256 certificate fingerprint pinning. When a server_fingerprint is present in the client config, the verifier computes the SHA-256 hash of the server’s end-entity certificate and compares it against the pinned value, rejecting the connection on mismatch. When no fingerprint is configured, the verifier accepts any certificate but logs the observed fingerprint for the user to pin later, enabling a trust-on-first-use workflow. Signature verification in the verifier accepts all TLS 1.2 and 1.3 signatures without checking against a root CA. This is intentional: the security model relies on PSK-based mutual authentication at the application layer combined with certificate pinning for defense-in-depth, rather than on the Web PKI trust infrastructure which would reject self-signed certificates. The supported_verify_schemes list advertises ECDSA and RSA schemes to maximize compatibility.
Add exponential backoff retry logic to PwrClient connection Implement connect_with_retry in PwrClient that wraps the existing connection logic with up to 3 retry attempts using exponential backoff starting at 1 second and doubling to 2 and 4 seconds. The existing connect method is renamed to connect_once and made private, with the public connect method now calling it in a retry loop. Transient network failures such as TCP connection refused or TLS handshake timeouts are retried, while authentication failures are not (they propagate immediately since retrying with the same credentials would produce the same result). Each retry attempt is logged at WARN level with the error and delay, and a successful retry is logged at INFO level. The connect_timeout_secs from the client config is applied to each individual TCP connection attempt within the retry loop.
Add progress callback support to client archive and restore methods Extend archive_project and restore_project with optional progress callbacks that report bytes transferred against total size. The existing methods become thin wrappers calling the new archive_project_with_progress and restore_project_with_progress variants with None for backward compatibility. During archive, the callback fires after each 1 MiB chunk is written to the TCP stream, reporting cumulative bytes sent. During restore, the callback fires after each received chunk is appended to the buffer, reporting cumulative bytes received. The callback signature is fn(u64, u64) where the first argument is current progress and the second is the total, suitable for driving indicatif progress bars or TUI progress displays without coupling the client module to any specific UI library.
Add progress bar integration to CLI with empty-archive edge case handling also add 0-byte transfer file size.
Fix client integration tests and add retry-aware connect test Repair the client integration test suite after the retry logic and library target additions. The connect_to_nonexistent_server test now uses a match statement instead of unwrap_err to work with the ClientResult type. The connect_timeout_is_respected test is marked #[ignore] because OS-level TCP timeout behavior varies across platforms, making sub-second timeout assertions unreliable in CI environments. Unused imports (TcpListener, Duration) are removed from the test file.
Add systemd service unit and deployment guides for server and client Create a hardened systemd service unit for pwr-server with security directives including NoNewPrivileges, PrivateTmp, ProtectSystem=strict, ProtectHome=yes, and read-only access to config and certificate paths with read-write access only to the project storage directory. The service runs as the pwr system user, restarts on failure with a 5-second delay, and logs to journald. Resource limits cap file descriptors at 4096 and memory at 512 MB. Add docs/server-setup.md covering the complete Debian 12 deployment workflow: installing build dependencies, compiling with cargo, initializing the server to generate TLS certificates and PSK, creating the storage directory with correct ownership, installing and enabling the systemd service, verifying the listener with ss, configuring firewall rules for nftables and iptables, and troubleshooting common issues. Add docs/client-setup.md covering the Arch Linux client workflow: building the binary, running pwr init with server host and PSK, setting up shell integration for bash, zsh, and fish, performing the first archive and restore, launching the TUI, and troubleshooting configuration and authentication errors. Include a full configuration file reference.
Fix warning: remove unused variable and clean up imports Remove the unused config variable clone from the listener accept loop where it was captured by the thread closure but never referenced. Remove the unused PrivateKeyDer import from rustls pki_types. Prefix the catch-all match variable with underscore to suppress the unused variable warning in the dispatch function. Keep the required parentheses around impl Trait syntax in argument position as required by Rust 2024 edition for disambiguation. Add MIT LICENSE file.
Annotate session state structs with allow(dead_code) for future use The ArchiveSession and RestoreSession structs in the handler state machine contain fields (session_id, file_count, compression, bytes_received, bytes_sent) that are stored for future use in resume-after-interruption logic and detailed transfer statistics. Currently they are only written during state transitions but not yet read back. Add #[allow(dead_code)] annotations to suppress compiler warnings while keeping the fields available for the planned transfer progress tracking and interrupted archive resume features.
Add operation progress overlay to TUI and wire pwr tui subcommand in CLI Implement an OperationOverlay screen for the ratatui-based TUI that renders a centered modal dialog with a progress gauge, transfer statistics, and a cancel prompt during archive and restore operations. The overlay displays the operation name and project name in the title bar, a cyan progress gauge driven by the bytes_done/bytes_total ratio, a statistics line showing human-readable byte counts with percentage, and a status line that changes between ‘Press Esc to cancel’ during transfer, ‘Transfer complete’ on success, and red error text on failure. The format_size helper converts byte counts to GB/MB/KB/B with one decimal place. The handle_input method maps Escape to cancellation and Enter to dismissal after completion. Wire the pwr tui subcommand into the CLI behind the tui feature flag. The Commands enum gains a Tui variant gated by #[cfg(feature = “tui”)], the dispatch match arm calls cmd_tui(), and the tui module is conditionally compiled. Building without –features tui produces a CLI-only binary; building with the flag includes the ratatui and crossterm dependencies and the tui module, enabling pwr tui to launch the interactive interface.
Add end-to-end integration tests for full client-server lifecycle Implement two end-to-end tests using paired in-memory byte streams (Pipe struct implementing Read+Write via Arc<Mutex<Vec») that simulate a complete client-server interaction without network dependencies. test_full_client_server_archive_restore_cycle creates a multi-file project directory, generates age encryption keys and a PSK, runs the archive pipeline to produce an encrypted blob, then spawns two threads for client and server communicating through paired pipes. The client performs the full protocol sequence: Handshake with HMAC-SHA256 proof, ArchiveRequest with project metadata, chunked data transfer with 1 MiB chunks and zero-length EOF marker, and ArchiveComplete with SHA-256 hash. The server thread receives the Handshake, verifies the client proof, responds with its own server proof for mutual authentication, reads the ArchiveRequest, receives all chunks via the 4-byte length-prefixed streaming protocol, and acknowledges ArchiveComplete. After both threads join, assertions verify the server received the exact encrypted blob, decryption succeeds, and the local project metadata transitions correctly through local → archived → placeholder states with .project.toml file survival. test_end_to_end_hash_verification_prevents_corruption validates that tampering with a single byte of the encrypted archive produces a different SHA-256 hash, ensuring integrity violations are detectable before extraction.
Document required parentheses around impl Trait syntax in handler signatures The Rust 2024 edition requires explicit parentheses around compound trait bounds in function argument position. Without them, ‘&mut impl Read + Write’ is ambiguous: it could parse as ‘(&mut impl Read) + Write’ (a mutable reference to a type implementing Read, with an additional Write bound) or ‘&mut (impl Read + Write)’ (a mutable reference to a type implementing both). The compiler requires the latter to be written with parentheses. Add a module-level doc comment explaining this so future maintainers do not attempt to remove the parentheses.
Add bash tab completion script for pwr CLI commands Provide a bash completion function for all pwr subcommands and their flags. The completion script maps each subcommand to its valid arguments: init completes –server-host, –server-port, –psk, and –local-root; archive, restore, and ensure complete directory paths; status and list offer –recursive/-r; log provides –errors/-e and –project; shell completes bash, zsh, fish, and –init. The completion is installed via ‘source <(pwr completions bash)’ in .bashrc.
Ships:
Note: Very untested, only try with projects you have backups of! Psync was designed to solve the problem of my laptop having limited storage and my with to be able to use my nas semi-transparently without the use of automountd or fuse both of which I have tried and deployed in other scenarios and neither of which are resiliant to not being able to contact the NFS server when on different networks. So i made Psync which uses encryption which make me feel secure enough to open it up to the internet instead of unauthenticated NFS....
|
1793775269.3258123
|
1794639269.3258123
|
|
23411
|
My awesome macropad! by @cdv | Stardance
|
cdv
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @cdv | Stardance
|
1793775268.4104042
|
1794380068.4104042
|
|
27620
|
'Amazing' Jokes Generator by @y4r4 | Stard 'Amazing' Jokes Generator by @y4r4 | Stardance...
|
y4r4
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-28T13:42:42Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a website that generates random (dad) jokes using HTML, CSS and JavaScript. To get a joke you just have to click the button. The hardest part was probably the java script code and finding out how it can generate random jokes without repeating them or using a loop of handwritten notes. I am very proud of how the styling of the website turned out.", "repo": "https://github.com/y4r4a/legoo", "demo": "https://y4r4a.github.io/legoo/"}]...
|
[{"post_id": 17592, "ts": "202 [{"post_id": 17592, "ts": "2026-06-28T13:38:49Z", "hours": 2.0, "text": "I made a website that generates random (dad) jokes using HTML, CSS and JavaScript. When you click the button a random joke appears."}]...
|
Title: 'Amazing' Jokes Generator by @y4r4 Title: 'Amazing' Jokes Generator by @y4r4 | Stardance
Devlogs:
I made a website that generates random (dad) jokes using HTML, CSS and JavaScript. When you click the button a random joke appears.
Ships:
I made a website that generates random (dad) jokes using HTML, CSS and JavaScript. To get a joke you just have to click the button. The hardest part was probably the java script code and finding out how it can generate random jokes without repeating them or using a loop of handwritten notes. I am very proud of how the styling of the website turned out....
|
1793775267.476634
|
1794639267.476634
|
|
1072
|
ESSENTIALS Shader by @ahnafiscool | Stardance
|
ahnafiscool
|
1
|
28.0
|
548
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-16T10:55:55Z", "hours": 28.0, "multiplier": 19.55, "payout": 548, "blessing": "neutral", "text": "Hey, read this, I’ve typed it in a way so that u don’t get bored: It is finally done… ESSENTIALS Shader is live and working so that you with a terrible device (like me) will have a chance to behold the premium look of minecraft without breaking the bank to buy a GPU. Ofc, it will not be the best looking shader since it’s optimized, but what more can you ask for? I was motivated to make a shader of my own because of 2 things: Wanting a GPU and help people to play mc smoothly with iGPU. I was planning to submit this shader to Lumen so that I’ll be eligible to win a GPU (unfortunately it ended well before I finished). The hardest part was actually testing it, yeah really. I can’t even count how many times MC crashed when I turned on n off the shader everytime. And hackatime did not support on my Win7 so I had to both write codes in codespaces and locally to commit changes (2X work already here) and hours of work was not properly recorded. The best part was when I was midway through the project, I got so much interaction this page with followers, likes and most importantly ‘Super Star Project’. So tysm to all NOTE: Please click on the skip button if you did not understand the point of the project, do not vote without testing/knowing anything abt it. It may not look visually appealing to you but you must understand the sole purpose of the project. So please vote wisely ;)", "repo": "https://github.com/AhnafPro/ESSENTIALS-Shader", "demo": "https://modrinth.com/shader/essentials-shader"}]...
|
[{"post_id": 9875, "ts": "2026 [{"post_id": 9875, "ts": "2026-06-16T10:34:35Z", "hours": 7.0, "text": "Im really with skl stuffs these and did not have quite a lot of time to code like before. Since I have not posted a devlog in a long time, I’ll just briefly explain some simple changes/updates that were done. The shader was approved on Modrinth and CurseForge (). We also recieved decent amount of downloads combined. Check out below: https://modrinth.com/shader/essentials-shader/ https://www.curseforge.com/minecraft/shaders/essentials-shader A custom LICENSE file has been created to suit all the rules and regulations. And previous LICENSE based on GPL 3.0 was removed. Find it here: https://github.com/AhnafPro/ESSENTIALS-Shader/tree/main?tab=License-1-ov-file Gamma correction value has been altered. The day might look a little pale in color than before but it ensures that the night does not black out completely Reflection of moonlight on water is visible now (no performance cuts)"}, {"post_id": 6984, "ts": "2026-06-11T18:41:27Z", "hours": 4.0, "text": "Yoo, Im back after a long time, cuz I was really busy and tired with the school works, exams etc. Today I was bit free so I did lots of testing, debugging, editing etc. and then prepared the shader for a beta release on modrinth. I got nothing much to say cuz I’m really sleepy isw. And this ain’t the end, not the final version so please report bugs under any latest devlog here and i’ll look after it Project: https://modrinth.com/shader/essentials-shader Also I took some pics for gallery, pls enjoy…"}, {"post_id": 5048, "ts": "2026-06-08T18:25:13Z", "hours": 1.0, "text": "This project was marked as “Super Star Project”! and I would like to thank all of you who have interacted via following, commenting etc. cuz its an important milestone for our project. tysm once again… Some quite simple changes has been done in this log such as: Altered wavering effect to water to bare minimum value (unnoticeable tbh) so that when shadow falls on it, the shadow sort of move. Added a hover me button on the pack settings with some parts of README section (also read the note) Honestly the changes seems simple but the second change was kinda hard cuz it’s not that simple to make desc. of texts appear on buttons but credits to iris documentation, I made it into hovering style instead with the help of it. I’ll see if I can add more things to it … cya"}, {"post_id": 4162, "ts": "2026-06-07T11:34:19Z", "hours": 1.0, "text": "Feeling a bit lazy today cuz it’s sunday but I still made some updates, from the last log, I’ve fixed the water opacity issue (the water is now in 1 color across all y-angle) and now I’m mostly debugging and making small changes here and there, like updating the readme, seeing if certain blocks render properly etc. So far we are mostly done for a good optimized shader but I think there might be some things missing that I haven’t looked after- like today when I was working with the water shader files on overworld but then I remembered that I forgot to add the files for water to the end dimension (excluding nether here cuz water don’t work there yk).Which would have made water appear like normal vanilla ones. So there might lots of other stuffs im missing out. Once I make every major fix, I’ll upload the shader to modrinth so that you guys can review and give me feedback on it. Updates done: Fixed water opacity issue across the y axis from the crosshair horizontally."}, {"post_id": 3417, "ts": "2026-06-06T10:51:06Z", "hours": 3.0, "text": "Today I was working on improving the water, I did some noticeable improvements but it still has one issue, at different y angles the opacity of the blue color of water changes. So I will try to fix next time or keep it as it since its not a big visual issue. Also found another problem at End, when I hit the ender mobs they do not render the red effect. Therefore i’ve encountered 2 minor issues. Hope i’ll be able to patch it… bye"}, {"post_id": 2847, "ts": "2026-06-05T18:06:39Z", "hours": 4.0, "text": "I really felt dumb after spending over 4 hrs trying to fix the last 2 issues, ill tell you why. The issue with grainy effect on the sky can’t be fixed, some of my friends told it kinda looks good like a galaxy with millions of star and there isnt any point of working on it if Im not able to patch it. And here where it gets interesting. The first issue was where I spent most of the time, to then discover that the fix was sitting just on a different directory. I tottaly forgot that I’ve patched mob texture issues before with the help of gbuffer_textured f/v shader files, so I just copied them from overworld and pasted them on world1 file and everything got fixed. I was really dissapointed tbh. So the fixes were: Copying gbuffer_textured f/v shader files & gbuffer_terrain_lit f/v shader files to world1 Copying gbuffer_textured f/v shader files to world-1 So basically we got our shader made but we can’t be just releasing on modrinth like this. We need to test with older version, check various scenarios to see if things break, improve some current elements like water, maybe add reflection etc. Please let me know if you have suggestions…"}, {"post_id": 1477, "ts": "2026-06-03T14:59:40Z", "hours": 1.0, "text": "I’ve finally fixed the End dimension the shading works well and also added aurora effect in the sky (this genuinely required help from claude), and the good news is it does not effect fps much or even at all. Also there is an alternation in sky light between the cheese yellow and slight pink (u can see the variation in both images). But I ran into 2 different issues here: The ender mobs (enderman,mites, dragon) are not rendering their purple from their eyes aka no eyes. When moved to outer end island or when dragon is killed in main island, the sky seems to render the grainy effect (which looks a bit odd like its a whole milky way) So, I’ll try to patch it today night, cuz these are some common shader issues while making one, there are enough documentation from various sources like iris, shaderLABs etc. Wish me gl!"}, {"post_id": 976, "ts": "2026-06-02T19:12:03Z", "hours": 1.0, "text": "I’m really tired today after juggling school works and this project at the same time, as of now I made a pretty basic shader, the lighting work (as you can see the light from the torches) but the shadow is sorta broken, its not appearing and the whole world kinda look way too lit up (when Im far from the ender dragon’s main island). Imma peace out for today and will try to patch it tmrw."}, {"post_id": 861, "ts": "2026-06-02T15:58:30Z", "hours": 0.0, "text": "Just did a little work some code cleanup and also made the end files inspired by shaderLABS which were similar to nether files but certain things like change in color filter of sky for end is needed. I’ll try to add the end shader update on the next devlog. CYA… [wrong file image, sry it should have been world1 folder, imma edit it later]"}, {"post_id": 797, "ts": "2026-06-02T13:54:14Z", "hours": 1.0, "text": "I thought the nether was gonna work with the same shader files from the overworld but when I went through the portal, I saw a different story. Everything looked dark, dark as if it was nighttime during overworld but with no moon, also realised that the entities had a transparent body. So these 2 issues were fixed along with the nether shader base when I made it. Things that were done are: Fixed nether lighting Added shadows Removed fog codes from composite.fsh What I have noticed was that I got slight better fps in nether than overworld cuz lots of parts of nether consist of wasteland biome which has less structures and vegetation."}, {"post_id": 357, "ts": "2026-06-01T17:51:38Z", "hours": 0.0, "text": "I started making it way before Stardance cuz I was planning to submit it to Lumen but unfortunately Lumen ended (I was working towards getting a GPU) and I was not able to finish my shader by then. (I spent 10+ hrs of which 3hrs were logged, but not shown here since I logged them before Stardance) As of now its a very lightweight & basic shader, but honestly I think its sorta visually appealing (at least for those who got no ded. gpu). I myslef is use my father’s ancient PC from 2013 with no GPU (MC crashed over 20 times while debugging) and Ik the pain of others who runs their game at bare bones low settings, so I hope this project will come in a help for them as I’ll try to make the shader as optimized as possible. As of now the overworld is sorta complete with these features: Fake sun/moon rays V. weak Fog semi-realistic fresnel water (still in dev.) Shadows, Lighting etc. In my next devlog i’ll update the nether a little more to make it look standout. And I think my logs are not gonna have good amount of time logged in cuz im using Win7 and Hackatime does not work, so I’ll have to manually edit codespaces and local shader files while testing."}]...
|
Title: ESSENTIALS Shader by @ahnafiscool | Stardan Title: ESSENTIALS Shader by @ahnafiscool | Stardance
Devlogs:
I started making it way before Stardance cuz I was planning to submit it to Lumen but unfortunately Lumen ended (I was working towards getting a GPU) and I was not able to finish my shader by then. (I spent 10+ hrs of which 3hrs were logged, but not shown here since I logged them before Stardance) As of now its a very lightweight & basic shader, but honestly I think its sorta visually appealing (at least for those who got no ded. gpu). I myslef is use my father’s ancient PC from 2013 with no GPU (MC crashed over 20 times while debugging) and Ik the pain of others who runs their game at bare bones low settings, so I hope this project will come in a help for them as I’ll try to make the shader as optimized as possible. As of now the overworld is sorta complete with these features: Fake sun/moon rays V. weak Fog semi-realistic fresnel water (still in dev.) Shadows, Lighting etc. In my next devlog i’ll update the nether a little more to make it look standout. And I think my logs are not gonna have good amount of time logged in cuz im using Win7 and Hackatime does not work, so I’ll have to manually edit codespaces and local shader files while testing.
I thought the nether was gonna work with the same shader files from the overworld but when I went through the portal, I saw a different story. Everything looked dark, dark as if it was nighttime during overworld but with no moon, also realised that the entities had a transparent body. So these 2 issues were fixed along with the nether shader base when I made it. Things that were done are: Fixed nether lighting Added shadows Removed fog codes from composite.fsh What I have noticed was that I got slight better fps in nether than overworld cuz lots of parts of nether consist of wasteland biome which has less structures and vegetation.
Just did a little work some code cleanup and also made the end files inspired by shaderLABS which were similar to nether files but certain things like change in color filter of sky for end is needed. I’ll try to add the end shader update on the next devlog. CYA… [wrong file image, sry it should have been world1 folder, imma edit it later]
I’m really tired today after juggling school works and this project at the same time, as of now I made a pretty basic shader, the lighting work (as you can see the light from the torches) but the shadow is sorta broken, its not appearing and the whole world kinda look way too lit up (when Im far from the ender dragon’s main island). Imma peace out for today and will try to patch it tmrw.
I’ve finally fixed the End dimension the shading works well and also added aurora effect in the sky (this genuinely required help from claude), and the good news is it does not effect fps much or even at all. Also there is an alternation in sky light between the cheese yellow and slight pink (u can see the variation in both images). But I ran into 2 different issues here: The ender mobs (enderman,mites, dragon) are not rendering their purple from their eyes aka no eyes. When moved to outer end island or when dragon is killed in main island, the sky seems to render the grainy effect (which looks a bit odd like its a whole milky way) So, I’ll try to patch it today night, cuz these are some common shader issues while making one, there are enough documentation from various sources like iris, shaderLABs etc. Wish me gl!
I really felt dumb after spending over 4 hrs trying to fix the last 2 issues, ill tell you why. The issue with grainy effect on the sky can’t be fixed, some of my friends told it kinda looks good like a galaxy with millions of star and there isnt any point of working on it if Im not able to patch it. And here where it gets interesting. The first issue was where I spent most of the time, to then discover that the fix was sitting just on a different directory. I tottaly forgot that I’ve patched mob texture issues before with the help of gbuffer_textured f/v shader files, so I just copied them from overworld and pasted them on world1 file and everything got fixed. I was really dissapointed tbh. So the fixes were: Copying gbuffer_textured f/v shader files & gbuffer_terrain_lit f/v shader files to world1 Copying gbuffer_textured f/v shader files to world-1 So basically we got our shader made but we can’t be just releasing on modrinth like this. We need to test with older version, check various scenarios to see if things break, improve some current elements like water, maybe add reflection etc. Please let me know if you have suggestions…
Today I was working on improving the water, I did some noticeable improvements but it still has one issue, at different y angles the opacity of the blue color of water changes. So I will try to fix next time or keep it as it since its not a big visual issue. Also found another problem at End, when I hit the ender mobs they do not render the red effect. Therefore i’ve encountered 2 minor issues. Hope i’ll be able to patch it… bye
Feeling a bit lazy today cuz it’s sunday but I still made some updates, from the last log, I’ve fixed the water opacity issue (the water is now in 1 color across all y-angle) and now I’m mostly debugging and making small changes here and there, like updating the readme, seeing if certain blocks render properly etc. So far we are mostly done for a good optimized shader but I think there might be some things missing that I haven’t looked after- like today when I was working with the water shader files on overworld but then I remembered that I forgot to add the files for water to the end dimension (excluding nether here cuz water don’t work there yk).Which would have made water appear like normal vanilla ones. So there might lots of other stuffs im missing out. Once I make every major fix, I’ll upload the shader to modrinth so that you guys can review and give me feedback on it. Updates done: Fixed water opacity issue across the y axis from the crosshair horizontally.
This project was marked as “Super Star Project”! and I would like to thank all of you who have interacted via following, commenting etc. cuz its an important milestone for our project. tysm once again… Some quite simple changes has been done in this log such as: Altered wavering effect to water to bare minimum value (unnoticeable tbh) so that when shadow falls on it, the shadow sort of move. Added a hover me button on the pack settings with some parts of README section (also read the note) Honestly the changes seems simple but the second change was kinda hard cuz it’s not that simple to make desc. of texts appear on buttons but credits to iris documentation, I made it into hovering style instead with the help of it. I’ll see if I can add more things to it … cya
Yoo, Im back after a long time, cuz I was really busy and tired with the school works, exams etc. Today I was bit free so I did lots of testing, debugging, editing etc. and then prepared the shader for a beta release on modrinth. I got nothing much to say cuz I’m really sleepy isw. And this ain’t the end, not the final version so please report bugs under any latest devlog here and i’ll look after it Project: https://modrinth.com/shader/essentials-shader Also I took some pics for gallery, pls enjoy…
Im really with skl stuffs these and did not have quite a lot of time to code like before. Since I have not posted a devlog in a long time, I’ll just briefly explain some simple changes/updates that were done. The shader was approved on Modrinth and CurseForge (). We also recieved decent amount of downloads combined. Check out below: https://modrinth.com/shader/essentials-shader/ https://www.curseforge.com/minecraft/shaders/essentials-shader A custom LICENSE file has been created to suit all the rules and regulations. And previous LICENSE based on GPL 3.0 was removed. Find it here: https://github.com/AhnafPro/ESSENTIALS-Shader/tree/main?tab=License-1-ov-file Gamma correction value has been altered. The day might look a little pale in color than before but it ensures that the night does not black out completely Reflection of moonlight on water is visible now (no performance cuts)
Ships:
Hey, read this, I’ve typed it in a way so that u don’t get bored: It is finally done… ESSENTIALS Shader is live and working so that you with a terrible device (like me) will have a chance to behold the premium look of minecraft without breaking the bank to buy a GPU. Ofc, it will not be the best looking shader since it’s optimized, but what more can you ask for? I was motivated to make a shader of my own because of 2 things: Wanting a GPU and help people to play mc smoothly with iGPU. I was planning to submit this shader to Lumen so that I’ll be eligible to win a GPU (unfortunately it ended well before I finished). The hardest part was actually testing it, yeah really. I can’t even count how many times MC crashed when I turned on n off the shader everytime. And hackatime did not support on my Win7 so I had to both write codes in codespaces and locally to commit changes (2X work already here) and hours of work was not properly recorded. The best part was when I was midway through the project, I got so much interaction this page with followers, likes and most importantly ‘Super Star Project’. So tysm to all NOTE: Please click on the skip button if you did not understand the point of the project, do not vote without testing/knowing anything abt it. It may not look visually appealing to you but you must understand the sole purpose of the project. So please vote wisely ;)...
|
1793775266.4830468
|
1794639266.4830468
|
|
26257
|
Debate Arena by @mucksuck | Stardance
|
mucksuck
|
1
|
8.0
|
10
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-26T09:03:16Z", "hours": 1.0, "multiplier": 8.82, "payout": 10, "blessing": "neutral", "text": "built Debate Arena — a multiplayer AI debate app where two people join a room via a 6-character code, each gets an AI advocate arguing their side, and a judge AI delivers the final verdict on who won challenging: syncing both players in real time with Firebase so the judge only fires after both arguments are submitted. also accidentally exposed my Gemini API key mid-build 💀 caught it fast and rotated it proud of: the multi-provider support — works with Claude, Gemini, and OpenAI. users just bring their own key. built the whole thing in vanilla HTML/CSS/JS, no frameworks to test it: open the link, create a room, share the 6-char code with a friend, pick your sides on any topic and let the AI fight it out 👇 mucksuck-oss.github.io/debate-arena", "repo": "https://github.com/MUCKSUCK-Oss/debate-arena", "demo": "https://mucksuck-oss.github.io/debate-arena/"}]...
|
[{"post_id": 22553, "ts": "202 [{"post_id": 22553, "ts": "2026-07-05T02:23:04Z", "hours": 1.0, "text": "change the design of the web app clean and simple try it on my github website ( https://mucksuck-oss.github.io/debate-arena/ )"}, {"post_id": 20443, "ts": "2026-07-02T01:14:17Z", "hours": 0.0, "text": "ok so debate arena is finally fully working spent way too long fighting CORS errors trying to call hack club ai directly from the browser (turns out you just can’t, it’s server side only). ended up spinning up a cloudflare worker as a proxy so the browser talks to the worker, worker talks to hack club ai, no more CORS nonsense also added a HC / NPC tab switcher on the setup screen. hack club ai is the default (free, no card needed), npc mode lets you bring your own gemini/openai/claude key if you want your specific model fighting mucksuck-oss.github.io/debate-arena"}, {"post_id": 19353, "ts": "2026-06-30T17:04:07Z", "hours": 0.0, "text": "hey i know it is not working i am working on it"}, {"post_id": 19201, "ts": "2026-06-30T13:46:20Z", "hours": 5.0, "text": "ok so i finally caved and added hack club ai support to debate arena you can now use it without needing your own api key, just grab a free one from ai.hackclub.com and pick a model. still kept the old provider thing too (gemini/openai/claude) just moved it behind a “npc mode” tab so it doesn’t scare off normal people also fixed like 3 git disasters in the process don’t ask mucksuck-oss.github.io/debate-arena"}, {"post_id": 16684, "ts": "2026-06-27T03:46:23Z", "hours": 0.0, "text": "how to use debate arena:- 1. step you must have two API key one for one person. 2. now just fill the form with you name your API key and everything else. 3 now either you create a room or join one. 4 lay back and let your AI debate for you this that simple enjoy."}, {"post_id": 16364, "ts": "2026-06-26T16:58:38Z", "hours": 1.0, "text": "Let’s go!! 🎉 I finally fixed the bug and resolved the Firebase error! Man, their APIs can be really tough to work with, but we got through it. I’m the man! 😎 Time to enjoy the win and keep building!"}, {"post_id": 16175, "ts": "2026-06-26T08:55:52Z", "hours": 1.0, "text": "built a multiplayer AI debate app where two people join a room via a 6-char code, each gets an AI advocate arguing their side, and a judge AI delivers the final verdict stack: vanilla HTML/CSS/JS + Firebase for real-time multiplayer + supports Claude, Gemini & OpenAI (bring your own key) biggest challenge was syncing both players in real time and making sure the judge only fires after both arguments are submitted it’s live and open source 👇 mucksuck-oss.github.io/debate-arena"}]...
|
Title: Debate Arena by @mucksuck | Stardance
Devl Title: Debate Arena by @mucksuck | Stardance
Devlogs:
built a multiplayer AI debate app where two people join a room via a 6-char code, each gets an AI advocate arguing their side, and a judge AI delivers the final verdict stack: vanilla HTML/CSS/JS + Firebase for real-time multiplayer + supports Claude, Gemini & OpenAI (bring your own key) biggest challenge was syncing both players in real time and making sure the judge only fires after both arguments are submitted it’s live and open source 👇 mucksuck-oss.github.io/debate-arena
Let’s go!! 🎉 I finally fixed the bug and resolved the Firebase error! Man, their APIs can be really tough to work with, but we got through it. I’m the man! 😎 Time to enjoy the win and keep building!
how to use debate arena:- 1. step you must have two API key one for one person. 2. now just fill the form with you name your API key and everything else. 3 now either you create a room or join one. 4 lay back and let your AI debate for you this that simple enjoy.
ok so i finally caved and added hack club ai support to debate arena you can now use it without needing your own api key, just grab a free one from ai.hackclub.com and pick a model. still kept the old provider thing too (gemini/openai/claude) just moved it behind a “npc mode” tab so it doesn’t scare off normal people also fixed like 3 git disasters in the process don’t ask mucksuck-oss.github.io/debate-arena
hey i know it is not working i am working on it
ok so debate arena is finally fully working spent way too long fighting CORS errors trying to call hack club ai directly from the browser (turns out you just can’t, it’s server side only). ended up spinning up a cloudflare worker as a proxy so the browser talks to the worker, worker talks to hack club ai, no more CORS nonsense also added a HC / NPC tab switcher on the setup screen. hack club ai is the default (free, no card needed), npc mode lets you bring your own gemini/openai/claude key if you want your specific model fighting mucksuck-oss.github.io/debate-arena
change the design of the web app clean and simple try it on my github website ( https://mucksuck-oss.github.io/debate-arena/ )
Ships:
built Debate Arena — a multiplayer AI debate app where two people join a room via a 6-character code, each gets an AI advocate arguing their side, and a judge AI delivers the final verdict on who won challenging: syncing both players in real time with Firebase so the judge only fires after both arguments are submitted. also accidentally exposed my Gemini API key mid-build 💀 caught it fast and rotated it proud of: the multi-provider support — works with Claude, Gemini, and OpenAI. users just bring their own key. built the whole thing in vanilla HTML/CSS/JS, no frameworks to test it: open the link, create a room, share the 6-char code with a friend, pick your sides on any topic and let the AI fight it out 👇 mucksuck-oss.github.io/debate-arena...
|
1793775265.4712565
|
1794639265.4712565
|
|
8264
|
My first slack bot! by @chouranebd_4507 | Stardanc My first slack bot! by @chouranebd_4507 | Stardance...
|
chouranebd_4507
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @chouranebd_4507 | S Title: My first slack bot! by @chouranebd_4507 | Stardance...
|
1793775264.4532783
|
1794380064.4532783
|
|
30382
|
On Demand Judge by @jayeshsinghal | Stardance
|
jayeshsinghal
|
1
|
19.0
|
149
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-06T19:53:21Z", "hours": 19.0, "multiplier": 8.04, "payout": 149, "blessing": "neutral", "text": "AI Debate Judge A real-time multiplayer debate platform with AI-powered judging using Groq’s Llama and Whisper models. Features Multiplayer Debates: Two players debate in real-time with WebRTC video streaming Live Video: See your opponent during the debate with side-by-side video feeds Speech-to-Text: Automatic transcription using Groq Whisper API AI Judging: Comprehensive debate analysis using Groq Llama 3.3 70B Public Forum Format: 8 speeches across 4 rounds (Constructive, Rebuttal, Summary, Final Focus) Real-time Sync: Firebase Realtime Database for instant synchronization Tech Stack Pure HTML/CSS/JavaScript (no build tools) Firebase Realtime Database WebRTC for peer-to-peer video Groq API (Whisper + Llama 3.3 70B) Deployed on Vercel How to Use Visit ondemandjudge.vercel.app Create a debate room or join with a room code Wait for both players to connect Start the debate and speak when it’s your turn Each speech has a 5-minute time limit After all 8 speeches, get AI-powered judging results Debate Format Round 1: Constructive Speeches (Pro then Con) Round 2: Rebuttal Speeches (Pro then Con) Round 3: Summary Speeches (Pro then Con) Round 4: Final Focus (Pro then Con) Judging Criteria The AI judge evaluates both teams on: Claims Quality (0-10) Evidence Strength (0-10) Persuasiveness (0-10) Winner is determined by overall score and detailed reasoning.", "repo": "https://github.com/jsplaystore/OnDemandJudge", "demo": "https://ondemandjudge.vercel.app"}]...
|
[{"post_id": 23684, "ts": "202 [{"post_id": 23684, "ts": "2026-07-06T19:52:46Z", "hours": 1.9008, "text": "Finalized the project by redoing the UI and fixing small streaming issues"}, {"post_id": 23616, "ts": "2026-07-06T17:58:21Z", "hours": 3.5458, "text": "Redid the UI, fixed video streaming! Tested it without speaking, and the judging seems pretty good!"}, {"post_id": 22387, "ts": "2026-07-04T20:44:44Z", "hours": 3.5069, "text": "Was able to figure out how to get the rooms working, just need to clean up some things on both sides for this to be finished."}, {"post_id": 22249, "ts": "2026-07-04T16:56:07Z", "hours": 1.8972, "text": "Working on a room system, I was able to code the logic – still using the AI UI because I am simply too lazy right now, but I will get to it before ship. You can invite people to debate you and the impartial AI scores you, is the concept so far. Rooms need to be bugfixed, sitll working on that"}, {"post_id": 21887, "ts": "2026-07-04T01:59:07Z", "hours": 1.1386, "text": "I was able to split the two into video and transcript, and one uses videos processed locally. I want to see if i can make rooms and have people join and debate their friends… also redo UI"}, {"post_id": 21859, "ts": "2026-07-04T00:48:55Z", "hours": 1.7606, "text": "Worked on getting the recordings to work so that the debate will get scored based on the recordings. I will have to test it out, but so far, this is what I have. I have yet to change the UI myself; I will get to that… Next orders of business, TEST grading systems, work on UI and bug fix Next"}, {"post_id": 21816, "ts": "2026-07-03T22:59:55Z", "hours": 4.77, "text": "AI Debate judge underway, I spent a lot of time working out the logic behind how to judge debates, used AI to make a simply UI, but I am going to handmake it later… Currently uses an API key, but I am going to change the logic once I figure it out… Hope you enjoy the journey this will take me on."}]...
|
Title: On Demand Judge by @jayeshsinghal | Stardan Title: On Demand Judge by @jayeshsinghal | Stardance
Devlogs:
AI Debate judge underway, I spent a lot of time working out the logic behind how to judge debates, used AI to make a simply UI, but I am going to handmake it later… Currently uses an API key, but I am going to change the logic once I figure it out… Hope you enjoy the journey this will take me on.
Worked on getting the recordings to work so that the debate will get scored based on the recordings. I will have to test it out, but so far, this is what I have. I have yet to change the UI myself; I will get to that… Next orders of business, TEST grading systems, work on UI and bug fix Next
I was able to split the two into video and transcript, and one uses videos processed locally. I want to see if i can make rooms and have people join and debate their friends… also redo UI
Working on a room system, I was able to code the logic – still using the AI UI because I am simply too lazy right now, but I will get to it before ship. You can invite people to debate you and the impartial AI scores you, is the concept so far. Rooms need to be bugfixed, sitll working on that
Was able to figure out how to get the rooms working, just need to clean up some things on both sides for this to be finished.
Redid the UI, fixed video streaming! Tested it without speaking, and the judging seems pretty good!
Finalized the project by redoing the UI and fixing small streaming issues
Ships:
AI Debate Judge A real-time multiplayer debate platform with AI-powered judging using Groq’s Llama and Whisper models. Features Multiplayer Debates: Two players debate in real-time with WebRTC video streaming Live Video: See your opponent during the debate with side-by-side video feeds Speech-to-Text: Automatic transcription using Groq Whisper API AI Judging: Comprehensive debate analysis using Groq Llama 3.3 70B Public Forum Format: 8 speeches across 4 rounds (Constructive, Rebuttal, Summary, Final Focus) Real-time Sync: Firebase Realtime Database for instant synchronization Tech Stack Pure HTML/CSS/JavaScript (no build tools) Firebase Realtime Database WebRTC for peer-to-peer video Groq API (Whisper + Llama 3.3 70B) Deployed on Vercel How to Use Visit ondemandjudge.vercel.app Create a debate room or join with a room code Wait for both players to connect Start the debate and speak when it’s your turn Each speech has a 5-minute time limit After all 8 speeches, get AI-powered judging results Debate Format Round 1: Constructive Speeches (Pro then Con) Round 2: Rebuttal Speeches (Pro then Con) Round 3: Summary Speeches (Pro then Con) Round 4: Final Focus (Pro then Con) Judging Criteria The AI judge evaluates both teams on: Claims Quality (0-10) Evidence Strength (0-10) Persuasiveness (0-10) Winner is determined by overall score and detailed reasoning....
|
1793775258.6102574
|
1794639258.6102574
|
|
9860
|
Discord bot by @Aglomation | Stardance
|
Aglomation
|
1
|
35.0
|
0
|
[{"ship_num": 1, "ts": "2026-1 [{"ship_num": 1, "ts": "2026-10-29T00:27:11Z", "hours": 35.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built a custom Discord bot for a large student server I run, which brings together students from different LBS schools across Sweden. Because our community has unique needs, a normal “off-the-shelf” bot didn’t really meet our needs, so I developed a bot with a few tailor-made features that fits our needs. First, I created a custom ban system instead of using Discord’s built-in option. Discord’s default ban system applies an IP ban, which was a major problem for us since hundreds of students share the same school Wi-Fi. Instead, this system automatically kicks banned members if they try to rejoin. To handle spam from compromised accounts, the bot also monitors a honeypot channel. If an account sends a message there, it immediately mutes them without needing a moderator. Finally, the main reason for creating the bot was to build an automated verification system that ensures members are actual LBS students. The bot generates a unique code for each Discord user, who then submits it through a Google Form using their official school email. The bot verifies the submitted code against the user’s ID, and if everything matches, it grants them the verified role and full access to the server. The main server is a private server after all but most features work great on the demo server!", "repo": "https://github.com/Aglomation/Skol-bot", "demo": "https://discord.gg/C4Y3DUVazK"}]...
|
[{"post_id": 83964, "ts": "202 [{"post_id": 83964, "ts": "2026-10-29T00:04:26Z", "hours": 7.1372, "text": "I’ve remade basically the entire bot i forgot this site existed, erm idk it works good and people on the school server seem to like it :3"}, {"post_id": 71245, "ts": "2026-09-20T14:53:24Z", "hours": 10.5392, "text": "I’ve added tons, forgot this site existed. erm I added temp VCs, a honeypot channel, tons of smaller fixes and automized a bunch of weird things that took ages to do manually"}, {"post_id": 28907, "ts": "2026-07-15T14:42:51Z", "hours": 16.6425, "text": "I’m working on adding tempvc"}, {"post_id": 3593, "ts": "2026-06-06T16:20:56Z", "hours": 0.3981, "text": "Fixed some issues with the birthday commands, also made it into a much nicer embed instead of plaintext"}, {"post_id": 3563, "ts": "2026-06-06T15:42:21Z", "hours": 0.6975, "text": "Made a useless update"}]...
|
Title: Discord bot by @Aglomation | Stardance
Dev Title: Discord bot by @Aglomation | Stardance
Devlogs:
Made a useless update
Fixed some issues with the birthday commands, also made it into a much nicer embed instead of plaintext
I’m working on adding tempvc
I’ve added tons, forgot this site existed. erm I added temp VCs, a honeypot channel, tons of smaller fixes and automized a bunch of weird things that took ages to do manually
I’ve remade basically the entire bot i forgot this site existed, erm idk it works good and people on the school server seem to like it :3
Ships:
I built a custom Discord bot for a large student server I run, which brings together students from different LBS schools across Sweden. Because our community has unique needs, a normal “off-the-shelf” bot didn’t really meet our needs, so I developed a bot with a few tailor-made features that fits our needs. First, I created a custom ban system instead of using Discord’s built-in option. Discord’s default ban system applies an IP ban, which was a major problem for us since hundreds of students share the same school Wi-Fi. Instead, this system automatically kicks banned members if they try to rejoin. To handle spam from compromised accounts, the bot also monitors a honeypot channel. If an account sends a message there, it immediately mutes them without needing a moderator. Finally, the main reason for creating the bot was to build an automated verification system that ensures members are actual LBS students. The bot generates a unique code for each Discord user, who then submits it through a Google Form using their official school email. The bot verifies the submitted code against the user’s ID, and if everything matches, it grants them the verified role and full access to the server. The main server is a private server after all but most features work great on the demo server!...
|
1793775257.1698356
|
1793861657.1698356
|
|
42823
|
tashOS by @vrajsanghavi | Stardance
|
vrajsanghavi
|
2
|
11.34
|
7
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-16T10:26:05Z", "hours": 3.0, "multiplier": 2.57, "payout": 7, "blessing": "neutral", "text": "I HAD MADE MORE THAN 3 CHANGES IN MY tashos[WebOS 2] .. i have added a terminal with basic commands!! i have also included a calculator in commands!! i have added multiple wallpapers here!!! i have added a settings so that you can add/remove website shortcuts!!(my favourite) i have added files and it can save any text you wannt here… and more!!!!! you can see a detailed description in README.md", "repo": "https://github.com/vraj2011/tashOS", "demo": "https://tashos.netlify.app"}, {"ship_num": 2, "ts": "2026-08-13T18:33:56Z", "hours": 4.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "i made this project with full of joy!! and i learned much new things like setting up time and more!!! i have created 2 apps with moving,dragable and closable windows.. i tried to make this tashOS og and it is!!! now i will update it when i unlock webOS2 so waiting for the review…. check this out, https://tashos.netlify.app/", "repo": "https://github.com/vraj2011/tashOS", "demo": "https://tashos.netlify.app"}]...
|
[{"post_id": 60363, "ts": "202 [{"post_id": 60363, "ts": "2026-09-02T17:31:11Z", "hours": 4.3408, "text": "WORKED BIG ON IT !!! I HAVE TO SLEEP SCHOOLS TOMORROW EARLY MORINING ..I WILL EDIT THIS IN FEW HOURS"}, {"post_id": 48042, "ts": "2026-08-16T10:21:18Z", "hours": 1.1839, "text": "finally, everything is looking done… i am shipping this project, you can use it daily!! at tashos.netlify.app"}, {"post_id": 47886, "ts": "2026-08-16T04:35:45Z", "hours": 1.4281, "text": "i have added many wallpapers and auto changing system,too. and i also added a terminal here(learning how to respond for that commands) and more!! i also added a loading page tutorial for users ,i am working to add it in settings,too. visit tashOS at https://tashos.netlify.app"}, {"post_id": 46474, "ts": "2026-08-13T18:28:00Z", "hours": 2.1228, "text": "FINALLY,I DONE IT… I COMPLETED MY FULLL PROJECT NOW ,I KNEW I AM VERY SLOW BUT I POLISHED IT WITH MY FULL OF SKILLS SO IT IS LIVE AT https://tashos.netlify.app and everything’s fine now we have 2 app windows ,i willl add more!!! sooooon!! so get updated keep learning and building!!!its midnight 12 but done"}, {"post_id": 45861, "ts": "2026-08-12T16:14:11Z", "hours": 0.665, "text": "this time i obveously done background image and also a clock version for us!! very good…"}, {"post_id": 45819, "ts": "2026-08-12T15:27:48Z", "hours": 1.1742, "text": "i am on this web os ,i knew i worked very low here but i tried my best writing every single world carefully and i have done this,specially text was failing everytime then i found a issue so i solved it!! part 1 is done by 2x time.. but we will work more soon!!"}]...
|
Title: tashOS by @vrajsanghavi | Stardance
Devlog Title: tashOS by @vrajsanghavi | Stardance
Devlogs:
i am on this web os ,i knew i worked very low here but i tried my best writing every single world carefully and i have done this,specially text was failing everytime then i found a issue so i solved it!! part 1 is done by 2x time.. but we will work more soon!!
this time i obveously done background image and also a clock version for us!! very good…
FINALLY,I DONE IT… I COMPLETED MY FULLL PROJECT NOW ,I KNEW I AM VERY SLOW BUT I POLISHED IT WITH MY FULL OF SKILLS SO IT IS LIVE AT https://tashos.netlify.app and everything’s fine now we have 2 app windows ,i willl add more!!! sooooon!! so get updated keep learning and building!!!its midnight 12 but done
i have added many wallpapers and auto changing system,too. and i also added a terminal here(learning how to respond for that commands) and more!! i also added a loading page tutorial for users ,i am working to add it in settings,too. visit tashOS at https://tashos.netlify.app
finally, everything is looking done… i am shipping this project, you can use it daily!! at tashos.netlify.app
WORKED BIG ON IT !!! I HAVE TO SLEEP SCHOOLS TOMORROW EARLY MORINING ..I WILL EDIT THIS IN FEW HOURS
Ships:
i made this project with full of joy!! and i learned much new things like setting up time and more!!! i have created 2 apps with moving,dragable and closable windows.. i tried to make this tashOS og and it is!!! now i will update it when i unlock webOS2 so waiting for the review…. check this out, https://tashos.netlify.app/
I HAD MADE MORE THAN 3 CHANGES IN MY tashos[WebOS 2] .. i have added a terminal with basic commands!! i have also included a calculator in commands!! i have added multiple wallpapers here!!! i have added a settings so that you can add/remove website shortcuts!!(my favourite) i have added files and it can save any text you wannt here… and more!!!!! you can see a detailed description in README.md...
|
1793775256.2196965
|
1794639256.2196965
|