-
-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-human (bot) interface #104
Comments
What distinguishes a human interface from a bot interface? Are we going to start presenting CAPTCHAs? :) |
For example, no ANSI colours and a machine parseable interface -- eg, JSON |
Ah, well there is /theme mono which removes all colors. No plans for JSON yet, though. Maybe someday. |
The line based format is ok when building simple bots (like my ssh-chat-bot) But it would be nice to be able to identify as a bot so that human users could opt to filter out potential noise. |
There is no way to force bots to identify themselves as such, /mute command will come eventually to let you silence whoever you don't like. We can also add better throttling heuristics if anyone has ideas. Most likely implementation of a non-human interface is maybe something like TERM=bot env variable which will skip PTY handling and won't set a prompt. |
I was thinking that well behaved bots should have an option to identify themselves as bots, since we don’t have control over the clients. I’ll experiment some more with my little bot. |
I was thinking of exposing the TERM variable in the /whois (any objections?), so that may help further in identifying people vs bots. |
Ah, that might be a good way to do it. (Unless there are security implications in doing so) |
I think that is fine. It's your fault if you use an insecure version of bash anyways. |
@chexo3 This is unrelated to bash, it's your terminal (that you might run bash inside). No, I don't think there should be security implications. But someone correct me if I'm wrong. |
Perhaps another way forward would be to use the SSH "exec" session request rather than "shell" session request to differentiate the protocol-based interface from the UI, leaving the "UI" with shell. Then someone could do "ssh server sshchat/1.0" to get the protocol interface v1.0 and a session would be established, or an error returned in the form of an exit code. |
IMO setting a TERM variable to bot or readline something would be the cleanest thing to do. |
I'd argue against passing environment variables in a "shell" session because there's no right answer -- setting it to "bot" isn't good enough since someone in the future may define a "bot" terminal (probably not) and we can avoid ambiguity thanks to SSH's existing features. |
Since we did a bunch of changes to how we render things in the last release, we probably broke most bots. I'd like to provide a more barebones output for bots for the next release. My current thinking:
My only concern right now is whether it'll be too hard to do the mid-session |
I think the exec session request is probably the best idea. You can use the TERM variable in shell mode to enable support for extra terminal features. |
@chexo3 Why is it the best idea? What about my reasoning do you disagree with? |
I'm sorry, I wasn't trying to impose. I'm not too versed with the ssh protocol, but I thought that using the exec system was an easy way to ask for a specific service and interface for that service. you don't have to worry about environment variable issues, you can do something like |
To clarify, so you can ask what interfaces are available (first example), join a specific channel/room, (second example), use a special interface (third example, could even have an TTS interface for eyesight-impaired people) |
I don't disagree that having exec commands is a thing that is possible--it is in fact something I want to use for other features, I'm just trying to understand why that's better for describing what kind of terminal encoding is supported? Could you expand on what you're referring to by "worry about environment variable issues"? |
You don’t have to worry about someone making a terminal or having their terminal set up in a way that it conflicts with the bot mode. In that sense the exec commands to enter bot mode are a command/endpoint like any other. Like /bot, but it’s more convenient for bots that need to start working immediately. |
As I mentioned in #104 (comment) I don't believe this is a problem, so I think we're fine.
env commands as much commands as exec commands. It's just another kind of command in the request/response loop.
FWIW I'm not sure interactive /bot mode will be possible easily, but we'll see. |
It seems that the TERM is not even set if there's no pty (it's set with the pty-req, not env vars), and I personally don't know why a bot (or 3rd party client) would want a pty. Another solution might be to just have a different environment variable such as SSHCHAT_FORMAT, though shazow disagrees. I guess it's not a big deal to use TERM with a pty, I just don't see why. Also since #333 supports SSHCHAT_THEME=mono a bot mode seems less important, we could potentially reserve a bot mode for something a bit better. I do like the idea of a JSON mode, however. |
This was completeld in #341
From an ssh protocol perspective, you can use either I like the idea of adding a |
Publish the conversion happend on 2019-03-23 for some ideas.
|
I'm sure I saw a bot known as Hubot last time I logged in, amongst the now-frequent spam from various miscreants.
I wonder, is it using the regular human interface?
Perhaps we could have some kind of API to make a bot, remote or local.
The text was updated successfully, but these errors were encountered: