Remington Williams

ARCHITECTURE FLOW

Plaintext zone Ciphertext only HTTP WebSocket Server state

Message text only exists in the green nodes. Everything right of the wire routes the same bytes without ever decrypting them.

Architecture

The first phase of any software project should be mapping out the system design, because poor architecture leads to code that cannot scale. Encryption was safest if message text only existed in the browser, so every message is encrypted before Socket.IO ever touches it.

On the client, CryptoJS runs AES 256 in CBC mode with the room's shared key. Each message gets a fresh random salt, so the same sentence sent twice never looks the same on the wire. The Flask server receives a base64 blob, and nothing on its message path calls decrypt. Every decrypted message is also HTML escaped before it reaches the page.

CONGESTION WINDOW Connection Synchronization TCP Window Expansion

Packet	Time (s)	Flags	Window (bytes)	Phase	Elapsed
1549	37.063134	SYN	65,535	Initial	0 s
1550	37.063215	SYN-ACK	65,535	Handshake	+0.00008 s
1551	37.063231	ACK	408,320	Slow start · 6.2× growth	+0.0001 s
1552	37.063243	ACK	408,320	Congestion avoidance	+0.0001 s
1553	37.066011	HTTP	408,320	Congestion avoidance	+0.003 s
1555	37.070160	PSH-ACK	407,680	Congestion avoidance	+0.007 s
2089	42.461543	PSH-ACK	407,552	Congestion avoidance	+5.4 s
4060	103.421413	PSH-ACK	407,616	Congestion avoidance	+66.4 s
6277	171.830728	ACK	407,872	Congestion avoidance	+134.8 s
7420	199.008157	PSH-ACK	407,680	Congestion avoidance	+162 s
8488	226.723437	PSH-ACK	407,424	Congestion avoidance	+189.7 s
9208	242.683106	ACK	407,424	Congestion avoidance	+205.6 s

15–30 ms Message latency, localhost

25 s Heartbeat interval

1–3 s Reconnection time

5 users Concurrent, all features working

TCP Underneath

To see what sits under Socket.IO, I captured packets of the app's traffic in Wireshark on the loopback interface. The first three rows in the table are the handshake that opens every connection. The client requests, the server accepts, the client confirms, and that final confirmation also expands the transfer window 6.2 times over, per the scale agreed on during the handshake.

The window holds near 408 KB for over 200 seconds with no retransmissions. A steady window means the receiver never fell behind, so data kept flowing without either side slowing down. Socket.IO layers heartbeats every 25 seconds, and watching those pings scroll past in debug mode was when the protocol stack felt concrete.

ROUTER TOPOLOGY

Client Server Room broadcast Direct message

The Office never receives broadcasts sent to The Breakfast Club. That isolation comes from one room filter in app.py, not the transport layer.

Rooms/Routers

The app has no network router, so the server's dictionaries do the routing. A dictionary called active_users maps each socket id to a username, room, and status. A public message goes only to sockets whose room matches the sender's, which turns every room into a multicast group.

A message in The Breakfast Club reaches Claire, Bender, and Andrew at once, while Mr. Vernon in The Office never hears it. That isolation comes from one filter in app.py, not from anything in the transport. Direct messages bypass the filter entirely. The send_dm event skips the broadcast and unicasts to a single socket id, so two people can talk privately without leaving the main room.

Functional Verification & Error Handling Complexity: Medium High

Feature	Test scenario	Result	Status
Public messaging	Send message to room	All users received and decrypted	Pass
Message encryption	Send plaintext message	AES-256 encryption applied	Pass
Direct messaging	Click username and send DM	DM delivered to recipient only	Pass
DM notification	Receive DM while not viewing panel	Red pulsing badge displayed	Pass
Multiple DM badges	Receive DMs from 2+ users	All badges visible with counts	Pass
Status change	Set status to busy / away	All users see updated status	Pass
User disconnect	User leaves room	User list updated correctly	Pass
Connection loss	Simulate network failure	Socket.IO reconnected successfully	Pass

Error scenario	System response	Status
Empty form fields	Alert displayed, submission blocked	Pass
Invalid encryption key	Shows [Decryption Failed]	Pass
User disconnect mid-session	Session cleaned up, user list updated	Pass
Malformed encrypted data	Error message shown, no crash	Pass

