Rename SSH3 => SSHH3 ?

[telamon]

This project is not an iteration of SSH as it does not extend the SSH protocol itself and is not compatible with existing clients nor tooling and runs on a completely different port and server architecture.
Which leads me to assume that the number 3 was acquired from the use of http/3 proposals.

As such the long form description is "SSHv2 over HTTP/3" so my question is:
Wouldn't it be more correct to shorten it to sshh3 or sshh ?

-- You've created something cool but completely different :-)

[jas4711]

Indeed, command-line completion and package naming will be confusing wrt existing ssh. How about shh? That name seems unused. Or hsh as in HTTP Shell.

[nileshpatra]

/cc: @francoismichel it'd be great to have your opinion on this.

[stappersg]

Short: Please do s/ssh3/sshh3/g, global substitute "ssh3" with "sshh3".

Several years ago there was use SSH2, because SSH1 has security flaws. Today I heard about ssh3 and was thinking "O chips, need to update all SSH2 stuff". Then I learnt this actual sshh3. :-/

The it is a poor name is also expressed in https://lists.debian.org/debian-devel/2023/12/msg00213.html and it's follow-up messages.

And in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059618#26 is stated:

I share these concerns, so I'll delay the upload for now. I'm hoping
upstream will rename the project to something less confusing.

[mikelolasagasti]

Another option could be soh for "SSH over HTTP" or "Shell over HTTP".

Waiting on the final decision to package this for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2256027

[stappersg]

Please do s/ssh3/sshh3/g, global substitute "ssh3" with "sshh3".

It became h3sh, inspired by https://lists.debian.org/debian-devel/2023/12/msg00225.html

something as simple as naming it h3sh would have avoided the brand confusion

There are merge request #85, #86 and #87. That last one:

stappers@paddy:~/xkcd386/h3sh
$ git show
commit 22b6ac4b4be0f8203e6103ef8c4ebe038239f5ba
Author: Geert Stappers <[email protected]>
Date:   Sun Dec 31 13:38:15 2023 +0100

    Explaining the name.
    
    Because we can't afford ourselfs the effort to explain
    all the SSH users that this is not SSH3.
    
    Signed-off-by: Geert Stappers <[email protected]>

diff --git a/README.md b/README.md
index bb767ae..a81f99b 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,7 @@ Among others, H3SH allows the following improvements:
 > [!TIP]
 > Quickly want to get started ? Checkout how to [install H3SH](#installing-h3sh). You will learn to
 
-*H3SH* stands for the concatenation of *SSH* and *H3*.
+*H3SH* stands for *HTTP/3* and *shell*.
 
 ## ⚡ H3SH is faster
 Faster for session establishment, not throughput ! H3SH offers a significantly faster session
stappers@paddy:~/xkcd386/h3sh
$

And regarding the "appears to be intentional" from

Even something as simple as naming it h3sh would have avoided the brand confusion while communicating the purpose of the package. This does not appear to be a case of "unknowing infringement." It appears to be intentional.

Younger versions of me also did intentional "this will be funny" and got back "not funny" that made me better.

[jas4711]

IMHO typing h3sh at the command line is not that pleasant. I suggest not using a digit in the name. Let's use a name that is unique and where typing and tab-completion is simple and package naming doesn't conflict or confuse with existing projects.

[stappersg]

On Sun, Dec 31, 2023 at 05:46:24AM -0800, Simon Josefsson wrote: IMHO typing `h3sh` at the command line is not that pleasant. I suggest not using a digit in the name. Let's use a name that is unique and where typing and tab-completion is simple and package naming doesn't conflict or confuse with existing projects.

s/3/e/ gives hesh. Yes, much more pleasant to type as h3sh. https://duckduckgo.com/?q=hesh didn't show conflicts with software projects, nor with SSH. -*H3SH* stands for the concatenation of *SSH* and *H3*. +*HESH* stands for the 3 in *HTTP/3* mirrorerd into E and *shell*. Happy New Year Geert Stappers -- Silence is hard to parse

[francoismichel]

Sorry for the delay, I am currently out of office.

I have no problem with rethinking the name, and I am also okay with distros renaming the binaries
however they want right now. I am happy with people discussing this here and I take note of the suggestions. We however may want to wait a little bit before applying renaming on the whole project. I think the question about naming will become clearer once we get to discuss the project at IETF in March. We discussed
a few alternative name ideas. shh is one of the candidates that I like, the only thing I don’t like in it is that it looks like an ssh typo. shs can be cool as well.
I am a bit less convinced with names with the « 3 » in it as one of the goals could also be to make it support HTTP/2 (again, this might become clearer after a few IETF discussions).

I think waiting until March-April would help us coming up with a more solid name, and that would also give time to other people for discussing names here as well. In the mean time, distros naming it how they want if they don’t like ssh3 is okay to me, the packages would probably be proposed for unstable distribution releases anyway.

Meanwhile, Happy New Year and thank you for the thoughtful comments and the momentum you give to the project ! I am really looking forward to the release 0.1.5 that includes a lot of cool improvements that will make it great for day-to-day use :-)

I let the issue open right now as I would like to keep getting more feedback in the meantime.

[iustin]

My 2 bits here as a random small open source developer. March is 3 months away. Keeping ssh3 for another 3 months especially as "3" should not be in the name (per your comment) doesn't make sense.

Just rename it to a random, even long name for now - ssh-over-http3, and in March once the future goals are clearer, find a good, proper name.

