manjumusei

FINAL DEVLOG!!!!!!!!!!!!!!!!

Did some linting as well as final checking, as well as scale of character sizing + appearance and positioning of enemies and drafting for my eventual export to godot which is a whole new language I would like to learn since I think a game like this would be much easier to code (especially the cards) on there which will be continued in macondo. Happy gaming and I hope flavourtown was a blast for yall! Enemies now are positioned in a way where they dont swarm the screen. Theres also a visibiliy issue for the commander passives in terms of visual detail which will also need a hotfix soon in the future, but there are only 40 minutes left for FT!

Edit: This will be my FINAL devlog for FlavourTown since it is ending soon! Development will continue on Macondo and any sort of restructuring will be continued there! Latest code on git may not work since I am still working on it, so I have hosted the latest working version on cloudflare and took it off vercel since I want to transform it with a chaos engine! Link is here: https://tkpc-cih.pages.dev/, it is updated to the latest iteration of the ship.

Finished debugging liubeis common cards!! Found a race condition while I was debugging!!!!!!!!!!!!! There was a race condition in the persistent save logic where my sync function writes saveData.run then calls persistSave() without awaiting it and then there is multiple quick state changes that scheduled overlapping async saves and caused chaos! It hasnt affected my project yet because it is still not incorporated into my own save system and mostly served as a logging which I thought was decent enough for my localbuild, to transform it to a online db schema is my final goal for the game with a login system so this will need to be fixed in the near future!

Finished testing and debugging caocaos rare cards, found a few errors related to targetting, will probably need a clarification patch for mechanics in the future. Also added a button for activation of the passives or quirks for caocaos influence mechanic

I will have to integrate another 67 cards and verify for Liubei to check for bugs now

Finished testing caocaos uncommon cards on enemies to see if the tests would conflict or lead the engine astray! Each new card was tested on merchant rerolls + buying, damage+ shield calculation, DOT effects and against other cards which will take long and longer as we get to sunquan since he has a LOT of DOT effects. Tested around 40 ish cards! Again, i can only post the code because the checks are done manually. I have been thinking of some DOT reworks since they seem a bit weak

SIKE! Another expansion and singular testing of caocao cards to ensure that they work with the system + integration for rarities, no output here other than the code itself, i am checking one by one to ensure that the new mechanics work as planned

This should wrap things up since I will likely either continue the project on Macondo or in the future when I get an artist to draw cards for me, its been a good sprint! Happy voting!

Undocumented for my last ship but I updated the UI!! Probs need to work on resizing assets next

Updated menu from feedback, gonna make the assets a bit bigger

Added another card expansion and gave buffs + interaction to caocao and liubei as well as added tutorials for players, Commander is used as a placeholder for login ID later when i create a login system for the system to be hosted on . This was done on ‘Physics engine’ as an addon to the project albeit me not pushing any changes since I only had my laptop with me because I was visiting grandparents and was writing the code and found out I wasnt on the correct repo halfway

Increased font size for ease of reading
Changed the chinese text for copper currency from mandarin 铜钱 to a 🪙for better communication
Also merged the topbar and the dialoguebar when it shows up
Fixed another story sync issue

Changed relic mechanics to drop RNG instead of be event based
Also added glossary for users to read mechanics (scroll wheel broken idk why), probs have to fix it next

Another fat devlog but basically I have been working on the cards as well as the implementation… its on lapse! Please check and see if it is valid since I technically didnt use it but it will be implemented for the future when I have my art assets ready for each card

A bit of a longer dev message but basically in this devlog I struggled with syncing story progress to nodular progress and specific boss nodess resulting in a story time drift where there wasnt really one singular source of truth so fixed this by centralizing everything in a runtime spine, (not SPINE) that acts as the backbone of the story progress

All story beats are now a flat, ordered array per act with hard‑coded columns. But not hard coded map generation.This basically guarantees that every beat appears at a known column on the map, and the map generator can simply stamp them in. and solves my branch mapping problem.

I used a .json schema to basically tie node to json information “id”: “A1_BEAT1_TURBAN_CAMP”,
“column”: 2,
“nodeType”: “event”,
“title”: “The Yellow Turban Remnant Camp”,
“body”: [
“Starving zealots in patched yellow scarves hold a walled granary. They demand safe passage to join Liu Bei.”
],

