Gemini features wishlist

After a few years of active usage of Geminispace and developing various apps (clients and servers),

I have finally compiled a personal wishlist regarding my views on potential improvements to the Gemini protocol.

Although I have little hope that these ideas will be officially implemented,

just wrote this note to clear my mind before embarking on something new for myself later.

Protocol

Header size limits

I don't see any rational reason for limiting the header size to 1024 bytes.

This current limitation restricts user input, particularly for Cyrillic characters.

Service providers often crop their tokens to provide users with as many free bytes for requests as possible.

However, this practice also reduces brute force resistance for guest sessions.

Allowing an unlimited or server-expected header size would unlock additional features, as described below.

Content size header option

I found that optional content size header is highly desirable:

• the content size helps allocate memory for the content buffer, rather than changing its capacity all the time
• it provides an additional option to track the loading progress on the client side
• it would also be useful to validate that the massive content was actually delivered
• for non-static content, such as streaming data, the content size value could simply be omitted

Navigation menu

Deprecated idea, as yet not sure that is really protocol-level subject, but markup feature:

Let's make new 20* code that includes navigation menu or menus!

New header option would be useful to build client-side navbars and prevent extra scroll actions.

Not sure about format yet, it could be something like that:

20 text/gemini; charset=utf-8; ref=[
    /link1.gmi Alt 1;
    /link2.gmi Alt 2
]\r\n

• about `ref` name, it would be also `top_ref`, `bottom_ref`, `left_ref`, `right_ref` etc

Merge Titan with Gemini

Titan protocol is part of Gemini ecosystem: at least client expect Gemini response from Titan request.

Different schemes may also cause the redirection issues as described here:

I think we can merge Titan with Gemini protocol, to not confuse beginners by present different URI schemes.

It's nothing new: GET/POST/etc - user never see the header lines in response (but source only)

Thoughts only, Gemini requires MIME type when Titan does not.

Optional TLS

Some traffic is already encrypted in local and/or mesh networks, such as Yggdrasil.

Adding an additional layer only creates power safe issues, without providing significant benefits.

Furthermore, some alternative or DNS-less resolvers would require additional setup.

External resources policy

Typically, clients do not automatically load additional content on page, such as images.

However, for some reason, Gemini protocol does not restrict auto-redirections!

In my opinion, if the Gemini protocol intended to be privacy-safe,

it should disallow any auto-redirection, especially to external resources.

Also, it is important to clarify what constitutes an external redirection:

• a change in scheme?
• a change in userinfo, even not in use?
• a change in hostname or port?
• or simply a change in subdomain..

If the server attempts to relocate the user, the client should prompt the user for confirmation.

Gemtext

Some thoughts about Gemtext: I really miss some classic markdown features!

Anchors

Even URI fragment could be parsed with client using H1-H3 lines to build some navigation UI,

I still can't share these references with others. For example, reference to specification that describes Redirection rules.

Listing levels

I don't see any issues with reading following lines in plain mode:

* item 1
* item 2
  * item 3
  * item 4
    * item 5

Inline code

Preformatted `inline`, why not?

Robots

Additional specification for some Gemini features, e.g. status codes 30, 31:

• scan policy
• redirection rules

See also

Yet another opinions found in Geminispace: