Add unproto keyboard-to-keyboard

[jmkristian]

Thomas KK6FPP wrote:

I don't want to ask you to create such a modified version of converse.js just for me, but here is what I think it would take to do so:

The command-line and options would remain the same: local call sign # remains the FCC call of the operator, to ensure every transmission includes it remote call sign # Default is CQ, but actual use varies. 145.05 Net convention is operators First- or Nick-name (not matching any real node) but most importantly, the functionality doesn't change. It still is the destination address in the AX.25 packet (even though there is no such destination!). --via digis # same functionality as in the connected mode case, but tends to be even more important in order to carry the conversation over a wider range (digipeaters need to be carefully chosen by the operator to reach all participants of the group discussion but also need to follow a reliable path).

Since the conversation is not limited to a single recipient but open for others to participate, unproto communication usually prefixes all received packet data (just like having "Monitor On" in connected mode) with a line containing at a minimum "->" but often include the list of digipeaters as well (better clients will mark the heard node with an asterisk after the node name). Some clients include a timestamp in that Sender->Destination line (while that is helpful for logging, it can clutter the screen). The data within the received packet follows that identifying line and may spread over multiple lines if the packet had a large payload.

Some unproto clients will omit connected mode traffic (only show UI frames) that is being received and that tends to improve the keyboard-to-keyboard experience on a channel/frequency with mixed traffic.

Since it is not a connected mode session, the client application needs to have a way to terminate cleanly (such as entering Ctrl+] command mode and selecting Quit/Exit).

The existing command X to take input from a file is useful for unproto conversations as well, especially when it is known ahead of time what you are planning to say. Ideally you don't want to send a separate packet for every CR/LF found in an input file, instead sending a single packet containing multiple lines. There is however a gotcha when that input file is longer then the payload for a single packet and you are forced to split the input file over more than one packet. If you are sending the second packet too soon after the first, it very likely will "double" with the digipeater repeating the first packet (most keyboard-to-keyboard traffic will involve digipeaters, so this is an important issue). Therefore some delay is required which may depend on the number of digipeaters involved in the transmission. On the other hand you don't want to delay sending the second (and possibly more) packet too late which may result in other transmissions interleaving with the parts of this transmission possibly causing confusion in the recipients. Making long transmissions is being frowned upon in keyboard-to-keyboard mode, so this may be a rare issue. Perhaps another way of dealing with it would be to warn the operator if they try to use the X command to open a file that is longer than can be transmitted in a single packet.

A nice to have but not strictly required feature would be a command to list all heard senders whereby just a list of sender calls alone would already be fine. Better yet would be to have two options for such a command. One command to show the sender with the destination and via nodes and the timestamp when that sender was last heard (here too marking the node from which the sender was heard with a trailing asterisk is useful). Another command to list just the senders call and the first N characters (whatever fits on one line) of their last transmission (very helpful to a NC on a keyboard-to-keyboard net taking check-ins). Those command options would require additional functionality not currently present in converse.js (storing details of the last transmission from every sender that was received).

[jmkristian]

I think this should be a separate program (e.g. chat.js), not a mode of converse.js.

[jmkristian]

Version 1.3 includes a chatter program, with some but not all of these features.

[jmkristian]

Version 1.4 adds an X[ecute] command, but it doesn't attempt to avoid doubling with digipeaters, and it doesn't send multiple line in a single UI packet. I think it's not a good idea to do either of those things. An operator should not blast out a ton of UI packets at high speed; it's just rude. And other participants in a chat session reasonably expect to receive each line in a separate UI packet. Several lines in one packet would annoy them, I think.

The appropriate use of an X command is executing other commands or sending I packets on a connection. For example, I imagine it will be used to execute a medium-sized series of H[ide] or S[how] commands. It can send UI packets, but it should not send many.

The X command will send multiple lines in a single I packet in a connected session. (Under the hood, the lines are combined into a continuous stream that contains EOL markers, and then the stream is divided into packets.)