What this column -2 is the exact map column where the node is forced to appear, the player will always find it regardless at the second column of the app, not the node so the player will always find it and it cannot be skipped. Nodetype is the type of node which is an event node which will always spawn when the player hits the second column. Title and body should be self explanatory!

Okay so i finally changed the mapping schema to be more visible and less confusing, added glowing nodes and made the nodes you traveled to/forgone fade away.

I also rewrote the ENTIRE logic for the maps, now they follow the storyline no matter which path you take, and these storyline choices determine the bosses and ending as well

Working on rewriting the logic, there was a problem where the overlappings would lead to the player going into the wrong room, also path lighting was not done. working on it now and i will update later

https://steamcommunity.com/sharedfiles/filedetails/?id=2830078257 THIS COMMUNITY POST HELPED A LOT WITH MY MAP GENERATION. This is the node generation logic for the rouguelike run

Implemented liubeis prelude dialogue ! As for the assets I havent really implemented them yet! Need to work on enemy mechanics later such as drawing from a weighted pool of attacks! A little backstory on Liubei is that he was a sandal maker during the last years of the Han dynasty, and is really humble. His rags to riches story is based on brotherhood with Guanyu and Zhangfei leading to the Oath of the peach garden. Historically as he dies, he dies controlling a third of China which is a true tale of what a commoner was capable of if he stuck to his ideals which is a theme I replicated a lot in Liubeis character path/node choosing.

Final version 1.5 has been released!
Bugs fixed:
Enemy hp used to be a bit awkward with enemy dying at 2 hp then the reward screen would come
Added backdrops!
Settings still dont work but thats whatever in the roadmap
Need to replace energy symbol with some art as well as the drawpile probably
Cards still need to get replaced

Overall not a bad project for the lockedin Sidequest especially rushing everything. Happy testing!!!

Finally the game looks a hell lot better! Added graphics for UI and dialogue choiecs

Working on card expansion currently, relics have been implemented but I need to find artwork for it :)))

i am also working on different mechanics that the game will use as well for future expansions and will work on card render tonight! This project was pretty rushed because of locked in sidequest but you cant have your pie and eat it too i suppose

Please note that the settings cog is for the future implementations, I also intend on drawing my own cards so you guys will need to cope with the current flat generated ones with an emoji. The games resolution is a bit blurry but still readable, Ill try to tune it but I think its a problem with the phaser pipeline with graphics render. As of now I will be submitting it for the locked in challenge so the game is only playable until the third combat where you wont be able to progress due to the relics not being fully implemented which will be my next job. Happy testing! Feel free to leave feedback!

Prototype is done, frantically looking to get it shipped in the next hour for lockedin for the prototype! The game is NOT finished

Omg the nodes are working!!!!!!!!!!!!!!!!!!!!!!!

Used AI to generate the fallback mechanisms for the intent UI that describes the enemies next move

Finished writing the future “Chaos engine” so tldr it aggregrates everything in the game, such as Runs, style of run, character etc as well as choices and relic draw which will shift and balance the game accordingly for modifiers so we will have an ever evolving game, currently it is not in practice since I need to finish the vertile slice for my lockedin and is uncommented

Working on the UI and some placeholders, this is the art i will be using but phaser is having some issues retaining the resolution so i will need to troubleshoot

• Wrote map node creation logic and baselines
  -Wrote status effects and when it will tick such as owner turn end or owner turn start
  -Wrote the card containers which I want to substitute for a template PNG later on
  -Refactored effectqueue logic so we have priority for status effects such as DOTs
  -Also did some UI changes, as well as damage numbers popping up on the screen
  -Coded the relics to be added, as well as their effects and a few placeholders for future work
  made the sprite appear in the battlefield, but I need to calibrate the 2d platform for presentations sake as well.
• Used AI generated code for the typescript for the Spine36 bridge since there isnt one on the market for plugins for phaser 3.0 and I am really not familiar with how art assets react with the SpineBridge so um yea AI was used for debugging and finding a way for the sprites to appear on the screen without breaking the game

Very very hasty but im trying my very best to devlog, especially with how my other project got called out by fraudsquad for some reason and took away all of my cookies wtf

Wrote character definitions and their passives but have yet to enforce them

