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 <stappers@stappers.it>
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 <stappers@stappers.it>

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 =)