animesh_varma

woooo, I forgot to write a devlog, guess it will show up after my ship… Oh well

anyway, so flavortown just ended and I managed to slip in my ship exactly 2 min before it did…
I am so filled with adrenaline now I can’t express ittt

also the worst possible thing happened before I was about to the ship (~15 mins were remaining to the deadline), I realized I hadn’t cleared the 15 vote vote deficit from my last ship of another project and had to provide 15 comprehensive reviews in lest then 15 mins, to say it was a trip through hell would be an understatement (but don’t burn me. I still provide valid feedback to people, just mostly positive as I had no time to critique their work…), and that is the story of my very weird ship! ;(

anyway, as i said in my ship, the project itself is pretty easy to use, if you don’t understand something, please feel free to mail me now with that out of the way, attached here with are some screenshots from the demo script, enjoy!!!

[also, for some context, the video pre-processing is required as V-JEPA is pretty strict about what it takes in and how long it should be to yield optimal results, the bounding box for the frames is resizable as if you increase its size it, the extract is downsampled so V-JEPA can ingest it…]
[can you tell I am burned out, is my speech coherent? NVM, please refer to the readme if you need to understand it better… sorry again…]

Whewww, the final night before the deadline!

I just finished running the absolute final physics metrics on the new 50K-sigma model I spent the last 4 days training. And guess what? It turned into a complete coward!

Let me explain… To fix the “gravity bias” I talked about in the last log, I trained a new model that completely ignored angular orientation and used standard sigma, not my (potentially) novel crescent curriculum. It turns out, by removing that penalty, the network just took the easy way out. It parked its prediction right in the geometric center of the box and refused to move. It played it way too safe to actually track the physics, also while the actual avg prediction was parked in the center the heatmap covered the entire object edge to edge making the prediction pointless (img attached).

But here is the crazy part: when I ran a custom “Physics Capture” script to evaluate the vector distances, my original 50K Crescent model emerged as the undisputed champion. Despite the occasional bimodal split, it actually pushed its prediction away from the geometric center and consistently tracked the true hidden mass. It earned its accuracy through real physically grounded directionality, not just guessing the middle or flailing wildly like the baselines! [even though the 1K crescent and the resent baseline beat it there they suffered very badly in other metrics making the 50K-crescent only the one to service “well enough on all of them”, and of course its predictions look so cool and dynamic :)]

So, the original 50K Crescent model is officially the SOTA (it is now but I don’t know for sure still, dont know what I uncover when writing the final paper)! I am spending tonight doing a massive cleanup of my GitHub repo [deleting gigabytes of local logs, fixing hardcoded paths, and backing up all the weights and datasets]. I’ll whip up the final README tomorrow morning and hit that SHIP button right before the Flavortown deadline (I am in IST so adjust that accordingly).

See you on the other side!
[again the attached img is of the sigma 50K model just guessing the entire box just to be safe…]

Whewww, 23h 12m logged! Truth be told I didn’t believe that I would make STATERA presentable in time before flavortown ended (less than 2 days left yikes), but here we are, with a single devlog for 23h 12m no less (as I said I never expected it to be completed in time)!

So what is this massive project? STATERA (Spatio-Temporal Analysis of Tensor Embeddings for Rigid-body Asymmetry) is basically a zero-shot physics engine inside a neural network. It watches an opaque box tumble in the air and mathematically calculates exactly where its hidden internal center of mass (CoM) is, just from the raw video.

What have I been doing for 23 hours? Fighting physics and neural networks. I generated 50,000 simulated tumbling videos to train a frozen V-JEPA vision model on my single RTX 5070 Ti. I had to build a custom 2.5D decoder and a mathematical extraction pipeline using OpenCV just to track the physics accurately. (and yes obv the training time is not in the hours of work, hackatime sends heart beats only when you’re actively coding… the cumulative training time including all the ablations is well over 2 weeks!)

The biggest challenge yet? The model actually overfit to gravity! It learned a “Settling-State Bias” where it realized heavy things usually face the floor when they land in the simulation. So when I tested it in the real world in my bedroom and the box bounced with the heavy side UP, the network’s brain literally split in half trying to decide between the visual bounce and its gravity bias[I call this Visual-Kinematic Aliasing for now]. Fixing this math by changing the training curriculum to a phase-agnostic gaussian dot took some time (but nothing compared to the time it took to come up with the previous 50K curriculum which failed with the bias. It used a crescent target that forced the model to learn angular orientation, which accidentally taught it the gravity trick)!

