Initial observations

[Jordy3D]

Before I start, I am glad to see Cryptii evolving, and into a node-based editor no less.

That said, here is some observations from playing around with the current at the time version of ciphereditor:
General:

1. Nodes seem to have the option to get input from and output to variables, however actually knowing where those variables are coming from is not clear unless you've directly created them and noted the name of them. Having a list of these variables available somewhere would make things easier, especially if that list updates the values with the Graph, and if clicking on those variables took us to or highlighted the place they originate from. Alternatively, or in combination, having the variable name appear as a label next to the Node output could also help.
2. The blue button that brings up the Description of a node feels a little unnecessary. The Up/Down arrow on the button implies that it will shift things in reverse or something, but it only seems to bring up a Description box. If that's all it's intended to do, then I believe having the name of the node at the top of the Node would be nicer overall, and more clear as to what each node is doing. This could also go a long way in making Nodes easier to click without making something shrink or expand, which just feels kinda clunky.
3. The right-hand sidebar feels rather large when open, but the button to hide it also makes things feel odd to me. Perhaps having that button still be there, but supplemented by a bar on the edge of the side menu allowing manual resizing could help bridge that?
4. Zooming. I know you mention using the built-in Zoom functionality of the browser, but that's less than ideal in a number of situations. A dedicated ability to zoom, either with a scroll or with +/- buttons on the UI, would not go unappreciated.
5. Node input/output path collision. This is definitely less of an important thing than others, but it's still worth mentioning, if a Node is placed on top of a path between inputs/outputs, the path ignores it and continues as if it wasn't there. This could make more complex nodes a little less manageable. A tried to use Empty Control nodes as a sort of "relay" node, but that didn't seem to work as I expected.
6. When two Paths overlap each other, it can be confusing where data is actually going to/coming from. I know there's a dark outline around them that helps a little, but separating the two lines when they overlap may come in handy in certain situations.
7. Drag-to-Remove Paths. This is a feature I rather enjoy in some other node-based editors. It's not initially clear that you can click on a Path and then press Delete to remove it. I guess that could just come down to a future tutorial of sorts on how to use ciphereditor
8. While testing further, I seem to have accidentally had the sidebar display button disappear. I am not sure what caused this, but I had to refresh the page for it to return.
9. A dedicated right-click menu could also be nice. More so if it was similar to ones like Amplify Shader Editor for Unity, where you can right-click and start typing to quickly find desired nodes. Not so important now, but as more nodes and features get added... It may help in the long-term.

Specific Nodes:

1. On the Binary/Text encoding node, it seems rather unclear on how to flip the operation around (from text to binary, instead of the default binary to text). The "Alphabet" name for the setting in that Node doesn't really feel like it conveys a sort of "encoding mode" of sorts.
2. On the Word Counter node, the Character Count, Word Count and Line Count values seem somewhat inconsistent in the way they can be used. I assume this is down to the Type of the value.
3. The Case Transform Node has (and I assume others have) the ability to output their mode of sorts as a string for use in other nodes. However, the string they output does not match with the string we see in their relevant dropdown menu, instead using camelCase strings or other raw values. This alone is fine, but perhaps a preview of what it would output could be handy.
4. The OR, NOT and AND Nodes may be benefited by allowing other nodes to enter them (other than the other logical operator nodes). For example, if a Word Counter node's input results in an output of Word Count 1, that should be readable by the logical nodes. This could also work in tandem with:
5. A Switch/IF node. Changing the output path of data based on incoming conditions, such as "value greater than" or "string contains" or what have you can lead to deeper interactions between the nodes and more freedom overall.

I hope this didn't come across as too nit-picky or something!
I just really like node-based editors, and this would be a great application to see thrive going forward.

[ffraenz]

Hi @Jordy3D! Thank you for taking the time to leave this comprehensive amount of feedback. As sole contributor I much appreciate getting an outside perspective on the project like yours. Let me go through it point by point.

General feedback:

1. Yes, indeed, variables is a rather invisible concept as of now. It's main purpose is a more accessible approach to connecting one or more controls/nodes through the use/pull/push select in the control indicators and an alternative to dragging and dropping a wire (which can't be done through keyboard input). The status quo is far from ideal. I'll take your design considerations into account when I continue working on this.
2. The 'blue button' on an operation acts as the operation header (incl. the name) and sits in between controls most of the time. It should give a visual clue as to where the operation is executed and what the result is (e.g. separating plaintext & settings from ciphertext). The icon should support this, though you saw it as a way to flip the controls. The operation modal that opens by clicking the header will include everything about the operation not accessible on the node itself. You will be able to rename the node, remove it, show, hide and flip controls as well as view details about warnings.
3. Yes, a way to resize the docs by dragging the edge of it makes sense. I've added this to the backlog.
4. I was experimenting with having an app setting to scale the UI but bumped into limits imposed by the browser environment. There will be no app-specific scaling options in the near future. However, the app respects the browser zoom and font-size settings which can be adapted per site using +/- on most keyboards.
5. I'd like to sketch out the paths/wires automatically based on control and node layout and thus have no way of interaction planned to change their positioning manually. However, the initial layout algorithm is rather trivial, as you pointed out. To me the status quo is a good starting point, making things 'available', but it will definetly be reconsidered in the future.
6. I'm considering to add more variable/wire colors to improve on this.
7. How does a 'drag to remove' interaction look like? Do you have an existing example of it?
8. I keep an eye on the maximize/minimize button. If you find a way to reproduce it, you are welcome to file a bug issue ;)
9. You are suggesting to use the 'right click' interaction on the canvas to open a shortcut menu for adding new nodes as an alternative to the 'Add operation' modal, right? Could you add a screenshot of how this is done in Unity?

Operation feedback:

1. One very imporant difference between ciphereditor and other node editors is the fact that all controls (that are not read-only) are able to both take input and produce output. To decode base64 you may input it into the "Encoded data" control. The decoded data lands in the "Data" control. Like I mentioned I'd like to add a flip button to change the layout of the controls, though, this has no effect on how controls work.
2. Indeed, they are integer values and may be reused in integer input controls (e.g. to set the shift on a Caesar cipher operation). I'll introduce more operations to turn numeric values to text/binary in the future. The value type is displayed in the lower left corner of an expanded control and can sometimes be changed (if the operation supports it). You can find a list of value types in the manual. More value types will be added in the future.
3. Yes, labels and values may differ from one another. Labels should be descriptive and accessible while values should be unique and backwards-compatible. I see your point, I'm just not sure about how to show the raw value without cluttering the UI.
4. Indeed, as of now, there are no other controls that output boolean values. I'm not sure if implicit conversion of integer values to boolean values is the way to go here. But more operations (e.g. a condition evaluator) will be introduced in the future.
5. I would love to introduce structures but they also bring a lot of complexity and edge cases, especially as design & evaluation is done at the same time in ciphereditor. That's why I'd like to test and stabilize the status quo before getting to structures. Don't expect them anytime soon.

[Jordy3D]

Thanks for your prompt and detailed feedback!
Since you've answered most of my points, I'll only respond to ones that I feel benefit from further discussion at this time.

General:
5. I am definitely more than happy with how they are now, it was just a thing I'd thought of. That said, I felt the option of a Relay could still come in handy between the current status quo and a future "smart-path" of sorts. As displayed here, the Relay just acts as another route for the path, which may help in the interim, though is far from necessary overall.

7. Below is an example of this drag-to-remove nature I mentioned. This node-based system (Amplify Shader Editor, or ASE) has defined input and out-point points that are used for such interactions, so it's not 1:1, but I believe that dragging the arrowhead in ciphereditor may be a suitable alternative to achieve similar behaviour more readily.

9. Below is an example of ASE's right-click menu. There are other menus in Unity's world, but this I find is the most user-friendly approach overall.