Okay ive been wrestling with a few problems

1. Resolution, I am on a 2k monitor so for some reason the graphics are really blurry so im gonna need to fix that
2. Debugging scripts will need to be made to address point in 1
3. This might impact my sprites which I would like to be as polished as possible

As for what has been done in these hours

1. I have finished the save system which saves the state of the game and player information for each run down to the second which may not sound like a lot but this save system logs everything such as rewards, relics, skills chosen, path etc etc so its really good for returning players if they would like to optimize their runs!

Today Ive been locking in a lot so for todays session so far I wrote the save logic and the persistent seeding logic as well as fixing viewport so it looks clearer on different monitors since mine is 1440p and it was a bit blurry so I coded it to fix viewport, its now a loooot more clearer. I also made it so that the pen drawing will persist across the same playthrough

Wrote all of the save and debug logic since that is the core foundation of what is required for the system, not much like always but its the core integral of the game. As the game gets more developed i probs need to add more atomic saves but for now this will do. I would say that I have a somewhat playable version of the game but will release screenshots later once I am done exporting the SPINE assets to phaser via the bridge.

Wrote the event system, the event outcomes and the skeleton rules based AI for user pathing which basically classifies nodes as pathBias?: ‘safe’ | ‘greedy’ | ‘aggressive’; and then depending on what the user picks, the system reacts accordingly. I also added debugging, and added the rewards interface imports for stuff like gold, cards, relics that may pop up after selecting a node. Now i will be working on the chronicle which is the “backend” that I want to transform much later where players playing as X charcacter choose more of X choice/ending/death transform the overall game to make it always spicy. I really dont have an image to show atm since its the structure so :/

Going for lunch now so tldr today i made type definitions for character, then i made status definitions which are buffs and debuffs, might wanna add more in the future so I coded it in a very modular way as well. I also added a rules based “AI” system which i wanna develop more in the coming few days so the enemies will have a depth of personality

Finally back after my surgery and writing index.ts and defining game mechanics and effects such as sunquans fire mechanic, liubeis tide mechanic etc

Finished character mapping from character JSON to the uhhh each character, ill have to map the animations next to json for communication for the handler to API

EDIT: OH MY GOD MY ****** DIGITAL ASSETS ARE NOT COMPATIBLE WITH THE VERSION OF SPINE AND I DONT WANNA FORK 70 DOLLARS OUT WHAT DO I DO
EDIT2: THE SPRITES ARE NOW LIVE SO THIS WILL BE V0.1.0
EDIT3: I SPENT ABOUT 20 ISH MINUTES TO AN HOUR SETTING UP JAVA TO PORT MY PROJECT OVER BUT DIDNT DO IT BECAUSE I COULD FIND A WORKAROUND FOR THE SPINE ASSETS!!!!!!!!!! Idk if this is considered fraud because I was working on the skeletons and figured out I could “try” to get the assets exported

Writing .json for the SPINE manager to map the digital assets to charactres and to map the animations to an action such as playing a card

Apparently spine(which is a rigging software) isnt tracked so im kinda sad but this is a prototype i have from my cousin who is an animation artist! Focusing on exporting them now!

Edit: This was the free software and I couldnt export it until i got the paid software which is in lapse

I used AI to generate the spine plugin code for the bridge since I have no idea how SPINE assets work with phaser :// (ofc i reviewed the code and made tweaks to it)

Finally managed to create a draggable map that you can zoom and then also draw, something inspired from slay the spire to remember the paths you wanna take. I also made a topbar layover which displays stuff like health, currency, relics etc

Updated the map with symbols! Pity that time isnt tracked here otherwise, this is only for linear progression for the prologue at this current state.

Finished with the map progression! I wanted to use unity but it was incompatible with my current phaser and typescript stack so this will have to do, it is in one line since this is the prelude which serves as a linear introduction to the character you have chosen, again I am using placeholders, will likely put images inside from one of the open sourced image repos

Fixing the map progression, wanna input a graphic scroller similar to the one from STS but i am unsure if it is compatible with the current typecript and phaser implementation (PLaceholder, will update when i have fixed the map)

Writing hand mechanics as well as graphical reprsentation rn, its kinda hard to get the math right with the curvature

Coded logic for zone drag and drop acceptance and reject logic + graceful reject

