💾 Archived View for rawtext.club › ~sloum › geminilist › 002404.gmi captured on 2020-10-31 at 14:31:23. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

gemini+stream://

James Tomasino tomasino at lavabit.com

Sat Aug 15 00:39:20 BST 2020

- - - - - - - - - - - - - - - - - - -

Several of us had a fruitful discussion about gemini streaming over in the IRC channel tonight. For those of you who don't IRC, the full logs of the channel are available from my weechat logs, updated nightly at 0000UTC:

gemini://tilde.black:1965/users/fox/irc/log.txt

I strongly believe there's tangible value in having streaming support for the text/gemini mime-type. We have the lovely chatroom proof-of-concept out there already, and a few minutes of brainstorming came up with speech-to-text broadcast radio using Watson's speech-to-text engine. The cool ideas already floating around solderpunk's head in his gemlog about Gemini applications haven't been forgotten either. There's an untapped goldmine here.

That being said, the protocol has a very simple flow defined currently wherein a client makes a request, the server responds, ends the connection, then the client processes it. Changing that fundamental behavior to support streaming is not an insignificant thing to ask of client authors, and some will have no desire to do so at all.

We've talked in the past about possibly serving a different response code to signify to a client that this resource wants to stream, but that was countered with valid reasoning. Tonight I tried making the argument for a text/gemini+stream mime-type instead. Lukee challenged that, and ultimately I have to admit it leaves out one important aspect of serving streaming content: the user should be aware that the resource intends to stream.

Whether we serve a mime-type, response code, or somehow talk solderpunk into content-length information, none of these will be available as information to the user before they select a link. The only way to make it clear to a user that a stream is intended for a link, then, is a protocol indicator.

gemini+stream://

That's my recommendation for several reasons:

1. We're not changing much in the default gemini protocol. What we are indicating is that the client should not wait for a connection close to begin processing/displaying content. We are also signaling to the user that this resource intends to stream. Everything else about the connection remains otherwise default gemini behavior. Giving it a new protocol name would suggest there's more differences here and possibly open a doorway for other scope creep.

2. By keeping gemini in the protocol name still this tightly couples it with Gemini. This isn't something that is designed to go off and live on its own or be in any way confused as its own system. There was discussion about Titan when this idea came up. I personally still prefer gemini+write:// for that extension for the same reasons as above, but as Alex is doing literally all the work on it himself, I defer to him.

3. It's not gemini:// and therefore it is inherently not a part of the gemini core requirements for clients. I think streaming is fascinating, but I don't want to suggest that it be a requirement to support it like we have for the text/gemini mime-type. It represents a different way of consuming data and presenting it that would turn a weekend project into a two weekend project. Having a supplemental protocol fits better.

4. (sort of related to #3) Having "something" as a standard avoids the vagueness we have right now where people will try whatever makes sense to them in the moment. They'll get it working on their personal client and that's the extent of it. With something defined we all have a common target.

5. It doesn't inherently limit itself to the text/gemini mime-type since the streaming behavior is indicated by the protocol itself. It could also stream plain text, for instance, or even an mp3. The individual mime would have to make sense in a streaming context, but the door is technically open.

6. It is still a single client-initiated request happening in the foreground. We aren't creating background threads of who-know-what running services. We're getting an ongoing document in real-time, that's all.

I believe this answers all the concerns we've had voiced before about streaming. It allows for an optional extension of gemini that explicitly allows for a persistent streaming connection without breaking anything natural or inherent in the core protocol. But please chime in and correct me if I've missed something important.

This turned into quite the post! Yeesh