Comment by 🦂 zzo38

=> Re: "Could httpsy ---note the final y--- be adopted for use in..." | In: u/Bosque

This is multiple things involved.

I had previously defined a "hashed:" scheme in the Scorpion protocol specification (which is actually independent of the protocol), but it is for ensuring that the file that you linked to is the same one that was intended (that it hasn't been changed). HTTPSY is a different consideration, where it includes a key fingerprint; however, a similar scheme like "hashed:" can be used but with a different name (and still independent of the protocol), and this one will be used to verify the server instead of the file.

It also mentions a redacted part of the URL. Gemini doesn't have Referer header (Referer header is not really a good idea anyways), so that is not applicable. For server logs, that will depend on the server implementation of course. For display in the client, the software should allow the user to display them anyways if wanted even if they are hidden by default, and even when they are hidden, the display should include a marker to indicate that it has a hidden part. (Scorpion protocol specification says something similar about the password part of the URL; it can be redacted in a similar way. Gemini URLs do not include passwords. Spartan allegedly does but the password is worthless in the case of Spartan, so I don't know why they did it that way.)

The "httpsy" scheme reuses the username/password for another purpose, which means that you cannot use the username/password, then. (This is not a problem with Gemini, which already does not use them. But, as I had mentioned before, it could be made independent of the protocol, but that would involve a different format anyways.)

=> 🦂 zzo38

Jan 07 · 12 days ago

Original Post

=> 🌲 Bosque

Could httpsy ---note the final y--- be adopted for use in Gemini? (In theory, etc...) [https link]

=> 💬 1 comment · Jan 07 · 12 days ago