What’s next? The final 50K model is finishing its run tonight around 9pm. While that finishes, I am going to build a slick local web UI for the demo so you guys can just upload a video and watch the physics tracking happen live. See you in the next devlog! [the attached video shows the last 50k model splitting up its prediction as it fights internally between the face it thinks is correct from observation and the one which is facing down which it learned to be correct most of the time. The crosshair is the actual ground truth from my tracking and you can see where the model thinks the CoM is from the heatmap density! I have 76 such videos as my real-world validation test. Also did I mention I would be releasing a 50K benchmark for other people who want to test on my baseline? I do also believe that the accuracy will scale beautifully with more compute, which I simply don’t have right now (fun fact, each 50K run takes around 4.5 days to complete and a 1K run around 6-9 hours on my 5070ti i.e., also the 50K dataset alone is over 200GB!)]
(also the first one it where it splits and the wrong face wins, and in the second one, the correct one was selected, you might also think it is guessing which face and is bound to get it correct 50% of the time, but the other 74 runs not shared here make me believe otherwise…)

Whewwww, itsss finally donee (the PoC at least…), I will be shipping the project really soon, as for the changes I just polished up the setup script, tested it to make sure it runs on both linux and MacOS, and recored the videos for the README
[the img is from the testing video…]

Whewww, finally managed to make the audio in ESP32 barely work, the audio comes out fragmented but is finally legible, so that’s a win…I guess!!
Anyway now I am working on polishing the repo, making the setup work correctly, drafting a readme and setting up some demos for the same, see you soon in the ship!!

Well first of all, welcome! this is the first devlog I am going to write completely myself without the use of any AI, so please excuse any grammatical or spelling mistakes as I am going to make quite a few of them. anyway that’s besides the point, the thing is I have been working on a new project for quite some time [as you can see, around 12 hours logged]. Now, why were there no devlogs in that time? The thing was that 2 of my friends had committed to building this project together and I was waiting for them to join, and as it was not my own project I decided against putting it on flavortown, but guess what… they both bailed on me (hence the project then being posted here, rest assured all the commits were by me)! 
Anyway, eidolon is ment to function as a bridge to allow you deploy a live AI model [full duplex to be exact] as your personal assistant which can send and receive phone calls on your mobile device on your behalf. It functions by using the host to set up a Bluetooth HFP that a mobile considers as a headset and sends audio to, as it can send and receive audio, it can interact natively with the call.
Anyway curuntly its in very early PoC stage where I have just made the linux version working correctly [macOS version is also in its final stage of the PoC but will not work as intended because of kernel level constraints]. I am curruntly working on the esp32 version [ohh did I mention I will use the esp32 I bought from the shop to expand it to work without any desktop devices, its going to be sooo flipping cool!!]
also also, curuntly the linux and any other working version just have a basic TTS and STT implementation ment to function as a PoC, in the next (first ship) ill push all the working versions of it [esp32, linux, windows n mac] with the PoC TTS and STT. after it is done I’ll begin to work on actually implementing a live AI API [prolly openAI as I can get their credits from the shop and they are the only ones which provide a live API]
Also did I mention Eidolon will also have a mobile app operating over wifi to share live data about calls like transcription, what the agent is saying and providing the ability to guide it? again, it’ll be sooo fun, can’t wait!! [the attached screenshot is from the CursesTUI which I am using in the PoC working on linux (and me connecting to my pixel 9 and testing it with a call, also debug flag was set to true hence so many logs)!]

First off, a quick apology and clarification! 😅 I know there was some confusion regarding the version tags in my last devlog. To clear things up: I reassure you that all dev versions following v0.4.5 are correctly labeled with the 0.5.0-devX base in the dev branch. The math schema holds strong!

Now, onto the fun stuff. I just merged a massive PR for v0.5.0-dev3, and this one was an absolute beast to build. Remember that “Zero-Trust Screen Shield” I mentioned was breaking native dialogs in dev2? I finally beat it into submission!

The “Zero-Trust” Screen Shield Architecture:
Standard FLAG_SECURE is great, but it’s easily stripped by Xposed/LSPosed modules or malicious root apps. I built a custom, highly resilient alternative to aggressively protect the UI state:

Reactive UI Blur & Native Recents Defense: When the app loses window focus (like pulling down the notification shade), it triggers a Compose blur. For the OS Recents menu, I implemented a synchronous native FrameLayout shield during onPause to block snapshots entirely, defeating OS-level FLAG_SECURE strippers.

Capture Detection & Anti-Tapjacking: Added DETECT_SCREEN_CAPTURE to actively log hardware screenshot attempts (and clear the clipboard if it detects one!). More importantly, I enforced filterTouchesWhenObscured on the root view. If an invisible or malicious overlay tries to hijack your taps, Sigil drops the input entirely.

The Current Struggle (Why this took so long):
The challenges on this one were endless. The shield conflicted profusely with in-app dialogs. I initially tried engineering a system that treated the shield screen itself as a dialog with the highest precedence. Spoiler: It was a disaster. It was incredibly unreliable, completely messed up the Android lifecycle, and wasted a lot of my time.

