#967: feature/encrypt message at rest #971

ercsnmrs · 2025-08-31T14:17:56Z

Key Features

Optional: Encryption can be disabled if not needed
Transparent: No changes to client API required
Secure: Uses AES-256-GCM with random nonces
Performance Optimized: Only encrypts message content field
Error Handling: Graceful fallback if encryption fails

Security Considerations:

Message content only: Metadata remains unencrypted for search/indexing
Database admins: Can still see message metadata but not content
Key management: Critical - keys must be stored securely
Performance: Minimal overhead (~1-5ms per message)
Recovery: Lost keys mean lost message content

[#967]

ercsnmrs · 2025-08-31T14:24:27Z

I will post the test results + load test.

or-else · 2025-08-31T14:39:24Z

Do you want me to review this now or later, after the tests?

ercsnmrs · 2025-08-31T14:40:38Z

@or-else please do after my testing.

ercsnmrs · 2025-08-31T14:57:16Z

@or-else thinking about it, I would appreciate early feedbacks, we can discuss more technical details afterwards.

docker/tinode/config.template

keygen/README.md

server/store/store.go

or-else · 2025-09-01T07:06:18Z

server/store/store.go

+
+	// Encrypt message content if encryption is enabled
+	if encryptionService != nil && encryptionService.IsEnabled() {
+		encryptedContent, err := encryptionService.EncryptContent(msg.Content)


if encryptedContent, err := encryptionService.EncryptContent(msg.Content); err != nil { ...

No, not really.

This is not addressed. The encryptionService.IsEnabled() check is redundant.

or-else · 2025-09-01T07:08:24Z

server/store/store.go

-	return adp.MessageGetAll(topic, forUser, opt)
+	messages, err := adp.MessageGetAll(topic, forUser, opt)
+	if err != nil {
+		return nil, err


Return messages, err rather than nil, err. No need to change the logic here.

This is not addressed.

server/store/store.go

server/tools/encrypt_messages.go

server/store/encryption.go

Please don't do this.

or-else · 2025-09-15T06:58:32Z

Any update on this?

or-else · 2025-09-19T15:36:20Z

Closing as abandoned

ercsnmrs · 2025-09-19T15:38:25Z

@or-else let me open another mr on this one, been a though week. thanks for your input.

or-else · 2025-09-19T15:47:44Z

If you want to continue, please use this PR. I reopened it. Thanks.

ercsnmrs · 2025-09-19T15:48:56Z

Appreciate it thanks!

or-else · 2025-09-20T05:14:33Z

Could you please respond to each of my comments with done (if resolved) or not done and an explanation why you think it's not a good idea. This way I would know what to look for in the next code review. Thanks!

ercsnmrs · 2025-09-20T05:15:54Z

@or-else sure, currently testing the changes. thanks!

ercsnmrs · 2025-09-20T07:32:22Z

Testing Results:

Steps:

Generated and added the encrypted_at_rest config on tinode.conf file

Send Message 1 - Testing User

Result: Encrypted = true

Send Message 2 - second encrypted message

Result: Encrypted = true

Revert Config from Step 1

Result: Encrypted = false

Some observation:

I need to refresh the webapp to display the chat
Needs thorough testing

CC: @or-else

keygen/README.md

or-else · 2025-09-20T16:23:33Z

keygen/README.md

+./keygen -encryption -keysize 16
+
+# Generate 24-byte encryption key (AES-192)
+./keygen -encryption -keysize 24


This example is probably unnecessary. Any reasonable person can guess that specifying -keysize 24 would mean a 24-byte key.

This is not addressed

keygen/keygen.go

or-else · 2025-09-20T16:55:39Z

server/store/store.go

+}
+
+// initMessageEncryptionFromConfig initializes message encryption service from config file
+func initMessageEncryptionFromConfig(jsonconf json.RawMessage) error {


Please avoid code duplication. I'm strongly against copy-pasting code. Please merge this method with initMessageEncryption.

server/store/store.go

server/tools/README.md

server/tools/encrypt_messages.go

or-else · 2025-09-20T17:47:46Z

Please move server/tools/encrypt_messages.go to another PR. It will require a lot of work. It can be done later.

ercsnmrs · 2025-10-10T06:41:48Z

@or-else i will continue on this, will push a change tomorrow oct 10. please keep it open. Thanks!

or-else · 2025-11-03T07:14:19Z

Any update on this?

or-else · 2025-12-21T08:20:54Z

@ercsnmrs Please let me know if you wish to continue with this PR.

ercsnmrs · 2026-01-08T15:38:39Z

Had a long break. I will continue working on it @or-else thanks for the wait :D

… validation - Rename generic 'encryption' config to 'encrypt_at_rest' for clarity - Remove redundant 'enabled' field - key presence determines encryption - Support all AES key sizes (16, 24, 32 bytes) instead of just 32-byte keys - Simplify EncryptionService to MessageEncryptionService with cleaner API - Use []byte fields in EncryptedContent for automatic base64 conversion - Fix store initialization order: command line flags override config file - Update keygen tool with proper AES key size validation - Remove output file option from keygen (use shell redirection instead) - Fix encrypt_messages tool to use proper store interface methods - Add nil content handling in EncryptContent method - Update all tests to work with new MessageEncryptionService API - Improve error handling and method visibility throughout [tinode#967]

…ility [tinode#967]

- Detect encrypted content by presence of data and nonce fields - Message, replace with error placeholder instead of returning garbled encrypted content [tinode#967]

ercsnmrs · 2026-01-10T07:17:58Z

@or-else already addressed your concern on the MR.

i have concern regarding the front-end, what is your expected here?

E.g. admin put encryption then decide to go back.

or-else · 2026-01-10T11:31:18Z

already addressed your concern on the MR.

I don't understand. What's MR?

ercsnmrs · 2026-01-10T11:33:06Z

@or-else sorry MR is merge request, same meaning of pull request

or-else · 2026-01-10T11:39:47Z

what is your expected here?

The use case:

The encryption is turned on, a few messages are exchanged and stored encrypted on the server.
The encryption is turned off without decrypting already encrypted messages (tools are not ready).
New messages are unencrypted.

Expectation:

The encryption is handled by the server in such a way that the client is completely unaware of it. The messages appear completely normally in the client.
The encrypted messages become unaccessible. The client should see something like " not accessible" or "unavailable", not "invalid content".
New messages appear completely normally, like nothing happened.

Copilot

Pull request overview

This pull request implements optional message encryption at rest for Tinode, encrypting message content stored in the database using AES-GCM symmetric encryption. The feature is transparent to clients, with messages automatically encrypted on save and decrypted on retrieval.

Changes:

Added AES-GCM encryption/decryption service for message content
Integrated encryption into message save and retrieve operations
Added keygen utility support for generating encryption keys
Provided comprehensive documentation and test coverage

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
server/store/message_encryption.go	New encryption service implementing AES-GCM encryption/decryption for message content
server/store/encryption_test.go	Comprehensive test coverage for encryption functionality
server/store/store.go	Integration of encryption service into message persistence layer with graceful error handling
server/store/ENCRYPTION.md	Documentation covering configuration, key management, migration, and security considerations
server/tinode.conf	Added configuration options for encryption at rest with examples (includes unrelated DB config changes)
tinode-db/tinode.conf	Added configuration options for encryption at rest (includes unrelated DB config changes)
keygen/keygen.go	Extended keygen utility to generate encryption keys with validation
keygen/README.md	Documentation for encryption key generation
server/main.go	Minor cosmetic change (blank line)

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-10T11:52:59Z

tinode-db/tinode.conf

+		// "encrypt_at_rest": {
+		//	"key": "base64-encoded-32-byte-key-here"
+		// },
+		"use_adapter": "postgres",


The use_adapter has been changed from empty string to "postgres". This appears to be a development-specific change that should not be in a configuration example file. The default should remain as an empty string (or another placeholder value) so users can choose their own adapter.

Suggested change

"use_adapter": "postgres",

"use_adapter": "",

Copilot · 2026-01-10T11:53:00Z

server/store/message_encryption.go

+// EncryptedContent represents encrypted message content with metadata
+type EncryptedContent struct {
+	Data  []byte `json:"data"`  // Encrypted data (automatically base64 encoded/decoded)
+	Nonce []byte `json:"nonce"` // Nonce (automatically base64 encoded/decoded)


The comments on the EncryptedContent struct claim that Data and Nonce fields are "automatically base64 encoded/decoded", but the struct doesn't implement custom JSON marshaling/unmarshaling. Go's default JSON encoding for []byte fields uses base64 encoding, so this is technically correct, but the comment might be misleading as it suggests custom handling when it's actually Go's default behavior.

Suggested change

// EncryptedContent represents encrypted message content with metadata

type EncryptedContent struct {

Data []byte `json:"data"` // Encrypted data (automatically base64 encoded/decoded)

Nonce []byte `json:"nonce"` // Nonce (automatically base64 encoded/decoded)

// EncryptedContent represents encrypted message content with metadata.

// The Data and Nonce fields are []byte and will be base64 encoded/decoded

// by Go's standard encoding/json package when marshaling/unmarshaling.

type EncryptedContent struct {

Data []byte `json:"data"` // Encrypted data (JSON-encoded as base64)

Nonce []byte `json:"nonce"` // Nonce (JSON-encoded as base64)

Copilot · 2026-01-10T11:53:00Z

server/store/ENCRYPTION.md

+
+

The Troubleshooting section is empty. This section should include common issues and their solutions, such as: 1) What to do if encryption key is lost, 2) How to handle decryption errors, 3) What to do if messages appear as "[Message content could not be decrypted]", 4) Performance troubleshooting, etc.

Suggested change

### Lost or Rotated Encryption Key

The encryption key is required to decrypt any message content that was stored while that key was active.

If the key is lost or changed without a proper migration, previously stored messages **cannot** be decrypted.

Recommended practices:

- **Back up the key securely** before enabling `encrypt_at_rest` in production.

- Store the key in a secure secret manager or hardware security module (HSM) where possible.

- Restrict access to the key to only the server processes that need it.

If the key is already lost:

- Existing encrypted messages will remain in the database but their content is unrecoverable.

- You may configure a new key in `tinode.conf` and restart the server; all **new** messages will use the new key.

- If you have a database backup and a backup of the original key, you can:

- Restore the database snapshot that corresponds to the time when the old key was still available.

- Restart the server with the old key to access the data, or

- Implement a one‑time export/re‑encrypt procedure outside of this document.

### Decryption Errors

If the server logs decryption errors for message content:

1. **Verify the key format**:

- Ensure the `encrypt_at_rest.key` value is valid base64.

- After base64 decoding, the key must be exactly 16, 24, or 32 bytes for AES‑128/192/256.

2. **Check for configuration drift**:

- Confirm all server instances use the **same** encryption key.

- If you changed the key, verify that all nodes were restarted and are reading the updated configuration.

3. **Inspect for data corruption**:

- Validate that the stored JSON object contains both `data` and `nonce` fields.

- Ensure both fields contain valid base64 without truncation or manual editing.

4. **Review server logs**:

- Look for details such as "authentication failed", "invalid nonce size", or "ciphertext too short".

- These messages can help distinguish between key mismatch, corrupted data, and programming errors.

If decryption consistently fails for all messages after a deployment or configuration change, roll back to the previous configuration (and key) that was known to work, then re‑apply changes carefully.

### Messages Displayed as `[Message content could not be decrypted]`

When clients see a placeholder such as `[Message content could not be decrypted]`, it usually means:

- The server failed to decrypt the stored `content` field, or

- The content field is missing or corrupted in the database.

Steps to investigate:

1. Identify an affected message and locate it in the database.

2. Confirm that the `content` JSON has both `data` and `nonce` fields and that they are valid base64.

3. Check that the server is running with the same encryption key that was used when the message was stored.

4. Review server logs around the time the message was fetched for any decryption errors.

If only some messages show this placeholder while newer ones are fine, this typically indicates:

- A key change without migrating old data, or

- Partial database corruption or manual edits to stored messages.

In that case, only the affected messages are unrecoverable; new messages should decrypt normally once the key and configuration are correct.

### Performance Troubleshooting

Encryption at rest adds CPU overhead and increases stored message size. If you observe high latency or load:

- **Measure baseline performance**:

- Compare message send/receive latency with `encrypt_at_rest` enabled vs disabled in a non‑production environment.

- **Monitor resource usage**:

- Check CPU utilization on the Tinode server nodes during peak traffic.

- Ensure there are enough CPU cores for the expected encryption/decryption workload.

- **Review message sizes**:

- Very large message payloads incur more encryption cost and storage overhead.

- Consider enforcing reasonable limits on message size.

- **Scale horizontally**:

- If CPU is the bottleneck, add more server instances and ensure they all share the same encryption key.

- **Check configuration**:

- Verify that the key length is appropriate; AES‑256 may be slightly slower than AES‑128 but usually not dramatically so.

When investigating performance issues, always change one variable at a time (e.g., disable encryption in a staging environment only) and compare metrics to isolate the impact of encryption.

Copilot · 2026-01-10T11:53:00Z

tinode-db/tinode.conf

+				"database": "tinodesvc",
+				"dsn": "postgresql://user:pass@localhost:5432/tinodesvc?sslmode=disable"


The database configuration has been changed from default values. This change appears to be specific to a development environment and should not be committed. The database name changed from "tinode" to "tinodesvc", and credentials from "postgres:postgres" to "user:pass". These should remain as the default examples unless there's a specific reason to change them.

Suggested change

"database": "tinodesvc",

"dsn": "postgresql://user:pass@localhost:5432/tinodesvc?sslmode=disable"

"database": "tinode",

"dsn": "postgresql://postgres:postgres@localhost:5432/tinode?sslmode=disable"

Copilot · 2026-01-10T11:53:01Z

server/tinode.conf

+				"User": "user",
+				"Passwd": "pass",
 				"Host": "localhost",
 				"Port": "5432",
-				"DBName": "tinode",
+				"DBName": "tinodesvc",


The database configuration has been changed from default values. This change appears to be specific to a development environment and should not be committed. The database name changed from "tinode" to "tinodesvc", username from "postgres" to "user", and password from "postgres" to "pass". These should remain as the default examples unless there's a specific reason to change them.

Copilot · 2026-01-10T11:53:01Z

server/tinode.conf

+		// See server/store/ENCRYPTION.md for more information.
+		// "encrypt_at_rest": {
+		//	"key": "base64-encoded-key-here"
+		//	},


There's a trailing comma after the closing brace. While this is commented out, if users uncomment these lines to enable encryption, the trailing comma will cause a JSON parsing error. The comma should be removed or a comment should be added to warn users to remove it.

Suggested change

// },

// }

Copilot · 2026-01-10T11:53:01Z

server/store/message_encryption.go

+// GetKey returns a copy of the encryption key (for testing purposes)
+func (es *MessageEncryptionService) GetKey() []byte {
+	if es == nil || es.key == nil {
+		return nil
+	}
+	keyCopy := make([]byte, len(es.key))
+	copy(keyCopy, es.key)
+	return keyCopy
+}


The GetKey method is exported and allows retrieving a copy of the encryption key. While the comment indicates it's for testing purposes, being exported makes it accessible in production code, which is a security risk. This method should either be removed if not needed, or made unexported (lowercase 'getKey') and kept in a test file if needed for testing.

Copilot · 2026-01-10T11:53:01Z

server/store/message_encryption.go

+// GetMessageEncryptionService returns the current message encryption service instance
+func GetMessageEncryptionService() *MessageEncryptionService {


The GetMessageEncryptionService function is exported but not used anywhere in the codebase. Exposing the encryption service instance could allow external code to access encryption methods or the key (via GetKey), which is a security risk. This function should either be removed if not needed, or made unexported (lowercase name) if it's only needed internally.

Suggested change

// GetMessageEncryptionService returns the current message encryption service instance

func GetMessageEncryptionService() *MessageEncryptionService {

// getMessageEncryptionService returns the current message encryption service instance.

// It is kept unexported to avoid exposing the encryption service outside this package.

func getMessageEncryptionService() *MessageEncryptionService {

Copilot · 2026-01-10T11:53:02Z

server/tinode.conf

 		// DB adapter name to communicate with the DB backend.
 		// Must be one of the adapters from the list below.
-		"use_adapter": "",
+		"use_adapter": "postgres",


The use_adapter has been changed from empty string to "postgres". This appears to be a development-specific change that should not be in a configuration example file. The default should remain as an empty string (or another placeholder value) so users can choose their own adapter.

Suggested change

"use_adapter": "postgres",

"use_adapter": "",

ercsnmrs · 2026-01-10T12:04:20Z

Cool. Thanks for the feedback @or-else let me address that use case for this point:

The encrypted messages become unaccessible. The client should see something like "image not accessible" or "unavailable", not "invalid content".

I agree that the server should return other message instead.

or-else · 2026-01-10T12:18:33Z

I agree that the server should return other message instead.

It should not return the message with such text. It should return an indicator that the message cannot be decrypted, probably in the message header. Including such text into message body is undesirable because it has to be i18n-ed and that's easier if it's just a header.

or-else · 2026-01-10T12:37:25Z

Please address every unresolved comment. If you agree and it's resolved, say "done", if you disagree, explain why. Please do address every unresolved issue with either "done" or an explanation why it's a bad idea.

or-else reviewed Sep 1, 2025

View reviewed changes

server/store/encryption.go Show resolved Hide resolved

mielen636-ui previously approved these changes Sep 5, 2025

View reviewed changes

or-else changed the base branch from master to devel September 5, 2025 10:35

or-else closed this Sep 19, 2025

or-else reopened this Sep 19, 2025

ercsnmrs force-pushed the feature/encrypt-message-at-rest branch 2 times, most recently from 5d3ce78 to 157476a Compare September 20, 2025 05:01

ercsnmrs force-pushed the feature/encrypt-message-at-rest branch from 157476a to 4ae0494 Compare September 20, 2025 07:25

ercsnmrs marked this pull request as ready for review September 20, 2025 07:46

or-else reviewed Sep 20, 2025

View reviewed changes

server/tools/encrypt_messages.go Outdated Show resolved Hide resolved

server/tools/encrypt_messages.go Outdated Show resolved Hide resolved

server/tools/encrypt_messages.go Outdated Show resolved Hide resolved

server/tools/encrypt_messages.go Outdated Show resolved Hide resolved

ercsnmrs marked this pull request as draft September 21, 2025 03:57

ercsnmrs force-pushed the feature/encrypt-message-at-rest branch 2 times, most recently from 348f806 to 1a92f1a Compare January 9, 2026 14:08

ercsnmrs force-pushed the feature/encrypt-message-at-rest branch from 1a92f1a to 2a87eff Compare January 9, 2026 14:15

ercsnmrs added 2 commits January 10, 2026 12:54

tinode#967: removed encrypt_message tools, updated tinode.conf readab…

1d81215

…ility [tinode#967]

tinode#967: addressed redundant code, code suggestions

7c8a5e3

- Detect encrypted content by presence of data and nonce fields - Message, replace with error placeholder instead of returning garbled encrypted content [tinode#967]

ercsnmrs marked this pull request as ready for review January 10, 2026 07:19

or-else requested a review from Copilot January 10, 2026 11:43

Copilot started reviewing on behalf of or-else January 10, 2026 11:44 View session

Copilot AI reviewed Jan 10, 2026

View reviewed changes

ercsnmrs marked this pull request as draft January 10, 2026 12:35

+### Lost or Rotated Encryption Key
+The encryption key is required to decrypt any message content that was stored while that key was active.
+If the key is lost or changed without a proper migration, previously stored messages **cannot** be decrypted.
+Recommended practices:
+- **Back up the key securely** before enabling `encrypt_at_rest` in production.
+- Store the key in a secure secret manager or hardware security module (HSM) where possible.
+- Restrict access to the key to only the server processes that need it.
+If the key is already lost:
+- Existing encrypted messages will remain in the database but their content is unrecoverable.
+- You may configure a new key in `tinode.conf` and restart the server; all **new** messages will use the new key.
+- If you have a database backup and a backup of the original key, you can:
+  - Restore the database snapshot that corresponds to the time when the old key was still available.
+  - Restart the server with the old key to access the data, or
+  - Implement a one‑time export/re‑encrypt procedure outside of this document.
+### Decryption Errors
+If the server logs decryption errors for message content:
+. **Verify the key format**:
+   - Ensure the `encrypt_at_rest.key` value is valid base64.
+   - After base64 decoding, the key must be exactly 16, 24, or 32 bytes for AES‑128/192/256.
+. **Check for configuration drift**:
+   - Confirm all server instances use the **same** encryption key.
+   - If you changed the key, verify that all nodes were restarted and are reading the updated configuration.
+. **Inspect for data corruption**:
+   - Validate that the stored JSON object contains both `data` and `nonce` fields.
+   - Ensure both fields contain valid base64 without truncation or manual editing.
+. **Review server logs**:
+   - Look for details such as "authentication failed", "invalid nonce size", or "ciphertext too short".
+   - These messages can help distinguish between key mismatch, corrupted data, and programming errors.
+If decryption consistently fails for all messages after a deployment or configuration change, roll back to the previous configuration (and key) that was known to work, then re‑apply changes carefully.
+### Messages Displayed as `[Message content could not be decrypted]`
+When clients see a placeholder such as `[Message content could not be decrypted]`, it usually means:
+- The server failed to decrypt the stored `content` field, or
+- The content field is missing or corrupted in the database.
+Steps to investigate:
+. Identify an affected message and locate it in the database.
+. Confirm that the `content` JSON has both `data` and `nonce` fields and that they are valid base64.
+. Check that the server is running with the same encryption key that was used when the message was stored.
+. Review server logs around the time the message was fetched for any decryption errors.
+If only some messages show this placeholder while newer ones are fine, this typically indicates:
+- A key change without migrating old data, or
+- Partial database corruption or manual edits to stored messages.
+In that case, only the affected messages are unrecoverable; new messages should decrypt normally once the key and configuration are correct.
+### Performance Troubleshooting
+Encryption at rest adds CPU overhead and increases stored message size. If you observe high latency or load:
+- **Measure baseline performance**:
+  - Compare message send/receive latency with `encrypt_at_rest` enabled vs disabled in a non‑production environment.
+- **Monitor resource usage**:
+  - Check CPU utilization on the Tinode server nodes during peak traffic.
+  - Ensure there are enough CPU cores for the expected encryption/decryption workload.
+- **Review message sizes**:
+  - Very large message payloads incur more encryption cost and storage overhead.
+  - Consider enforcing reasonable limits on message size.
+- **Scale horizontally**:
+  - If CPU is the bottleneck, add more server instances and ensure they all share the same encryption key.
+- **Check configuration**:
+  - Verify that the key length is appropriate; AES‑256 may be slightly slower than AES‑128 but usually not dramatically so.
+When investigating performance issues, always change one variable at a time (e.g., disable encryption in a staging environment only) and compare metrics to isolate the impact of encryption.

		"database": "tinodesvc",
		"dsn": "postgresql://user:pass@localhost:5432/tinodesvc?sslmode=disable"

		// GetMessageEncryptionService returns the current message encryption service instance
		func GetMessageEncryptionService() *MessageEncryptionService {

-// GetMessageEncryptionService returns the current message encryption service instance
-func GetMessageEncryptionService() *MessageEncryptionService {
+// getMessageEncryptionService returns the current message encryption service instance.
+// It is kept unexported to avoid exposing the encryption service outside this package.
+func getMessageEncryptionService() *MessageEncryptionService {

#967: feature/encrypt message at rest #971

Are you sure you want to change the base?

#967: feature/encrypt message at rest #971

Uh oh!

Conversation

ercsnmrs commented Aug 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ercsnmrs commented Aug 31, 2025

Uh oh!

or-else commented Aug 31, 2025

Uh oh!

ercsnmrs commented Aug 31, 2025

Uh oh!

ercsnmrs commented Aug 31, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

or-else commented Sep 15, 2025

Uh oh!

or-else commented Sep 19, 2025

Uh oh!

ercsnmrs commented Sep 19, 2025

Uh oh!

or-else commented Sep 19, 2025

Uh oh!

ercsnmrs commented Sep 19, 2025

Uh oh!

or-else commented Sep 20, 2025

Uh oh!

ercsnmrs commented Sep 20, 2025

Uh oh!

ercsnmrs commented Sep 20, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

or-else commented Sep 20, 2025

Uh oh!

ercsnmrs commented Oct 10, 2025

Uh oh!

or-else commented Nov 3, 2025

Uh oh!

or-else commented Dec 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

ercsnmrs commented Aug 31, 2025 •

edited

Loading

or-else commented Dec 21, 2025 •

edited

Loading

ercsnmrs commented Jan 10, 2026 •

edited

Loading