RE: Detailed Guppy v0.2 Feedback

(edited 2023-08-11)

This is a quick list of thoughts, while going through feedback again. I'm still fixing v0.2 and preparing a v0.3 that fixes some things, and (stubbornly) retains some things that probably look like bad decisions to many readers (maybe like the entire effort, and that is OK, too).

I'm also updating the reference client and server implementations as I make changes, to make it easier to provide feedback if you don't want to read the protocol spec:

Server (side branch of tootik)

Client (side branch of gplaces)

And big thank you, @acidus, for the great attention to detail, the patience and the good will. I appreciate you a lot.

More feedback is welcome!

> How does the client which of these options an error packet means?

It doesn't!

> I found the system for the client to inform the user that user input is required confusing.

If the request has failed, the client shows the error to the user, instead of failing silently.

If the request failed because this is a dynamically-generated page that needs input, the client tells the user that input is expected, instead of failing silently.

> I suppose this could be done with the error packet's error message, but:

> * that is language specific

> * that makes writing a client harder.

Link text is language-specific, and so are prompts and errors. The problem of internalization should be handled outside of the protocol, in documents and CGI code.

> Make input be denoted by an error response also also means that an the author would need to configure the Guppy server to return this error, for every URL that needs user input. This sounds onerous, and its possible the content authors don't have access to the server configuration (think pubnixes).

Is it wrong to assume that most pubnixes only host static content (= no need for input prompts), and those that don't, allow users to put their stuff in a cgi-bin directory (= user has full control over the response)?

> If Guppy wants content authors to be able to inform users that input is required, I feel a Spartan-Style `:=` line type would be the best solution. Consider these two experiences:

>

> Using an error packet to signify user input:

> [...]

>

> Using a `:=` line:

> * user downloads gemtext

> * user clicks link using a := line

> * client prompts user for input, and requests URL with that user input

> * user gets response for user input

There's a third option.

When links have human-readable description:

user downloads gemtext

user sees a link that says "enter search keywords"

user right-clicks link and selects "send input"

client prompts user for input, and requests URL with user input

user gets response for user input

> Consider using a status code (like 2) for Success, just like Guppy does for errors and redirects [...]

A packet is a success packet if:

There's more than one digit before the space, or

There's a single digit, but it's not 0 or 1

This is a redirect packet:

This is an error packet:

But this is a success packet:

And so is this one:

But, I agree, it's a good idea to change the status codes so they match those in Spartan or Gemini.

> Right now, a Success packet cannot be empty.

This is intentional, becuse this simplifies clients. If the success packet can be empty, the client has to acknowledge it and wait for the first continuation packet before it can display anything.

When the success packet cannot be empty, the client sends the request and has something to show before another round-trip. I believe most users don't read fast enough to read the first response chunk before the second is received, or navigate to a different page because this one is not interesting enough.

Maybe, the use of plain-text UDP would allow users to receive the beginning of the page faster compared to a TCP handshake (plus a TLS handshake), at the cost of slower transfer of the entire page, when the page is big.

> Redirects and Errors are not ACKed by the client, so the server has no way to know if the Redirect or Error actually made it to the client.

I don't see a use case where the server needs to know if a user knows what error has occurred, or needs to know that client was redirected to a different page (minus rare things like text-based games that don't store the game state in the URL).

Also, acknowledging the first response packet takes the same number of packets as re-sending the request, if the user wants to get another chance to receive the previous response.

> Guppy only allows one data packet to be in-flight at any time.

This simplifies the client a lot, especially if written in a low-level language. In a protocol with out-of-order packets, something (either the TCP implementation or the application) has to save all received packets, so it can reorder them and drop duplicates.

When the client receives the response in the right order, the only state it needs to keep across incoming packets is the sequence number.

> It appears that Guppy is just slowly re-implementing features of TCP, but in a less powerful

I think it makes sense to prioritize simplicity over throughput, if this protocol is supposed to transfer very small documents that can be transferred in 1-8 packets.

> or clear way.

Working on it! :)

> * Guppy is more complex than other existing unencrypted protocols (Spartan, gopher, nex, finger)

> * Gubby v0.2 and below are unreliable, as major parts like requests, redirects, and errors don't require acknowledgement.

True: if a request changes anything on the server, the human user has no way to know if anything was changed.

However, I assume that:

1. >80% of requests don't receive any input

2. Most CGI pages that expect input expect things like search queries, and not the body of a new post

3. If the request times out or fails, (usually) the user has a way to check if the input was processed (for example, by viewing the list of recent posts) or undo duplicate actions (for example, by deleting one post)