@some_guy_named_joe

Handcryption Status Update 0.0.3.9

What Happened?

Ok, big change to the workings of this device. Previously, this device could only work locally, but through my Raspberry Pi server and a domain through ngrok, I can make the device work on the cloud, and I have altered the server code and main device code to work this way.

Also, instead of using IPs to identify devices, I am using my own identification system that is like a phone number, a sequence of 9 digits. I recognize that this may be a small number of available sequences, but for now, it is a good amount. I can change this later.

So, to send messages now, instead of using a socket, the device sends an HTTP request to the ngrok domain hosted by the Pi. The request includes the message, the destination’s ID, and the sender’s (the device’s) ID. The server then stores this information in a “mailbox” -a collection of all sent messages. The receiving device, every 2 seconds, is sending an HTTP request to the server asking if there is anything in its mailbox. If so, the server returns the message(s) with the sender ID so the receiver can match that to a contact.

The cloud update has made my overall code length shorter, as most of the long sequences of code have been simplified to shorter HTTP requests.

Also, as promised, this is my part BOM: https://github.com/Joethebeast-coder/Handheld-Encryption-Device/tree/main/Hardware

What’s Next in 0.0.4?

 - Extra Add-on Device Features
 - Maybe more website interactivity

Handcryption Status Update 0.0.3.9

What Happened?

Ok, big change to the workings of this device. Previously, this device could only work locally, but through my Raspberry Pi server and a domain through ngrok, I can make the device work on the cloud, and I have altered the server code and main device code to work this way.

Also, instead of using IPs to identify devices, I am using my own identification system that is like a phone number, a sequence of 9 digits. I recognize that this may be a small number of available sequences, but for now, it is a good amount. I can change this later.

So, to send messages now, instead of using a socket, the device sends an HTTP request to the ngrok domain hosted by the Pi. The request includes the message, the destination’s ID, and the sender’s (the device’s) ID. The server then stores this information in a “mailbox” -a collection of all sent messages. The receiving device, every 2 seconds, is sending an HTTP request to the server asking if there is anything in its mailbox. If so, the server returns the message(s) with the sender ID so the receiver can match that to a contact.

The cloud update has made my overall code length shorter, as most of the long sequences of code have been simplified to shorter HTTP requests.

Also, as promised, this is my part BOM: https://github.com/Joethebeast-coder/Handheld-Encryption-Device/tree/main/Hardware

What’s Next in 0.0.4?

 - Extra Add-on Device Features
 - Maybe more website interactivity

Handcryption Status Update 0.0.3.6

What Happened?

I added a cool new feature to the Handcryption device-GROUP CHATS!! This allows every user with a Handcryption device who opts to join the group to participate in conversations, fostering a more connected experience among users. I learned how to use Flask (thanks to GeeksforGeeks), which enabled me to seamlessly integrate the group chat feature into the server code running on the Raspberry Pi.

In addition to the chat functionality, there is now a website hosted on the Raspberry Pi’s IP address that displays all the messages in the group chat. The caveat is that every message on the website is shown in its encrypted form to maintain security and confidentiality.

Looking ahead, I plan to implement a feature that would allow Handcryption users to sign in to the website. This will enable them to view messages in a decrypted format, enhancing user experience while still prioritizing privacy. I believe these developments will significantly improve user engagement and create a more dynamic platform for communication.

 My device(s) are becoming more and more like a phone

What’s next?

 - Preliminary BOM
 - Increase Website Functionality
 - Timeline Estimation
 - Code Cleanup and Extra Features

Photo Description: Some of the server code for the group chat

Handcryption Status Update 0.0.3.6

What Happened?

I added a cool new feature to the Handcryption device-GROUP CHATS!! This allows every user with a Handcryption device who opts to join the group to participate in conversations, fostering a more connected experience among users. I learned how to use Flask (thanks to GeeksforGeeks), which enabled me to seamlessly integrate the group chat feature into the server code running on the Raspberry Pi.

In addition to the chat functionality, there is now a website hosted on the Raspberry Pi’s IP address that displays all the messages in the group chat. The caveat is that every message on the website is shown in its encrypted form to maintain security and confidentiality.

Looking ahead, I plan to implement a feature that would allow Handcryption users to sign in to the website. This will enable them to view messages in a decrypted format, enhancing user experience while still prioritizing privacy. I believe these developments will significantly improve user engagement and create a more dynamic platform for communication.

 My device(s) are becoming more and more like a phone

What’s next?

 - Preliminary BOM
 - Increase Website Functionality
 - Timeline Estimation
 - Code Cleanup and Extra Features

Photo Description: Some of the server code for the group chat

Handcryption Status Update 0.0.3.5

What Happened?

I was able to set up a server on my Raspberry Pi 4 with the help of Copilot (I do not know Flask in the slightest). So now, when a device wants to send a message, the audio recording is sent to the Pi, requesting that it be translated to text. I’ve been experimenting with Claude on making a website to monitor the server’s status, but I will talk about that more in a later update if I decide to go that route.

Today, I was able to make a CAD model of the housing of the device (The process of which is posted on Lapse). I have to admit, it looks a lot like the phreakers from the early days of calling.

What’s Next?
- Decision on whether to pursue web monitoring
- Preliminary BOM
- Timeline Estimation
- Extra Features for the Device

Handcryption Status Update 0.0.3.5

What Happened?

I was able to set up a server on my Raspberry Pi 4 with the help of Copilot (I do not know Flask in the slightest). So now, when a device wants to send a message, the audio recording is sent to the Pi, requesting that it be translated to text. I’ve been experimenting with Claude on making a website to monitor the server’s status, but I will talk about that more in a later update if I decide to go that route.

Today, I was able to make a CAD model of the housing of the device (The process of which is posted on Lapse). I have to admit, it looks a lot like the phreakers from the early days of calling.

What’s Next?
- Decision on whether to pursue web monitoring
- Preliminary BOM
- Timeline Estimation
- Extra Features for the Device

Handcryption Status Update 0.0.3.2 (Big News)

What Happened?

So, I was able to add in a UI that includes settings, contacts, message history, as well as battery status. In the settings, the user can change the volume of the piezo, as well as clear the files on their device (Contacts, Known IPs, and Message History. When hovering over a choice, the icon (the volume icon, for example) repeatedly switches from inverted to normal.

However, while I was debugging, I found a MAJOR problem. My measly ESP32 microcontroller doesn’t have enough CPU and RAM to run the speech-to-text model. However, I can pivot from this by using the VOSK model paired with my Raspberry Pi 4 that I have on hand as a server to run the model for the microcontroller. This opens up a whole new possibility. We can now have a main hub that monitors the devices, serves the speech-to-text requests, and sends the text back.

What’s Next?

 - Speech-to-text code for the Raspberry Pi
 - Communication Protocol between the device and Pi

Handcryption Status Update 0.0.3.2 (Big News)

What Happened?

So, I was able to add in a UI that includes settings, contacts, message history, as well as battery status. In the settings, the user can change the volume of the piezo, as well as clear the files on their device (Contacts, Known IPs, and Message History. When hovering over a choice, the icon (the volume icon, for example) repeatedly switches from inverted to normal.

However, while I was debugging, I found a MAJOR problem. My measly ESP32 microcontroller doesn’t have enough CPU and RAM to run the speech-to-text model. However, I can pivot from this by using the VOSK model paired with my Raspberry Pi 4 that I have on hand as a server to run the model for the microcontroller. This opens up a whole new possibility. We can now have a main hub that monitors the devices, serves the speech-to-text requests, and sends the text back.

What’s Next?

 - Speech-to-text code for the Raspberry Pi
 - Communication Protocol between the device and Pi

Hancryption Status Update 0.0.3 (Combined)

What Happened in 0.0.2.3?

I have created a parts list for this project:
Adafruit:
- Adafruit Electret Microphone Amplifier - MAX4466
with Adjustable Gain
- Adafruit 2.13” Monochrome eInk / ePaper Display
with SRAM - 250x122 Monochrome with SSD1680
- Adafruit ESP32-S2 Feather - 4 MB Flash + 2 MB
PSRAM - STEMMA QT / Qwiic
- Lithium Ion Polymer Battery - 3.7v 100mAh
- Tactile Button switch (6mm) x 20 pack
- Small Enclosed Piezo w/Wires
I have decided to use the Adafruit ESP32-S2 Feather as my microcontroller, as it takes care of the LiPoly battery charging, so I don’t have to buy extra parts for it. I can also charge the battery through the USB-C on the board. It also has many GPIO pins that I can give to my e-Ink display, as well as the switches (6).

What Happened in 0.0.2.5?

I created a wiring diagram for the components listed in the parts list. The time-lapse can be seen on Lapse*.

*I forgot to add the piezo in the time-lapse, and I wired the SDA and SCL pins to buttons, which was not supposed to happen, so later, I added the piezo, and moved the button wires to spare analog pins. You can see these in the screenshot below.

What Happened in 0.0.3?

I made a complete draft of the code for the device. I added all of the button logic and basic e-ink display code. I added a loading screen with “HANCRYPTION” in block text and a sleep screen. To “power down”, when the user holds the power button for more than 1 second, it goes into deep-sleep, which is basically off for microcontrollers. If it is less than that, it just goes idle. Of course, this is not the final code. I will keep adding more and more features that are compatible with the current set of parts I already have.

What’s Next in 0.0.4?

-Extra UI Features
-Possibility of Games

Hancryption Status Update 0.0.3 (Combined)

What Happened in 0.0.2.3?

I have created a parts list for this project:
Adafruit:
- Adafruit Electret Microphone Amplifier - MAX4466
with Adjustable Gain
- Adafruit 2.13” Monochrome eInk / ePaper Display
with SRAM - 250x122 Monochrome with SSD1680
- Adafruit ESP32-S2 Feather - 4 MB Flash + 2 MB
PSRAM - STEMMA QT / Qwiic
- Lithium Ion Polymer Battery - 3.7v 100mAh
- Tactile Button switch (6mm) x 20 pack
- Small Enclosed Piezo w/Wires
I have decided to use the Adafruit ESP32-S2 Feather as my microcontroller, as it takes care of the LiPoly battery charging, so I don’t have to buy extra parts for it. I can also charge the battery through the USB-C on the board. It also has many GPIO pins that I can give to my e-Ink display, as well as the switches (6).

What Happened in 0.0.2.5?

I created a wiring diagram for the components listed in the parts list. The time-lapse can be seen on Lapse*.

*I forgot to add the piezo in the time-lapse, and I wired the SDA and SCL pins to buttons, which was not supposed to happen, so later, I added the piezo, and moved the button wires to spare analog pins. You can see these in the screenshot below.

What Happened in 0.0.3?

I made a complete draft of the code for the device. I added all of the button logic and basic e-ink display code. I added a loading screen with “HANCRYPTION” in block text and a sleep screen. To “power down”, when the user holds the power button for more than 1 second, it goes into deep-sleep, which is basically off for microcontrollers. If it is less than that, it just goes idle. Of course, this is not the final code. I will keep adding more and more features that are compatible with the current set of parts I already have.

What’s Next in 0.0.4?

-Extra UI Features
-Possibility of Games

Hancryption Status Update 0.0.2.1

What Happened?

I patched some bugs in the client class so I could add a main loop for the device. When the device is sending, it is the server, and in any other circumstance, it is the client, it is idle and waiting for a message.
I added the button and microphone logic for the specific components.
I need to add the logic for the eink display

Hancryption Status Update 0.0.2.1

What Happened?

I patched some bugs in the client class so I could add a main loop for the device. When the device is sending, it is the server, and in any other circumstance, it is the client, it is idle and waiting for a message.
I added the button and microphone logic for the specific components.
I need to add the logic for the eink display

Handcryption Status Update 0.0.1.5

What’s New?

I created a rough sketch of the device. I also wrote down a tentative list of parts I would need. See Below

0.0.2 Should be released by 6/4/26.

*Note: I completely forgot about the screen and the parts needed for that.
LCD
3 buttons

Hancryption Status Update 0.0.2

What Happened?

I added classes for server and client communication so the device could be either. I also added the encryption feature, which generates a unique key for each known IP address. The network also includes a client status check that occurs every 15 seconds, in which the client sends its IP address to the server.

What’s Next in 0.0.3?

Full draft code for a device. This will include all of the machine programming for the ESP32 chip, which is for the microphone, eink screen, and buttons.

By 0.0.2.3, a draft parts list should be complete.

By 0.0.2.5, a wiring diagram should be complete.

Hancryption Status Update 0.0.2

What Happened?

I added classes for server and client communication so the device could be either. I also added the encryption feature, which generates a unique key for each known IP address. The network also includes a client status check that occurs every 15 seconds, in which the client sends its IP address to the server.

What’s Next in 0.0.3?

Full draft code for a device. This will include all of the machine programming for the ESP32 chip, which is for the microphone, eink screen, and buttons.

By 0.0.2.3, a draft parts list should be complete.

By 0.0.2.5, a wiring diagram should be complete.

Handcryption Status Update 0.0.1.5

What’s New?

I created a rough sketch of the device. I also wrote down a tentative list of parts I would need. See Below

0.0.2 Should be released by 6/4/26.

*Note: I completely forgot about the screen and the parts needed for that.
LCD
3 buttons

Hancryption Status Update 0.0.1

I have created the basic logic framework for the speech-to-text with processing. I am currently using many placeholders, however. Will be updating that by 0.0.4 at the latest. For encryption, I am using my previously developed “Cencrypt” Python library.

What’s Next in 0.0.2?

Networking Framework
Encryption Setup

Hancryption Status Update 0.0.1

I have created the basic logic framework for the speech-to-text with processing. I am currently using many placeholders, however. Will be updating that by 0.0.4 at the latest. For encryption, I am using my previously developed “Cencrypt” Python library.

What’s Next in 0.0.2?

Networking Framework
Encryption Setup