very real projects here

pretty much almost done with the entire thing! as of last night i finally submitted all the things needed for the HC Gap Year submission and will now wait for the results!!

i completed the projects and explore page now, allowing you to see the mock data i made at the beginning now :3. you can view individual projects for more details, and on projects “you own” (Maya) you can “edit” the project to see a little demo of commenting on (groups of) commits / timestamps on timelapses. You can actually put in any repo to see how it’d look like on others as well, though the comments and grouping are hardcoded and randomized of course.

for the few smaller things: i updated the bg image, adding a little “parallax” effect when moving the cursor around, randomized the timestamps for the comments, added some info at the bottom of the sidebar, and deployed it live to netlify (since i had some issues deploying a node server on my own VPS - i need set everything up again lmao)

this isn’t ready yet for shipping since I need to get it looking decent on mobile (otherwise my ratings will plummet lmao), probably add a bit more explanation to stuff to describe stuff since a lot are placeholders, have a real README, and probably link to my YSWS one pager :3

look at all those items that may not be 404’d!

Still spending too much time on this but after this I’m gonna focus on the actual important stuff of that logging (e.g. commit) commenting & grouping for projects probably! This devlog I added the shop page which shows a list of some of the items that could be in the event, with an image, name, price, and a small funny little blurb. This is very inexhaustive and the prices aren’t final either, this is just to show the kind of stuff that could be in the event.

I also added a funny little error page that shows the status code. For the actually incomplete pages (help & settings), I added additional text to state that lol. The sidebar now dynamically updates depending on the number of projects “submitted” for you and for “total projects” in the event. Finally the dashboard’s featured items cards was updated to match the shop page’s cards with their blurbs.

Dashboard things

Wow, I am spending a lot more hours on this than I should be lol. You’re supposed to spend up to 3 hours (paid) for this, but I already almost reached the 3h in the beginning and went over the limit in this devlog lmao. You can spend more time on this, but I think I’m doing a bit too much lol.

Anyways, this devlog I created the basic structure for the pages to be shown, changed the font, fixed up navigation a bit, and laid out what the dashboard page could be: getting started, featured items, links, and “another section” x3. I’m not going to add stuff to, or at least complete, all pages because I need to get this done quickly; it’s supposed to be a quick draft but I’m overdoing everything. I also got exams soon near the same dates as the submission is due wahhh!

Mounted, your VR YSWS!

I got into the second round for the 2026 Gap Year applications for Hack Club, where you have to create a YSWS concept that you could run. One of the requirements is to create something that shows off your skills, so I am going to be creating a VERY rough mockup of the UI that might be seen in the event.

This is difficult for me because I am not a designer at all, just the implementer, so the design is VERY “inspired” by the Apple Vision Pro glassmorphism UI (and I want to take inspiration from the new Quest Horizon UI as well). So far, I have recreated a basic layout for what you might see when logged in - a very AVP UI with the sidebar showing the different pages you will go to. I also created mock database data that will be used to show off the projects in the “Explore” page.

The background is actually taken from the real image of the 3D scanned Hack Club HQ from a few days ago, but I wanna find a darker BG for accessibility reasons - would be cool for it to be HC-related.

stop, this is terrible

I finally did real-world testing of my HTTP implementation and it was.. worse than I expected in most of the cases (see first video). This was after I refactored quite a bit of the code and trying my best to optimize it; tested out queues, rate limits (<50hz), and other stuff, but nothing seemingly helped it.

finally, a less bad implementation (BLE)

Oh well, after this I started working on the BLE implementation instead - the watch would be the BLE central/master which scans and connects to the BLE peripheral/slave, a device running the “ZeppSlime Server” (idk what to call it yet) which advertises a service with all the characteristics to write to (imu, button, wheel for now).

The watch would then simply write the data to the specific characteristic (IMU/button/wheel), and as I expected this worked WAYYY better than before, who could’ve guessed (see second video); it’s actually submitting data at a constant, not slow rate.

..but it’s still scuffed

