Is /https deprecated?

[MarcoPolo]

The (protocols.csv](https://github.com/multiformats/multiaddr/blob/master/protocols.csv?plain=1#L31) claims /https is deprecated, but the source of truth multicodec table does not make that claim.

The deprecated claim was introduced in #109 which was a nice effort to sync this repo to the multicodec repo. It seems like deprecating /https was mentioned in the PR that introduced the /tls multicodec. But it was only mentioned as a future option, not something that was actively pursued.

Since the multicodec table does not deprecate /https (and with the extra context of the origin of the original claim), I don't think /https should be deprecated in this repo.

---

But, should it be deprecated in general? I don't think so. We've seen a lot of people use /https components in the wild, and prefer it to /tls/http. It also feels more natural to use /https because it's a lot more common across the internet. I think this should be an alias to /tls/http.

Do folks disagree?

cc @Stebalien who might have opinions as the approver of #109 and author of multiformats/multicodec#145

(The same arguments here apply to /wss and /tls/ws)

[Stebalien]

We should switch to /tls/ws, and /tls/http, yes.

Note: multicodecs themselves don't really get "deprecated".

[MarcoPolo]

What's the argument to not treat /https as an alias to /tls/http?

[Stebalien]

Reducing complexity, eventually? I don't feel about one versus the other, but we definitely shouldn't support both /tls/http and /https. We'll have to for now, likely, but we can deprecate /https eventually.

[MarcoPolo]

I agree it's nice and better to support a single format rather than multiple. /tls/http is better because there's a place for the /sni component (/tls/sni/example.com/http).

I don't have a strong opinion on not deprecating /https. Although I have a feeling some folks may be annoyed at having to use /tls/http instead of /https. Maybe I'll tag @olizilla, since I think they've been making some /https multiaddrs recently.

If there's no counter-opinion, I'm okay to close this issue as "Yes, we're trying to move away from /https and prefer /tls/http".