Mostly working on cards and how it shows up in the hand with the umbrella curve and how it reacts, for example drop zones on yourself and enemies

Wrote some design cues in my master direction markdown doc as well as wrote a new mechanic im working on which is :Exhaust which renders an overused card useless to make spammers not be able to thin out their deck to use OP cards

Writing card containers right now, will probably want to migrate it to a jpg format or something because i SUCK at art. Will use emojis as placeholders for now

Wrote the starting card decks for CaoCao Liubei and SunQuan in typescript! It follows a centralized structure where all of the cards will be sourced from index.ts. This follows a typical slay the spire deck starting formula. At the time of updating this 13 days later, there has been 3 or so expansions and reworks of cards and passives

Wrote liubei cards! will elaborate later! BUT tldr there willbe different cards contained in this centralized format and also some sort of passive mechanic which I will need to write and consult the lore document for

Currently I am writing cards that will go into liubeis deck, its a really long process icl but tldr its just a similar json format which allows me to keep it all centralized in one file, im not sure if this will have to be rewritten in another language if i were to port it to a fully online system

Finished making caocaos basic deck and now thinking of upgrade camp nodes on the map where you can upgrade a card to ‘plus status’ like in STS

Wrote a bunch of ts for caocaos “deck” and what I envision the gameplay to be, I am aiming for something similar to slay the spire in terms of mechanics and a RPG/alt history outcome that depending on what choices you make, your deck will evolve and so will your fictional endings will occur!

Fixed a lot of issues and added multiple extra features for the .exe file as well as updated the readme for the complete workflow of new features. Test cases were also made as well as changes to the math and the cryptography algorithms coded in the project. Happy testing!

Wrote up the skeletons as well as the layout of what I am envisioning for the game as well as a centralized lore document

Finalized everything, updated the CLI and added more functionalities, removed subscripts and updated the readme, basically delinting before shipping for review! Also note that bigger PNG files that are more clear will also take a longer time to get decoded :>. Currently the ASCII will be converted to a scannable PNG of the QR code instead since the resolution is not really clear even with the Reed

Tested all functionalities, and tested my test cases and everything works PERFECT! Probably have to do some touch ups on the CLI because i forgot an interface for the subcommands and other functions like signing messages digitally and HMAC challenge and response

Moved into QR code generation and this ended up being way deeper than expected because I didn’t use any libraries. Basically had to rebuild the entire QR encoding pipeline from the spec.

Started with understanding the format itself. QR codes aren’t just random squares, they have strict encoding modes depending on the data type, plus different versions that control grid size. Also had to choose an error correction level, which determines how much of the QR can be damaged and still recover the data. I went with higher correction because this is for keys, so reliability matters more than density.

Then came error correction which is where things got really technical. QR codes use Reed Solomon codes, which operate over Galois Field arithmetic instead of normal integers. That means addition becomes XOR and multiplication follows polynomial rules modulo an irreducible polynomial. I had to implement finite field multiplication manually, bit by bit, shifting and reducing using the field polynomial. This is the kind of math that looks simple on paper but is extremely easy to mess up in code. One wrong operation and the entire QR becomes unreadable.

After generating error correction codes, I had to interleave the data and parity blocks exactly as specified. This is not just concatenation since the bytes are arranged in a very specific pattern to distribute redundancy across the QR. Then came placing everything into the grid. QR codes have fixed function patterns like finder squares, timing lines, and format bits that all have to be placed at exact coordinates. The actual data bits are then woven through the remaining space in a zigzag pattern. This part felt like solving a binary puzzle where every bit position matters.

Finally built the rendering layer. Took the binary matrix and mapped it to Unicode block characters so it can be displayed directly in the terminal. Had to make sure spacing and proportions stay readable in monospace fonts, otherwise scanners won’t pick it up. The end result is a fully scannable QR code rendered as text, carrying cryptographic key material with built in error correction.

At this point I’ve basically reverse engineered and reimplemented QR encoding from scratch, including finite field math, error correction, and layout logic. No external libraries, just pure Python and elbow grease hah!

Moved into export and interoperability, basically turning raw keys into formats that real systems actually understand instead of just bytes sitting in memory.

