Fox

Wrote a benchmarking program for the traffic speeds in rust! Graph is attached bellow. TLDR of the graph is that with my method we're basically equivalent to the base case (zero filtering) and at some points beats it, which i'm really pleased about! So there's no almost no cost to sniffing packets with the program.

This is sort of a hard project to explain, I am able to detect what browser someone is using before their request even hits the server. No JavaScript. No User-Agents. It's implemented at the Kernel so could theoretically process 26 million packets per second on consumer hardware. I'm doing this with XDP and BPF filters, which is sort of like Java except it has only 256 bytes of ram.

Spent time porting everything into a web app! After shipwrecked I feel its good to try to put everything I possibly can into a web app just so I have an easy place to see my work. I know there's a ton of web dev's here so I'll explain my stack. I learned Ruby on Rails for this! I have a Rails server that's handling most of the actual DB management and that same DB is used for verification on the actual Guthrie server. Rails makes ratelimiting actually breeze so the account management system is getting it before the main TCP server does. If this actually gets integrated in someones stack they'd obviously replace the web interface with a proper one, but for demo this works great. Right now it just generates a random user id and user password, though normally though in proper usage those aren't exposed to the user. UI is bootstrap, because I didn't want to spend too much time tweaking CSS/Tailwind. Also ported uMessage (client to Guthrie) to wasm with emscripten, and I just link that in the Rails app. Still need to hook up guthrie-server to a TCP -> Websocket proxy so it actually works!

A lot of practical work was done this week! I know have SQLite caching on the client side because of the lack of persistence on the backend, this just hooks into the event loop I wrote earlier for the client library so it's really just been connecting the pipes now.

I wish I got some actual functionality done in this 10 hour span before SOM gets mad at me. Nope! Lots and lots of UI design. Clay is great for most things, except for making interactive components. So I spent a ton of this time working on a system for creating working textboxes with cursors and features people expect out of a text box. It's not quite Chrome/Firefox level but its usable, might spin this out into a separate component library since most of this code is reusable.

I finished writing the protocol, so messaging is working. Might want to have a a cache layer if a user is offline. That's my only major addition I want protocol wise rn. CLI client is done, it's of course just for testing but it just about has all the features of the protocol.
I started work on the actual GUI, its completly written in C and C++ with SDL as the actual rendering backend, with Clay for the layout engine. Sort of non-traditional for a interface, most people would tell me to just make a web app and call it a day. The reason I'm designing it this way is so it will comfortably run on a low end phone I have designed with a keypad keyboard. That's a whole separate mess that's hard to track for Hack Club, but I've been designing most of my personal projects to be able to theoretically run on this device. Device is using a 480x480 screen so thats the minimum resolution I've been testing in. There should be a web demo at the end of all of this with a port of the desktop app, but that will explain some of the more eclectic design decisions I have made.
Been prototyping layout and design, as well as making a button component for Clay that will hopefully be able to work with both the mouse and keys on the keypad. Images I've attached is my design goals and the current state of the design.

Guthrie is a high performance, secure, instant messaging protocol. I am building it as an infrastructural backend to replace a system like iMessage or RCS, though it could be used for any system for public facing authenticated messaging.

Whats actually been done so far.
I've written the authentication part with a Sqlite database, and drafted the protocol. I have packet checking in version check to make sure backwards compatibility is implemented from the very first version. I've previously ran into issues with supporting things like protocol extension with past protocols so I hope that I've made it easy enough! With a CLI client and accompanying client library I've been testing and debugging functionality. Eventually I hope to get a GUI made to!