Is gemini a read-only protocol?

I got to know the gemini protocol by reading Drew DeVault's blog. In a post from last year he argues that gemini is supposed to be a read-only protocol, that the INPUT response code is only for searching, and that the SENSITIVE INPUT code should be removed. Forms, file uploads, commenting systems, and other kind of interactive use cases simply fall out of gemini's scope according to him.

Reframing gemini

What do you think? I can't say I agree. There's a lot of things from the modern web that people that choose protocols like this want to leave behind, but I don't think the "social" aspect (social as in Web 2.0, not social networks in particular) of it is one of those. And I don't even think that gemini needs much more than what it already offers: an INPUT response code that allows clients to request plain text input which is then sent as a query string component.

dsp

I think these are just enough to do all that's needed. I think that I should be able to login and reply to midnight.pub within gemini, for instance. Even post whole new articles, why not?

Ohh in response to CRLF, that's a concern of implementation but it looks like percent encoding?

"The requested resource accepts a line of textual user input. The <META> line is a prompt which should be displayed to the user. The same resource should then be requested again with the user's input included as a query component. Queries are included in requests as per the usual generic URL definition in RFC3986, i.e. separated from the path by a ?. Reserved characters used in the user's input must be "percent-encoded" as per RFC3986, and space characters should also be percent-encoded."

https://gemini.circumlunar.space/docs/specification.html

dsp

Sensitive input is nice considering the risks of DNS, maybe you don't want every admin on your network to know your specific search queries.

Ideally, fancy viewer implementations could even allow for showing input boxes inline if they fit some standard like last item on page is input button, etc, etc, with a toggle setting in a view menu. Put a 🔒 next to it if it's sensitive, else 🔓

lufte

I agree that I should be able to use midnight.pub with all features from gemini. My concern was with CSRF (Cross-Site Request Forgery), not encoding. In the web this is a solved problem by using hidden form inputs, but we have no such thing in gemini. Although you could do it by generating dynamic URLs with a random code that gets verified by the server... I would need to think about it :D

Also, beware that SENSITIVE INPUT is only a cosmetic feature: your input still travels in the URL. The only distinction is that clients should not print on the screen the input as you type it, to prevent "shoulder surfers".

dsp

Ohhhh I see. I haven't dug in to all the details yet, in that case yeah not sure how to login other than maybe a 6 digit one time password somehow? and that gets messy. I hope to implement a client in a month or two once I finish a few things and so I'll need to learn at least the basics.

Maybe a signature for the text based on a public key setup previously over a browser? That does sound close to another protocol though so maybe it's right that it shouldn't be in gemini at all?

Now I'm even more ambivalent than I was! ahaha. I'm going to have to think about it.

cheers

tatterdemalion

Any kind of logins on Gemini should generally be handled with client certificates.

dsp

I found that out in the meantime! The Lagrange browser is very nice and exposed it to me and then I was like 'ahhhhhhHHHHhhhh' seems neat.

lufte

Ohh I'm writing a client myself, in Rust.

A toast for writing gemini clients!

tatterdemalion

IMO, the answer is somewhere in between. The input response isn't just for search; it's to enable various kinds of dynamic responses. Things like Spellbinder, or Astrobotany, or a Zork implementation are completely within Gemini's remit.

That said, Gemini requests are intentionally limited in length. They're also fundamentally similar to HTTPS GET requests, in that they don't support an arbitrary payload. They shouldn't be used for creating or editing resources, IMO, and ideally they should be idempotent, though this is not strictly required by the spec, and *some* leeway is fine, particularly behind a client certificate.

It's normally expected that new resources will be posted using another protocol, just as FTP was normally used to update gopherholes back in the pre-encrypt-everything days. SFTP is probably the most generally appropriate protocol, but like here, HTTPS is often used for its versatility. I'd like to see more flexible use made of SFTP in the future.

Comment systems are an edge case. They're *barely* implementable using input responses, but it feels questionable. I can't help but feel there's a better way that hasn't really been explored yet.

lufte

Right! I still have a lot of exploration to do to see what people has created. And now that you mention it, I do think there would be some problems implementing comments with gemini, especially when it comes to CSRF.

Hello ~lufte!

I personally agree with Drew, that gemini is a read-only protocol. This is why I have an email address listed on my capsule (not on the front page though, but it can be found). And since the mailing list died I receive only little email in response to what I publish.

I am much too old to miss the so called "social web", which in my not so humble opinion is not "social" at all. I do not participate. And I do not miss it either. If you find someones post good, then instead of pressing the non existent like button, take the time to find a contact address and write a nice email. Even if you disagree, write a nice email. Or write a post with "Re: <original title>" in the subject line. Cosmos will find it. This slight increase in impedance (not to have a like button) is absolutely sufficient to switch like/shit storms off. They do not exists, or at least I have not seen any in gemini. I have seen heated discussions on the mailing list.

The perceived lack of interactivity sparks a discussion every so often. I would like to encourage you (and whoever is reading this) to embrace the limitation and explore, what can be done within its limits. The perception, that feature X is missing, is mostly translated directly from the big web. If you like the big web, by all means, use it! If you like gemini, by all means use it! If you need to upload files to your capsule, by all means use a protocol, which is suitable for this. I publish my capsule on ew.srht.site, which is published directly from the associated git repository. So I use git:// as the protocol to upload files, and not gemini. I publish my atom feed via antenna. Antenna is a feed aggregator, which is fed by publishing authors. It does not crawl. It does not poll. It is imho one of the best aspects of gemini space. Use it, if you want your blog to be noticed.

All is still quite well. If the number of participants goes up by a factor of 1000 or so, I promise there will be effects of scaling, or rather the lack thereof: there will be filters needed (e.g. to not see entries in languages I can't understand), there will be trolls and beeblebroxians and hipsters and what not. This is all very normal. Everyone has to develop the skills to navigate the jungle. There is no simple answer. Big web tries to make you believe there are simple answers. But look closely, there are not.

All that being said: You (or anyone) does not have to agree with me.

TL;DR: I personally perceive the lack of interactivity in gemini:// as it's biggest feature. YMMV of course.

~bartender? How about another round of coffee/tea/water/juice whatever, after this ... ahem, lecture? Oh, you already prepared a tray of drinks? Yay! It's all on me, and long live ~bartender!

Cheers!

lufte

* grabs a drink *

Thanks mate! Next one is on me.

Yes, I kind of agree with you, although I do have fond memories of web forums and communities, where even if super basic, they all provided some sort of interaction mechanism in the website itself. But maybe email is the way to go... I don't really care about "like buttons" but I guess there's no real difference between that and a commenting system: if you provide a way to support one you end up supporting the other.

¡Salud!