First was PEM and PKCS#8. That meant taking the private key, wrapping it in ASN.1 DER structures, then base64 encoding it with proper headers like BEGIN PRIVATE KEY. Sounds simple until you realize Python doesn’t give you a native DER encoder, so I had to manually build the structure byte by byte. Length fields, type identifiers, all that low level encoding. Once it worked, the key could be dropped straight into OpenSSL or SSH tooling which is a huge step from just having raw entropy derived keys.

Then I implemented OpenSSH format. This one is more structured than it looks. There’s a magic header string, followed by fields describing the cipher and KDF. I supported both unencrypted keys and the structure needed for passphrase protection using bcrypt as the KDF. The final output matches what OpenSSH expects, meaning the keys generated from an image can actually authenticate against a real server.

Added JSON Web Key support next. This is more for web systems and APIs. Keys are represented as JSON with fields like kty and then base64url encoded values. I also added custom metadata fields so the key carries context about where it came from. It’s basically making the same deterministic keys portable across web based systems.

Then I somewhat built the QR code output which is probably the most fun part. Took the public key, encoded it into a QR matrix with error correction (super proud of that too btw), then rendered it directly in the terminal using block characters. Even if part of it is damaged or cropped it can still be recovered because of Reed Solomon encoding. So now you can literally scan a key off the terminal screen which is really convenient :).

Also added a raw binary format for internal use. Just the key bytes with a checksum prefix in big endian. No overhead, minimal storage, fast to read and write. This is what everything else builds on top of.

On top of all formats I added metadata tracking so keys aren’t just anonymous blobs. Each key now carries a timestamp of when it was derived, the exact derivation path used, the hashing algorithm, the original image source, and orientation data so the same image always maps correctly. There’s also a checksum field for integrity verification so corrupted keys can be detected immediately.

Basically wrote a few tests for my program to debug and managed to generate my first QR code from native ASCII

Today I basically implemented RFC 8032, Ed25519 , EdDSA signatures in pure Python and coded the edwards curve (in its twisted form) from scratch where it was basically

Curve equation: -x^2 + y^2 = 1 - (d)x^2y^2 where d = -121665/121666
Complete addition formulas (with no exceptions for point-at-infinity)
Fast doubling and addition with optimization
Did I mention it was all from scratch btw :)
I also did point decoding and encoding

32-byte encoding of points (64-bit y-coordinate + 1-bit x-sign)
Bit manipulation for sign recovery and reconstruction
Little-endian encoding per RFC 8032 standards which I studied overnight :/
Then I also implemented SHA-512 Hashing where I decided to use pythons hashlib which is just one external dependancy, and also created the 64 byte digest creation and did the prefix and nonce clamping for deterministic signatures.

I also wrote my own signature verification module down below which I am super proud of because the math involved was on another level! I hope this project gets high cookies because this project is super technical!

Moved into the actual crypto primitives and this is where it stopped being “deriving keys” and started being building real cryptographic functionality from scratch

First was Ed25519 key generation. Instead of generating random keys, I’m feeding in 32 bytes from the HKDF output, so the entire keypair is deterministic from the image. Those 32 bytes become the seed, then I process it. So tldr it means hashing it, splitting it, and clamping the private scalar so it fits the curve requirements. From there I do point multiplication on the Edwards curve to derive the public key. End result is a full Ed25519 keypair that can be regenerated anytime from the same entropy source. I also keep both the processed scalar and the original seed so nothing is lost and everything stays reproducible.

Then I implemented X25519 Diffie Hellman which is a completely different curve form but built on the same underlying math. Here the private key also comes from deterministic entropy, gets clamped according to RFC 7748, and then used in scalar multiplication against the base point to produce a public key. The key detail is using the Montgomery ladder which keeps the operation consistent and avoids leaking information through timing differences. Everything operates on the x coordinate only, which simplifies things but also means you have to be very precise with the math.

Once both sides generate their keypairs, the exchange is straightforward but kind of insane conceptually. Each side sends their public key, then uses their private key with the other party’s public key to compute a shared secret. Even though both sides are doing different calculations, they land on the exact same 32 byte result. No secret is ever transmitted, it just emerges on both ends independently.

That raw shared secret then goes back through HKDF to normalize it into usable key material. So even the output of the Diffie Hellman step gets structured the same way as everything else in the system.