The roles are actually reversed in my implementation, as typically the watch would be the peripheral (what devices connect to) and the PC would be the central (the device connecting to others), then the PC would subscribe to notifications on the watch; ZeppOS’ API does not expose the watch as a BLE peripheral yet, just a central.

Now all that’s needed is to interpret the sensor (gyroscope, angular velocity in deg/s, and accelerometer, in cm/s^2) data on the “ZeppSlime Server” and send it over to the SlimeVR Server via UDP!

this is a terrible idea, pls stop

Woo this is terrible but it is working! I’ve set up forwarding the IMU (accelerometer & gyroscope) data now and it’s pretty.. bad lol. I need to do some real-world testing (with my real watch rather than the simulator) but the requests being sent per second isn’t very good lmao.

I will definitely will implement the direct BLE connection when I get the chance. but overall I hope it will be better if i set the frequency mode of the sensors & remove the visual logging, testing on a real device.

HTTP server details

Currently, all the endpoints are GET requests with the IMU endpoint using query parameters of the raw values, which should be smaller/faster than POST requests & parsing JSON. I should move the other endpoints to query params so I could also implement support for multiple watches connected to the same server.

look at you, stealing code from your own project

Other than that, I set up some basic code for the SlimeVR Server forwarding (which I stole a bunch of the code to save time from my previous project, SlimeTora, since it’s also a TS project)

Monorepo time!

I turned the repository into a Bun monorepo consisting of the watch app and the companion server (currently a HTTP server to forward requests to SlimeVR Server).

Screw electron, embrace Tauri

The server app is a Tauri project with SvelteKit as the framework (where I’ll work on the UI later) and I went straight to implementing a basic HTTP API server with the actix_web crate.

Communication things

After creating the basic server, I installed the @zeppos/zml library to make communication easier, testing out the HTTP server through it, and it works.. after forgetting to initialize the side service in app.json again! This is one of the methods of the two I plan to implement (see the previous devlog). The user would just have to enter the PC’s IP to talk with the server for this HTTP method, but I’m making good progress :3

Accessing the data & real HW tests

I took a break for a while because I got busy on some stuff for a school event (& someone forgot she is a YSWS reviewer again lmao).

This time I tested accessing the required sensors I need (accelerometer & gyroscope) so I can interpret that for SlimeVR, displaying it on the screen for now. Also tested out the app on my actual watch for the first time, adding a visual logger package so I could see it on the watch.

Took me quite a bit longer than expected to get working (and I forgot that I needed to add the right permissions to the app.json file).

How should we relay the data?

I was investigating how I could actually relay the data to the SlimeVR Server and came up with two solutions, both being quite scuffed.

HTTP requests

The API allows for external fetch/HTTP requests through the watch connecting to the mobile app (side service), then performing the request on the phone. However, the SlimeVR Server does UDP (or nRF dongle) to handle communication between the trackers.

The first idea was the following, but I imagine the latency would be hell:

• Smart watch -> mobile app -> HTTP server (phone/PC) -> SlimeVR Server (HTTP -> UDP)

Bluetooth Low Energy

The watch can act as a BLE central so the second idea should be much better. Both options aren’t great solutions, but oh well it works I guess – let’s see hw it is in practice lol!

• Smart watch as BLE central -> Phone/PC running a BLE peripheral server -> SlimeVR Server (BLE -> UDP)
  

Doing the UI

The rest of the time was to figure out how to actually draw onto the app, which was pretty confusing because I kept getting errors which provide basically no info (incorrect file numbers as it shows from compiled JS, and some errors that’s supposed to say what variable caused, just shows blank lmfao)

ZeppSlime!

I got the Amazfit Bip 6 for Christmas because it is a very cool smartwatch for its price, with a full on developer API & app store! I had a few ideas for this so here’s the first project: turning these watches into SlimeVR trackers (similar to OwoTrack on Android).

This is my first time setting up a dev environment for it and it’s pretty cool what this company offers:

• The apps (and watch faces) are interestingly made in JavaScript
• The simulator to develop the apps uses QEMU
  
  I tried setting this up on my main NixOS machine, screwing around with the Nix flake but I didn’t get anywhere, so I decided I would just develop on my MacBook Pro instead.

I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.