Batch Tests

Logged in as members of the Brat Pack across several browser windows, I fed the client a wrong room key, a truncated base64 payload, a hand edited ciphertext, and an empty message. Each one failed gracefully with a [Decryption Failed] notice or an error message, and empty messages never left the form.

I also watched WebSocket frames in DevTools, throttled the network, and cut connections mid session. Socket.IO reconnected within one to three seconds. The direct message badges also fought back, but not as hard. Unread counts live on each client, so I logged every state change until each badge appeared and cleared on cue. I update badges in place so the user list never jumps.

DIRECT-MESSAGE FLOW

Client step WebSocket Unicast by socket id Server state

The server routes an encrypted blob it never decrypts, based only on who is attached to which room.

Direct Messages

A direct message takes the longest path in the app. The sender always gets an echo, but an offline recipient means the message quietly goes nowhere.

The server does store each room's key, to hand to new members. Messages live only in memory and logins are temporary.

If I had more time to keep working on this project, I would add real key exchange, a database for message history and accounts, and stronger authentication for deployment.

Paper knot pieces cut from multicolored craft paper

Knots in Pieces

While hand drawing knot diagrams for research advised by Dr. Jonathan Williams, I noticed that knots could be broken into segments. I initially used this method to speed up my drawings process. We put the pieces to the test, and they built a series of other standard knots. The research received a full year Research Experiences for Undergraduates grant from the Computer Research Association.

The first puzzle was physical. I designed, printed, and cut pieces from multicolored craft paper, then asked users to rebuild a knot from an image. It worked early on, but the layered paper was hard to handle and many shapes went unused, so I reduced the number of pieces.

Methodology

This research followed a research through design methodology, where making artifacts is the main way knowledge gets produced. The research is about both the product and the process of making it, so each prototype was also an experiment.

My second prototype simulated a digital interface in Google Slides. Users saw a completed knot on one slide, then rebuilt it on the next from stacked PNG pieces in an open work area. I ran the play tests over Zoom. The prototype showed promise for a dedicated interface. The tests also let me reduce the set to only two modular shapes, which put the focus on recognizing and manipulating them.

Drag, Rotate, Layer

The third prototype became custom code. JavaScript carried the interaction logic, so users could drag pieces, rotate them with the keyboard, and change their layer order to make one strand cross over another.

The knots were a vehicle for the computational reasoning required to solve the puzzles. I ran iterative user testing and co-authored an 11-page research paper analyzing the performance and interview data.

Participants not only built the knots successfully. They learned the visual language through tracing, shape recognition, and manipulation, and tracing stood out to me as a universal cognitive tool.

AI Crossings

Once the puzzle worked in 2D, the project naturally needed to evolve into 3D. I tried turning my vector diagrams into 3D models in Adobe Illustrator. In 2025, Adobe introduced a Beta AI tool that could rotate vector drawings, and I was excited to try it.

The program did not understand the crossings that defined a knot. Without knowing which part of the rope crossed, it was just another piece of loose rope. AI was advancing in a lot of areas, but it was not going to tie these knots for us.

3D knot models built from the wireframe drawings

3D Ties

The Associate Dean of Seidenberg took an interest in our work and wanted to take it into virtual reality. The knots needed real 3D form for that, so I found open source 3D models that matched some of my existing diagrams.

I studied the knot models and reported back on what I had learned. Neither of my advisers had prior 3D modeling or Unity experience. We had weekly meetings where they guided my work with their years of research experience.

Unity

Holding my first knot in VR was a pivotal moment. I started this project with paper, and two years later, I was holding a virtual knot.

I also trained a Teachable Machine image classification model on three knot types. I integrated it with Python, JavaScript, and HTML so the Meta Quest 3 camera could recognize each knot and automatically advance the instructions.

Before this project, I had never conducted formal research. This work led to multiple IRB-approved studies and guided my interest toward user research.

What is your favorite color?

Prinsys

Early Leakage Detection

Admin Panel
Entity Relationship Model

Secure Chat

Encrypted Instant Messaging

Algorithmic Crafting

Research Through Design

Islanding NYC

3D Animation

What is your favorite color?

The Art of Implementation

Tech Stack

Creative Tools