At this point the system isn’t just generating keys from images anymore. It can produce signing keys that follow real standards and also perform secure key exchange almost like, dare I say like modern messaging protocols. All of it deterministic, all of it reproducible, and all of it built directly on top of the entropy extracted earlier.

Next part was building the actual entropy source from images, specifically PPM P6 files. The goal here was to turn an image into a reliable stream of randomness without doing anything sketchy or lossy.

PPM P6 format imo is perfect for this because it’s basically raw RGB in binary form. No compression with no weird encoding layers, just a header and then straight pixel bytes. So I wrote a parser that reads the header, extracts width, height, and max color value, then pulls the pixel data directly. I had to be really careful with how the bytes are interpreted because you’re dealing with raw binary, so if you mess up ordering or offsets everything downstream becomes garbage, this iteration took maybe 1 and a half hours +- including testing.

Once I had the pixel data, I didn’t just dump it directly into the system. I experimented with multiple ways of extracting entropy because raw pixel data can have patterns depending on the image. The simplest method is just concatenating all the bytes, which gives you a big pool of data but might include bias if the image has large uniform areas. So I added diagonal sampling where I only take pixels along certain paths across the image to reduce structured patterns to make the input much less predictable. Then I implemented somemixing like XORing segments and generating checksums to break up correlations and spread entropy more evenly.

Also added some guardrails so the system doesn’t accept garbage input. There’s a minimum image size requirement, around 96 by 96, because anything smaller just doesn’t give enough entropy to be meaningful. That ensures we’re working with at least tens of thousands of bytes instead of something tiny and predictable which should be the basis for entropy.

Another thing I accounted for is reproducibility. If someone rotates or flips the image, the raw byte order changes, which would produce completely different keys. So I track orientation metadata so the same logical image always maps to the same entropy regardless of how it’s stored or displayed, this took me quite some time ~ 2 hours

Finally added checksum validation on the file structure to make sure the parser isn’t silently accepting corrupted or malformed files. If the format isn’t exactly what’s expected, it fails early instead of feeding bad data into the pipeline and notifies the user.

At this point the system isn’t really grabbing bytes from an image, it’s actually treating the image as a structured entropy source with validation, normalization, then creating keys from them which I am super proud of!

So basically in this devlog I have created the failback systems in case my python homebrew implementation could not handle the requiremements after a given time of processing.

I did:

• Try-except pattern for cryptography library import
• Fallback to library implementations
• Automatic performance testing for future metrics
• Transparent API - consuming code doesn’t know which backend is used

I also did some benchmarking and I found out that unsurprisingly
Ed25519 Signature Generation:
My implementation of pure python: ~4.5ms per signature
With cryptography lib: ~2.2ms per signature
Improvement: 2.4 with the cryptography lib but its essentially unnoticable by the average human

X25519 Key Exchange:
My implementation of pure python: ~3.8ms per scalar mult
With cryptography lib: ~1.8ms per scalar mult
Improvement: 2.11x

Hash Computation (HKDF):
Both: ~0.85ms (Python hashlib used in both)

I also implemented a graceful degredation process when cryptography is unavailable. Its just way too technical and complicated to talk about in this limited character pool :/

First thing I implemented today was HKDF based on the RFC 5869 standard. At a high level it’s basically a two stage pipeline that takes messy entropy and turns it into clean, structured keys. The extract phase takes whatever entropy I got from the image and runs it through HMAC with a salt.

This step is really important because raw entropy isn’t always evenly distributed, so this compresses it into a fixed, high quality pseudorandom key. Think of it like taking noisy input and normalizing it into something cryptographically usable for our use case scenario yk.

Then comes the expand phase. Instead of just producing one key, I can stretch that extracted key into as many bytes as I want. It does this by repeatedly running HMAC in a loop with a counter (self implemented btw) and then chaining outputs together. So I can deterministically generate multiple keys from the same source without ever touching randomness again. The “info” parameter is the key detail here because it acts like a label. Different info strings produce completely different outputs even if the base entropy is identical. That’s how I enforce domain separation, meaning one key can’t accidentally collide with another use case from almost the same image per se.

