1  - shell: interactive sessions, e.g. with calc or python, during remote shell are possible
  2           but this is not the case e.g. when calling python -> implement (move session to sub-shell?)   
  3      solution using expect (need sudo apt install expect):
  4      expect -c 'spawn python; expect ">>>"; interact'
  5      (exit with quit())
  6      expect -c 'spawn calc; expect ";"; interact'
  7      (exit with exit)
  8      # NOTE: expect is between user interaction so there may be formatting problems.
  9      # NOTE: you may also put the script in a file and run it with: 
 10      chmod +x myscript.exp
 11      ./myscript.exp
 12      or
 13      expect myscript.exp
 14      Investigate options using Tcl, Tk and wish.
 15  - shell: the command clear is executed only after a new command is executed. Solution?
 16  - shell: starting programs, e.g. gedit, works but then what? we cannot interact with the app.
 17           check also some tcl script using wish, e.g.:
 18           #!/usr/bin/env wish
 19           package require Tk
 20           label .msg -text "Hello from wish"
 21           pack .msg
 22           (shows a small window with that text!)
 23  - SIP and cellphone tests:
 24      - chat, shell:   termux (HUAWEI) - fix SIP (Acer) to fix SIP (Samsung)             - PC (Packard-Bell)
 25      - chat, shell:   termux (HUAWEI) - fix SIP (Acer) to cellphone (Samsung, WLAN off) - PC (Packard-Bell)
 26  - start a presistent ollama session? e.g. to continue chat after some days
 27    support from ollama v0.6.3 onwards?
 28    here an example:
 29    session_id=$(ollama run $model --session)
 30    response=$(ollama run $model --session "$session_id" "$input")
 31  - processing of characters ",*,etc.:
 32    - in chat with LLM (if " is not closed then we have a problem!)
 33    - in TTS output (?)
 34    - also in shell or file-transfer (?)
 35  - STT: 
 36    implement it or document how to configure
 37  - TTS:
 38    loop used to replace sleep ${WAIT_START_TTS_SEC} in tts.sh is not working, find out why
 39    the current hard-coded values may not work properly in every system
 40  - GUI (option -g):
 41    - add sub-menus, e.g. showing selection options from available interfaces in order to select them for communication, TTS, STT
 42    - add support to restore cfg to default values
 43  - fix audio input/output interfaces as configured:
 44    - system default for communication only if not configured, otherwise minimodem fix:
 45      *** DONE (see # SET_COMM_IFS), but then rolled-back:
 46                in the tested solution minimodem is running in a background tmux session (or a screen session) with a pipe to cat | minimodem
 47                (in that case the sink-source remains always the same, i.e. interface_index_minimodem_in/out are set once and are working as expected)
 48                but in that case the communication gets very unstable due to synchronization issues in minimodem, and probably also due to buffering in pipe, cat or tmux/screen
 49                alternatives using a named pipe instead of cat, or a temporary variable or file did not work as minimodem gets called several times
 50                A "dynamic" solution which detects the current sink-source used by minimodem which each call was not implemented
 51                because it may bring timing-problems as is the case when setting the TTS sink based on the sink-input
 52                A generic solution using virtual sinks and load-module in pulse audio may also not work when the sink-input changes with each call to minimodem.
 53    - TTS audio interfaces could also be set once for the App at system level instead of setting them with each call
 54      (see example solution for espeak in set_espeak_output.sh which does not work for festival.
 55       Decide wether to use it and lose support for festival - and probably other TTS tools.
 56       A generic solution using virtual sinks and load-module works fine but it's too complex and brings problems when reloading modules.
 57       Nevertheless, this seems to be the correct solution to set audio interfaces once.)
 58  - extend session initialization to support AUTONEGOTIATION, that is, agreement on:
 59    - protocol version
 60    - BAUD
 61    - NEED_ACK
 62    - etc.
 63    Use default 300 or 1200 baud for initialzation, then switch to negotiated transfer rate.
 64    *** ADJUST VOLUMES on both sides AUTOMATICALLY during session initialization also !!! ***
 65  - GUI like AC4QGP:
 66    "merge" AC4QGP and tea2adt or just "pipe" adapted AC4QGP to tea2adt
 67    (we may need to use AT commands or something like that)
 68  - test long-range with walkie-talkies (up to 6 Km in theory!)
 69  - sniffer: add new option and file mmrxsniff.sh
 70             with no pwd: like mmrxnopwd.sh but removing the ACKs
 71             can also easily reuse mmrx.sh to impl. sniffer?
 72             otherwise, with mmrx.py
 73  - new option to use tmux split-window -v i.o. konsole -e -> just config?
 74  - check at startup if the configured terminal is available and use system default instead or install with sudo apt install as required
 75  - use case with 2 offline-devices, test interface configuration:
 76      the Receiver offline-device could as well receive over a 2nd audio interface the data being sent and then decrypt it to show the complete conversation on the same screen:
 77                          ----->  receiver     <--
 78            internet-PC                           | 2nd. audio interface 
 79                          <-----  transmitter  -->
 80  - PEP8 for python code
 81  - improvement:
 82    configurable option: prevent user input during transmission (indicated by missing prompt cursor)? -> adapt mmtx.sh
 83  - create a new optional parameter to determine the round-trip delay "automatically" and use this value i.o. retransmission_timeout_sec
 84    this value can also be checked during the user session in order to monitor it dinamically e.g. in order to re-adjust it
 85  - use regular expressions to detect damaged "-----BEGIN PGP MESSAGE-----" and "-----END PGP MESSAGE-----" and restore them
 86  - test offline chat apps communicating over bluetooth or wifi
 87    check apps for:
 88    wireless ad hoc network (WANET)
 89    mobile ad hoc network (MANET)
 90    smartphone ad hoc network (SPAN)
 91    e.g.: 
 92    P2P Offline Call (only Android 13 ?)
 93    NOKs:
 94    -----
 95    Bridgefy (Google account? -> chinese text, bad reviews),
 96    Briar (only text messenger, no call),
 97    Bluetooth Chat (only chat and images, and only Bluetooth), 
 98    Signal Offline Messenger (not available, like many other apps),
 99    TrueConf(WiFi - but Google account? -> email not accepted!), ...
100  - BUG: verbose = true:
101        produces glitches which in turn produce "binary data" = lack of sync, leading to very unstable behavior
102        find out how to avoid this or remove this feature!
103        so long use with care and be aware of this problem
104  - BUG?: with start_msg and 700bps: simultaneous TXs in chat: messages seem to arrive ok, but ACKs seem to collide in logic, check setting of flags.
105          but there seems to be in fact a problem with the configuration. TODO: try RND delay before retransmission.
106  - derive more complex/secure pwd from user-pwd using a hash algorithm (but without salting!)
107    For deriving more secure passwords, key derivation functions (KDFs) like PBKDF2, bcrypt, and Argon2 are recommended. 
108    These functions are specifically designed to be computationally intensive, making brute-force attacks more difficult. 
109    They achieve this by applying the hash function multiple times (iterations) *** and using a salt *** -> can avoid this step?
110  - more tests with Virtual Machine(s)
111    e.g. split audio-in/out in 2 VMs sharing tmp folder over nfs: need code adaptation?
112  - remove:
113    - delay before ACK...was needed because of TRAILER, but now we don't use it anymore
114  - improvement: variable retransmission timeout:
115        TODO: long timeouts only in cases where request + response are long
116        otherwise short or proportional to estimated maximum lengths  
117  - improvmeent:
118    additional measures like signature verification as recommended here: https://github.com/ClarkFieseln/AC4QGP/issues/2
119  - investigate:
120    - how to deal with system sounds
121      (with 9.6 kbaud it was still possible to transmit information with ACKs even as music was played in the background, but the comm. errors increased)
122  - traffic masking? e.g. if minimodem TX continuously...can hide also metadata, e.g. nr. of messages, etc.
123  - support for password-protected pre-shared keys (PSK) -> see GPG
124  - add support of signature
125  - provide "forward secrecy" meaning retrospective decryption of unlogged messages is impossible
126    (warning: PGP lacks forward secrecy, once private RSA key exfiltrated all past and fufure communication can be decrypted passively)
127  - improvement: performance:
128    implement everything in C or C++ to gain speed, readability, etc.
129    (relatively small performance gain, e.g. of 15ms, as the biggest delays are introduced by gpg and minimodem)
130  - plausibility checks on configuration parameters
131  - similar to TFC-Installation: protection measures (see here: https://github.com/maqp/tfc/wiki/Threat-model)
132  TLS-MITM attack during installation
133  As long as the user has a way (face-to-face meeting with the developer or web of trust) to obtain the authentic fingerprint of the PGP key used to sign the installer, installation is mostly secure against MITM attacks. TFC is installed with a one-liner, the pinned SHA256 fingerprint of which authenticates the 4096-bit PGP/RSA signature verification key, which in turn authenticates the installer. If the attacker has a sufficient universal quantum computer that is capable of running Shor's algorithm, the authenticity of the installer cannot be reliably guaranteed with PGP signatures. The installer comes with pinned SHA512 hashes of all files downloaded from TFC's GitHub repository. These files include the requirements*.txt-files that contain the SHA512 hashes for dependencies downloaded over PIP. However, TFC requires dependencies (namely git, libssl-dev, net-tools, python3-pip, python3-setuptools, python3-tk, and Tor) that are downloaded with APT, and while the related public signature verification key is pinned to the OS, the exfiltration security of the private signing keys of third parties cannot be guaranteed.