[jas4711]

Maybe if someone can create a pull request with ONE proposed naming, and if we distributors can all agree to use that, pending a final decision? I'm preparing packages for Debian. If some other packagers can agree on a name, we can get consistency even if upstream wants to delay the decision (which is entirely reasonable).

I've done some typing tests, and my prefer is shs because it is fast to type on a keyboard. Repeating the same character on a keyboard as in ssh or shh is slower than alternating characters like shs. The acronym would be Secure Hypertext Shell which actually makes a lot of sense.

Thoughts? For packaging purposes, I think it is sufficient to rename the binaries /usr/bin/shs and /usr/bin/shsd, as I'm thinking the ssh3-server binary would eventually be extended to implement daemon-like functionality. I think shsd should not be in /usr/sbin as users may want to run it too, as a non-root setup. Project documentation and golang name stays the same. Thoughts?

[CameronNemo]

I like soh (could be an acronym for the specific "SSH over HTTP3" or the more general "Shell over HTTP", depending on where things go) personally, but shs doesn't seem terrible to me. I do find the acronym for shs ("Secure Hypertext Shell") to be a little weird... is there any actual hypertext in use? AIUI no.

[francoismichel]

Maybe if someone can create a pull request with ONE proposed naming, and if we distributors can all agree to use that, pending a final decision? I'm preparing packages for Debian. If some other packagers can agree on a name, we can get consistency even if upstream wants to delay the decision (which is entirely reasonable).

I like this idea, enabling us to have common package names without renaming in a hurry. Time will also tell us if the common package names is a good candidate for being the potential long-term name. I like soh and shs, I am just a little scared of shs being close to an ssh typo. It might be worth having the opinion of several people involved in distros packaging.

[francoismichel]

Iterating on this, what do we explicitly need in such pull request for distro packages ? I am not sure we need to rename every file, every object and package, we could stick to changing the binaries names, logging and readme for now, that would make the PR a lot lighter and probably a lot easier to maintain up-to-date with upstream.

Thoughts ?

[jas4711]

I like soh and shs, I am just a little scared of shs being close to an ssh typo. It might be worth having the opinion of several people involved in distros packaging.

Yeah, the acronym for shs is less good as @CameronNemo noted. I did some typing tests for soh and for me it involves using either three fingers (which cognitively takes more resources than two fingers) or movement of one finger (which also takes resources). Overall shs feels faster to type though. Yes, I am doing premature optimizations =)

[jas4711]

Iterating on this, what do we explicitly need in such pull request for distro packages ? I am not sure we need to rename every file, every object and package, we could stick to changing the binaries names, logging and readme for now, that would make the PR a lot lighter and probably a lot easier to maintain up-to-date with upstream.

Thoughts ?

• Rename binaries /usr/bin/ssh3 and /usr/bin/ssh3-server
• Rename ~/.ssh3/ naming? for consistency with the binaries
• ?

I think settling on naming is going to be the main challenge to get this packaged, at least for Debian. Doing an upload, even to experimental, only to later have to rename it requires some manual steps, so I'm reluctant to do that just now.

[iustin]

I don't think the optimisation here should be fast typing. shs or soh is almost the same. Yes, there's a difference, but IMO it's way more likely that one will mistype ssh as shs or viceversa, than be bothered by the slow soh typing.

I would vote for moving ahead with soh.

[jas4711]

I don't think the optimisation here should be fast typing. shs or soh is almost the same. Yes, there's a difference, but IMO it's way more likely that one will mistype ssh as shs or viceversa, than be bothered by the slow soh typing.

I would vote for moving ahead with soh.

Works for me if we can agree on it -- any other packagers here? Which distributions are interested?

[mikelolasagasti]

Fedora and potentially EPEL packager here, fine with soh (I proposed it 😅).

[francoismichel]

Great. I can make an soh release based on version 0.1.5-rc3 (or rc4). I think the new ProxyJump support (#44) makes it more usable so let's include it in the release.

[mpiraux]

I'm very fine with soh for all the reasons discussed here :)

[stappersg]

There is now #96 which has

Two main reasons:
Dropped the 3 to be ready for HTTP/2
Avoiding confusion with OpenSSH. ( We don't want to panic SSH users to update their SSH. And we don't want to keep explaining this project is not next OpenSSH release.)

in the commit message.

Regarding

Iterating on this, what do we explicitly need in such pull request for distro packages ? I am not sure we need to rename every file, every object and package, we could stick to changing the binaries names, logging and readme for now, that would make the PR a lot lighter and probably a lot easier to maintain up-to-date with upstream.

Thoughts ?

I think the name "ssh3" did serve it's purpose, it did bring this project attention. Now the project deserves a better name. The sooner, the better.

[telamon]

Reverse it?
hss

[francoismichel]

Thanks for the PR, I'll have a look at it at the beginning of next week.
As I said, I am fine if the binaries get named something else than ssh3. For the protocol in itself, we'll see after a few IETF discussions if it becomes a version of SSH or something else, but it will probably be presented as an SSH version: it really implements the SSH connection protocol.

Reverse it?
hss

We kind of agreed on a package name but I am okay if people want to continue to propose, I just think we'll stick to soh for packaging right now. It would be great to have a place easing propositions and votes.

[rbalint]

Reverse it? hss

Think this is quite good, HTTP Secure Shell, or HTTPS Shell.

[ledlamp]

hsh

[stappersg]