When I started using Winbox4, and wireguard, I realized it needs much work! The GUI IMHO is not particularly useful, efficient, or intuitive. Everything is mushed onto one page and one has to sift up and down to find the right information to enter and of course we know there are errors in the current implementation ( allowed IPs being one ). Then there seems to be half thought or more likely incomplete processes presented (in development).

For example, there is an import function is located on the main wireguard interface page, but how do you know which interface this is supposed to apply to? Are you importing an wireguard interface or a peer? When one selects and interface, there is no IMPORT function, which would be the more useful place to have an IMPORT selection??
I personally cannot think of importing files at the router or MT device yet, but there may be some good use cases. I would rank this low on priority.

To compound the strangeness, when you click on an interface, there appears to be an EXPORT function. All one is doing is creating a file name and sending it to the FILES menu in Winbox. There is no option to select which peer has been created for export ???Similarly to the EXPORT function, how do you actually select which peer one is exporting?

Thus if MT is still in development for these items, it would be a good time to sit down and figure out what are the most common scenarios to generate peers and what information is required.........and the following discussion/presentation is what I came up with.

The only assumption I make is that one has first created the wireguard interface and the logic follows.
Please feel free to tear apart, or ADD etc. to make it better!!!

DISCUSSION:
(1) New Wireguard Interface Creation Process
Discussion: Overall. the current Wireguard Interface creation menu (New) is acceptable except for the ambiguous nature of the private key. A plus symbol is used to indicate a manual private key entry, typically only used in a third-party VPN scenario, where the private key is supplied to the admin. Not intuitive in the least is that if one makes NO selection of private key, and then selects APPLY or OK, a private and public key pair will automatically be generated. This is valid for creating a public key that will be used for all other peers that generate their own key pair. To remove ambiguity and for a better UI experience, suggesting the options be made clearer.

Selecting Auto Generate would then display a private key and a public key in the grey areas.
Selecting Manual would allow entry to the box to the right. After key entry, the public key would be generated below it. Only the manual key box would be modifiable.
Each interface creation typically has two other related activities that need to be executed. The first is an input chain rule, however we are not suggesting this for automation or entry here, as placement of the rule is an admin decision. The second item, that is not mandatory but is used 99.9% of the time, is the address of the wireguard network
Thus proposing that the addition of the address can be done here (Optional). Suggesting that the current text entry of TYPE WIREGUARD.

The wireguard interface can be created without IP address, it is optional. If the IP address is entered here, it auto-populates the corresponding fields in /ip address.
Upon completion of the wireguard interface, the ROUTER Should provide an warning message that states a wireguard IP address should be created at /IP ADDRESS.
This would only be shown if the Optional field was NOT utilized.
...................

Discussion for the Peer Creation Options:

(2) New Peer Creation Process
Discussion: The current peer creation process is an attempt to squeeze a number of processes into one page and from a UI perspective fails to be an intuitive and clear approach. After some review, even though there is overlap in these processes it is felt that the distinct scenarios would be useful markers for entry. These markers would be Manual Peers (key-pair generation at both ends), Third Party VPN (no local peer key generation) , and Automated Peers ( no remote peer key generation). As well we will take advantage of MT BTH type functionality in terms of the concepts of automating peer profiles as well as exporting peer profiles. Upon review, it is not possible to overlap entries without causing confusion and we will use automation/logic as much as possible to simply entry.
.............. ............... ..............

Suggesting that three options be presented to the admin based upon available wireguard interfaces. The next three diagrams depict when the Admin Has selected NEW PEER and NEW is now highlighted. Instead of bringing up the peer creation page, it merely makes the three types of Peers Visible to the right of NEW. The admin chooses the appropriate type which then opens the Peer Creation Page and takes him/her to the start of the appropriate section of the peer creation page. The first sample view shows when no Wireguard interface has been created and thus one cannot create any new peers. The next , depicts what is available when no Wireguard interfaces are available/created with a manually entered private KEY, and the last, if ONLY wireguard interfaces with manual private keys have been created.
........................ ........................

Manual Peer creation ( key-pair creation at both ends )

This process addresses setting up the router as a client peer for handshake and setting up incoming client peers. The entry process for ‘manual’ will consist of first entering the Interface Name from a pull-down menu. The next common entry argument is public key from the peer. The next entry should be allowed-addresses. That concludes the most basic entry, and Apply/OK could be entered at this point. In the case of the router being a client for handshake, including the mesh setup, then the next entry is endpoint address. The endpoint port is defaulted to the Router listening port but is modifiable. The next entry is persistent keep alive. This constitutes the second entry criteria and selecting Apply/OK is valid. There other available option is pre-shared key.

3rd Party Peer creation ( no local key-pair creation).

This scenario covers the use-case for when the Router is a client peer for handshake from any other device and typically it’s a 3rd party VPN provider. The difference from Manual Peers is that the private KEY is generated by the 3rd party, not by the MT device. The 3rd party ( or other MT router ) provides a private key for you to use to generate the key pair and thus your public key is already known at the remote device.

The first entry will be interface identification and the router will default to the first Interface on the list with a manually entered private key. This will be followed by the endpoint information. After the selection of Allowed Addresses, and Persistent Keep-Alive, the basic entry has been reached and Apply/OK can be selected. Additional optional entries are available, such as Name of peer, Comments and pre-shared key.

Automated Peer Creation and Dissemination ( no remote key pair generation )

The final menu selection area allows the admin to quickly generate Peers with a one-way path for information, meaning that there is no swapping of keys. In this use-case, the router generates a random private/public key pair for the client peer. The receiving remote peer will not be required to generate a key pair and will already have its public key on the MT router and will also receive the Routers public key (from interface settings) in the file export.

The first entry is Interface selection. You will have noted that the admin has the option to create the wireguard IP address when creating the Wireguard Interface. Once the member enters in the Interface Name, and an IP address has not yet been selected the Admin will be prompted/warned to input the IP address BEFORE PROCEEDING. None of the other entries will be available until a wireguard ip address has been entered. When available the next field, the client address will be defaulted to the next available sequential wireguard IP address and is modifiable. The next entry is Client DNS and it defaults to wireguard gateway address of the router and is modifiable. Next is the endpoint address which defaults to the routers mynetname.net and is modifiable. The endpoint port is not required as it is pulled from the interface listening port. Allowed IPs are then entered and defaults to 0.0.0.0/0 and is modifiable. Finally, the Persistent-Keep alive setting, defaults to .30s and is modifiable. MTU defaults to the interface MTU, but is modifiable. That constitutes the basic entry point for selection of Apply/OK

Once completed, the admin will have the option to export (push) the peer file via the medium of file transfer chosen, OR be able to provide the peer client with an URL (pull) location that they can download the file from. An export file can be in two forms, a QR code jpeg, or the standard Wireguard export format.

After selecting Apply/Okay for the automated peer, the router displays a visual representation of the QR Code, probably to allow someone to take a photo/snip to send to others. Next to the QR code will be Two Export Selections for the admin and only one can be chosen. After the choice the FILE NAME field is available to accept or modify. If one selects URL download the Share location will be available and default to internal memory but is modifiable to a path entry for a file share location (external media). Expiry of never will not be permitted for security and storage reasons. Limit is 48 hours. An optional share key is available for the URL download.

EXPORT

The last bit of cleanup concerns importing and exporting of wireguard files. We have the EXPORT option as part of Automated Client Peer creation, because it makes most sense to put our export efforts there. If MT is willing to expand this effort then suggest the EXPORT TABLE also be made available when creating Manual Peers as well. This would alleviate some of the work of the ADMIN but keep in mind the client device would still need to execute a key pair and send the admin the remote device public key. I see no real advantage at this time to contemplate any import functionality.

Blue squigglies on the diagrams are my attempt to show mandatory entries.
One should note that much is based upon having made the wireguard interface first, as this is a reasonable assumption.
Where possible, admins may or may not select fields depending upon logic.
Ignore the poor quality and non-standard type MT entry icons/usage as I am art-challenged and used clipnsave, and paint.

Please feel free to critique and improve the presentation/format/logic !!!

BLANK FOR FUTURE IDEAS

On feedback from MT, some changes could be made to re-arrange the menus and thus the next attempt will be to do so, while preserving the overall concept of form follows function.

The approach to the wireguard interface is simply superior and should be adopted, including the option to add IP address from this location.
.................. ..................

The same goes for the options available but they will be presented on the SINGLE PEER page instead of the WIREGUARD MENU.
Thus one will still select NEW to access the peer creation page.
.................... ...................