I ended up scrapping that approach and building SecureAlertDialog and SecureDialog wrappers globally via SigilUiElements.kt. This whitelists legitimate in-app dialogs safely without compromising the underlying shield layer.

I’m packing up the APK now. The dev build is dropping right after this!

I’m taking a quick breather from my other projects to drop a brand new, wildly ambitious app! Meet Appraise!!

Appraise is a gamified camera app that turns the mundane real world into a massive, globally deduplicated collectible RPG. Point your camera at everyday objects to instantly extract them from reality and add them to your personal digital catalogue with procedurally generated stats and rarities! It isn’t just a scanner; it’s a collaborative project aiming to build a global encyclopedia of everyday things, complete with a creator economy for artists who claim and illustrate the items you find (not the AI slop you find these days)!

What did I make?
Before I can turn real life into a game, I had to figure out how to make real-life objects actually look pristine and cool. This v0.0.1 Proof-of-Concept is entirely focused on building a premium visual extraction pipeline:

1. The Extraction Engine: I hooked up Google ML Kit (via Play Services) to instantly identify and extract the primary object from a live CameraX preview. I also had to made the pipeline to support modern Android 15 / 16KB memory page architectures to stop native hardware crashes on newer Pixels!
2. Strict Subject Isolation: AI models can be messy and highlight background artifacts. To fix this, I cooked up blazing-fast, custom Kotlin Flood-Fill algorithm that isolates the single largest contiguous visual mass, completely deleting stray pixels and enforcing a “one-object-only” rule.
3. Dynamic VFX Compositing: The UI isn’t just an image slapped on a background! Using GPU-accelerated BlurMaskFilter passes and SRC_IN blending, a massive neon glow visually “bleeds” through the edges of the object. It perfectly occludes real-world light reflections and imperfect AI jagged edges!

This project is my absolute first foray into something that actually requires me to handle complex backends and APIs, so it’s going to be a massive learning curve!

Repo is public, but APKs are GitHub-only for now while I build out the backend and iron out the bugs!

[BTW the attached screenshots give a quick look at the final edge-blending math!]

I mentioned in my last Sigil update that I’d be dropping a brand new project soon… well, here it is! Meet Atropos!!

In Greek mythology, Atropos is the Fate who cuts the thread of time. I thought that was the perfect name for an open-source, continuous rolling-buffer camera! Think of it like a personal dashcam for your phone. You leave the app open, and it continuously records, auto-deleting old footage so your storage never fills up. When something cool happens, you simply cut and save the exact moment you need!!

This log covers the absolute birth of the app from an empty Activity to the v0.0.3 PoC Alpha!

What did I make?
I built out the entire core MVP pipeline across three rapid-fire versions:

v0.0.1 (The Engine): Built the CameraX rolling buffer and the Material 3 UI. Because leaving a camera app open melts your battery, I built Eco-Mode: after 1 minute of inactivity, the app physically unbinds the screen preview and plunges into a true-black OLED power-saving mode, while the camera keeps quietly recording behind the scenes.

v0.0.2 (The Seamless Illusion): Implemented the multi-chunk timeline. The app records in continuous 3-minute chunks.

v0.0.3 (Hardware Polish): Added Camera2Interop to bypass standard APIs and natively force Optical Image Stabilization (OIS), 10-bit HDR, and target FPS ranges. Also added a sleek M3 side drawer for quick toggles and pinch-to-zoom!

What’s next?
This is an early PoC Alpha (v0.0.3). The UI controls don’t currently poll hardware availability, so forcing 4K on a 1080p sensor will crash it. I’m moving to a standard Gitflow workflow next, fixing the hardware polling, and aiming for a stable v0.1.0 release soon, but there will definitely be more patch versions before the minor version.

Repo is public, but APKs are GitHub-only for now while I iron out the bugs and add more features!

[BTW the attached video gives a short demo of the app for you to see!]

I had to pause development for my Class 11 finals, but I’m officially back with MASSIVE news!

(Meta note: I actually had to use Gemini to shorten this log because my original draft somehow ballooned to over 3,000 characters!)

I just received an Emergent Ventures Grant! This is funding the huge v0.5.0 Steganography update and a Native iOS Port (just got an M5 Mac & iPhone 15 for it!). iOS dev starts in a new repo soon.

The New Plan: Bleeding-Edge APKs & Atropos
Going forward, I’m shipping every single dev build right here! I’ll link signed APKs so you can test features (and catch bugs) early. I’ll also be dropping updates for my other project, Atropos, alongside Sigil soon! 👀

What’s in the dev branch:

• Crypto Expansion (PR #18): @marek22k requested Camellia-GCM (Issue #15). I expanded our AEAD support and upgraded the “Sigil Chain” to a 100% authenticated 4-layer stack (XChaCha20-Poly1305 -> Serpent-GCM -> Twofish-GCM -> AES-GCM) using a Bouncy Castle wrapper!

• Legacy Theme Fixes (PR #17): Fixed a critical UI bug on Android 11 & below where custom colors caused invisible text. Added smart auto-contrast calculations.

• The Current Struggle (dev3): I’m building a “Zero-Trust Screen Shield” to block screenshots & tapjacking. It’s breaking native dialog rendering, so the PR is currently a Draft while I rethink it. (Check the attached screenshot to see the shield I’m working on in action!)

Community & Stats:

Issue #10: A cross-device decryption bug turned out to just be a KDF mismatch! Resulted in a great new UI feature request.

Stats: 38 Stars (Doubled again with zero marketing?!), 2 Watchers, 1 Fork.

The official public GitHub Project Board is finally live with 16 issues scheduled.

[I will be shipping v0.4.5-dev2 immediately after this post since the build is already 100% completed!]

Okay, I know I said in the last log that “each merge into the dev branch will be followed by a devlog.” Clearly, I lied. I am absolutely terrible at keeping that promise.

I’ve been heads-down working towards v0.4.5. This covers roughly 16h 12m of work, mostly fighting state management and GitHub Actions.

Here is what I’ve been busy doing (shortened caus the 2000-character limit):

I) The Auth Overhaul (Passwords are here!)
I ripped out the old logic for a system supporting full alphanumeric Passwords.

• Dynamic UI: The Lock Screen detects PIN vs. Password and swaps keyboards (Numpad vs. QWERTY) automatically.
• Security: Still backed by TEE and Salted Argon2id.

II) Encryption Profiles
The biggest change. Not everyone wants the paranoid “Quad-Layer Cascade.”

• Raw Mode: Output standard AES-GCM (no metadata) for OpenSSL compatibility.
• Custom Chains: Save algo configs as “Profiles” with custom KDF overrides to switch instantly.

III) CI/CD & Infrastructure
Spent ages fixing GitHub Actions. autobuild failed on Android, so I switched to manual Gradle with JDK 17 to restore CodeQL and Linting.

The Bug Report (Issue #10)
First real bug report! @hulkspec noted cross-device decryption failed.

• The Cause: Likely a feature working too well. Differing Argon2 settings (e.g., 64MB vs 128MB RAM) mean derived keys won’t match. Waiting on confirmation.
• The Fix: Manual syncing for now. Future: embed KDF params or add Profile sharing.

Project Status:

• Stars: 15 (Doubled since last devlog despite no marketing!)
• Watchers: 2
• Issues: 1 (Investigating KDF sync UX)

Polishing final docs now; v0.4.5 is imminent. After that, I’ll be setting up a public GitHub Project Board so you can actually see the roadmap instead of me just rambling about it here.

This first devlog will cover what I have already done for Sigil, as I have been working on it for well over two months (Before I joined HackClub yesterday).
Till now, I have managed to:

1. Keep a very high security standard across the app
2. Pass numuras varifcations [Displayed in README as badges]
3. Set up a CI/CD pipeline along with PR checks
4. Publish the app on IzzyOnDroid and Google Play
5. Implement 15+ algorithms
6. Make an Auto and Custom tab for different levels of users
7. Create a comprehensive onboarding
8. Add TEE and hardware integration with a Keystore tab for keystoreage
9. Implement a release tab
10. Create a settings tab allowing tweaking of encryption parameters and other parameters
11. Add applock with biometrics and custom pin separate from screen lock
12. Allow changing of appearance
13. Screen shield and Clipboard auto wipe

And that about winds it up. This was until v0.4.1 whcih is a Pre-release (Though not marked as such because of IzzyOnDroid publishing guideline, this will be fixed with the release of v1.0.0)

The next release will be v0.5.0 with the following updates:

1. Implement Steganography tab: The Steganography tab will be implemented.
2. Biometric Upgrade: Transitioning authentication keys to AES-GCM.
3. Custom Chains: The “Auto Mode” encryption chain (currently fixed at 4 layers) will become fully configurable. Users will be able to define their own custom cascades of ciphers for quick access.
4. New Algorithms: Implementation of XChaCha20-Poly1305 and Aegis-256 (Addressing issues #3).

I am keeping this dev log just to keep track of changes I made, each merge into the dev branch will be followed by a devlog documenting everything (At least I hope so, as I am the worst at keeping consistent :( )
Sigil currently has: 7 Stargazers, 1 Watchers (Me), and 1 issues open (Add encryption algorithm)