After that I built a fully native BIP32 style hierarchical system on top of HKDF. Instead of just getting one key per image, I now have a full tree of keys derived from a single seed. The image entropy becomes the master seed, and from there I can derive paths like m/44’/0’/0’ or m/44’/0’/1’. Each step in the path feeds into HKDF again using a path specific info string like entropygarden plus the path itself. That means every node in the tree is cryptographically isolated but still deterministically linked back to the original image.

What this really means in practice is that one image can generate an entire structured key hierarchy. Same image always gives the same tree, but different paths give completely different keys. So now there is no abstract randomness, no storage needed, and everything is reproducible on demand. It’s basically turning an image into a deterministic key generator with infinite branches which would mean that it would be unguessable from an adversaries perspective, while being fully reproducible by someone you want to share with key with!

What I did today : Implement Montgomery curve arithmetic without external libraries all the way from scratch which required me to look up the math for it and implement it in python logic.

I also implemented field arithmetic*(Modular Prime Field 2^255-19):

• Custom integer operations modulo prime p = 2^255 - 19
• Inverse calculation using Fermat’s Little Theorem which isx^(p-2) mod pand widely used in cryptography
• Efficient modular reduction (avoiding slow Python to ensure the program stays snappy//)
• Constant-time operations to prevent timing attacks in a realistic scenario

Then as I stated before, I also implemented the Montgomery Ladder(Key Exchange) where basically:

• Scalar multiplication algorithm: k·G where k is secret, G is generator
• Differential addition and doubling on Montgomery curves
• Handling of cofactor and special points

I have also studied clamping and what it does and how to implement it to the standards of RFC 7748

• Scalar processing prevents small-order attacks
• Bit manipulation logic in python to clear lowest 3 bits, set bit 254, clear all bits > 255

Overall it might not seem a lot but there is SOOO much math involved and a lot of trial and error

Finished my project for the locked in challenge, I am aware I did go over the 10 hour mark for devlogs though but it was a lot of work and I did not want to do much context switching.

Built CommitForge during a hackathon-style sprint which is a CLI tool that scans your repo, tells you what you’re about to commit, catches obvious mistakes, and suggests a proper commit message, all in one command. I started by setting up a clean project structure and locking in core dataclasses early so everything stayed stable. The initial version had multiple commands and worked fine, with config loading from .commitforge.json and about 29 tests passing, but the output was useless since it just said files changed. I rewrote the analyzer to actually parse git diffs, so it could report meaningful changes like added functions, then added checks for debug prints, TODOs, secrets, and missing tests, plus a clean HTML report that opens automatically.

On the second day, I focused on usability issues. The tool wasn’t scanning untracked files, which is when you need it most, so I fixed that. Commit suggestions were also bad, so I improved them to follow proper Conventional Commits like feat(auth): add password validation. I reduced noise by only analyzing changed or new files and limiting warnings to what actually matters. Finally, based on feedback, I simplified everything into a single drag and click pipeline. I removed unnecessary features like the GUI and overly granular checks, cleaned up the codebase, and ended with 39 passing tests. Tested it on a random project, got clean and useful output, and shipped it.

My objective of this project is to design a system that derives cryptographic keys deterministically from image entropy, enabling “visual key generation” where visual chaos in bytes becomes cryptographic order.

The stuff I identified as key challenges:

• Converting unstructured image pixels to cryptographically secure entropy
• Implementing elliptic curve cryptography without external dependencies (probably wanna self engineer this because why not)
• Supporting hierarchical key derivation (BIP32-style)
• Multiple export formats for interoperability (maybe QR implementation?)

Pre learning that I probably have to do :

• RFC 8032: Ed25519 signature scheme analysis (Section 5 - curve arithmetic)
• RFC 7748: Elliptic Curve Diffie-Hellman (X25519) Montgomery ladder
• RFC 5869: HKDF key derivation specification
• NIST recommendations on entropy extraction
• SSH key format specifications (RFC 4251, RFC 4253)
• JWK (JSON Web Key) RFC 7517 requirements
• QR code error correction (Reed-Solomon codecs)

So likely this is what I have to do :
Layer 1: Image Entropy - PPM file parsing, pixel extraction
Layer 2: Key Derivation - HKDF-SHA3, hierarchical paths (m/44/0/0/…)
Layer 3: Cryptography with Ed25519 signing, X25519 DH, Curve25519 math
Layer 4: Export/Use - PEM, SSH, JSON, JWK, QR, Binary formats