This tutorial by bitchat focuses on the specific task in the title. Bitchat’s Bluetooth Mesh and Nostr fallbacks address different connection conditions; end-to-end encryption cannot hide all device, time, proximity, and network metadata.
Below is a demonstration using a test environment and revocable data. When accounts, keys, machine control, investments or emergency communications are involved, manual confirmation must be done.
How to divide the work between Bluetooth Mesh and Nostr fallback
This section only deals with “How to divide the work between Bluetooth Mesh and Nostr fallback”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Only install from trusted distribution channels
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is “only install from trusted release channels” and obtain verifiable results, rather than the command just not reporting an error.
First test using two backup devices
| Check items | Passing criteria | Stop signal |
|---|---|---|
| The first test uses two backup devices | Input, output and permission scope are clear | Tool automatically expands the scope of operation |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
What are the system Bluetooth permissions required?
This section only deals with “What system Bluetooth permissions are required”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Discover distance limits for nearby devices
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is to “find the distance limit of nearby devices” and get a verifiable result, rather than the command just not reporting an error.
Whether the relay node really forwards the message
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Whether the relay node really forwards the message | Input, output and permission scope are clear | The tool automatically expands the scope of operation |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
How to record offline message delay
This section only deals with “How to record offline message delays”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
What network metadata will be exposed by Nostr fallback?
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion criterion is to obtain verifiable results of “What network metadata will be exposed by Nostr rollback?” rather than the command not reporting an error.
Encryption protects content but does not equal anonymity
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Encryption protects content but does not equal anonymity | Input, output and permission scope are clear | Tools automatically expand the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
How to verify contacts by nickname and public key
This section only deals with “How to verify contacts by nickname and public key”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Emergency erasure does not guarantee that the storage media will be traceless
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is that “emergency erasure does not guarantee that the storage medium is traceless” and a verifiable result is obtained, rather than that the command happens to report no error.
Why does mobile phone power saving strategy lead to disconnection?
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Why does mobile phone power-saving strategy lead to disconnection | Clear input, output and permission ranges | Tools automatically expand the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
When messages accumulate, check the relay or Bluetooth first
This section only deals with “When messages accumulate, check whether the relay or Bluetooth should be checked first.” Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Emergency drills cannot only test successful sending
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is that “emergency drills cannot only test successful transmission” and obtain verifiable results, rather than that the command happens to report no errors.
Don’t treat a single application as your only communication solution
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Don’t rely on a single application as your only communication solution | Clear input, output and permission scope | Tools automatically expand the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Clear accounts and logs after testing
This section only deals with “clearing accounts and logs after testing”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Test method for three devices to form a relay topology
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is that the “test method of three devices forming a relay topology” can obtain verifiable results, rather than that the command just does not report an error.
How to reproduce disconnection caused by background power saving
| Check items | Passing criteria | Stop signal |
|---|---|---|
| How to reproduce disconnection caused by background power saving | Clear input, output and permission ranges | The tool automatically expands the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Check the participant’s public key after the exercise
This section only deals with “checking participant public keys after the exercise”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For bitchat, this boundary must be combined when judging the results: bitchat’s Bluetooth Mesh and Nostr fallback address different connection conditions; end-to-end encryption cannot hide all devices, time, proximity relationships, and network metadata.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
final check on bitchat
- The versions and sources used are documented.
- Test input and formal data have been isolated.
- Commands, configurations and actual output can correspond.
- The failed path was actively tested at least once.
- Keys, accounts and private data do not enter Git or logs.
- There are clear actions for upgrading, stopping and resuming.
If you still can’t explain how the results came about, keep bitchat in a test environment without extending permissions or replacing existing stable processes.