mirror of
https://codeberg.org/postscriptum/gemlog.git
synced 2026-02-19 06:22:41 +00:00
126 lines
No EOL
4.5 KiB
Text
126 lines
No EOL
4.5 KiB
Text
# 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:
|
|
=> gemini://bbs.geminispace.org/s/Gemini/24978 Regarding Titan redirection rules
|
|
|
|
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.
|
|
|
|
Relevant:
|
|
|
|
=> gemini://gemini.ctrl-c.club/~stack/gemlog/2022-02-13.notls.gmi A Call for a Gemini Without TLS
|
|
=> gemini://station.martinrue.com/audacityplatypus/c965bae452864452add5d53ba6c18a56 TOFU makes Gemini inappropriate for sharing software in-band
|
|
=> gemini://bbs.geminispace.org/s/Gemini/24266 Thoughts on geminict://
|
|
|
|
### 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:
|
|
|
|
``` gemtext
|
|
* 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:
|
|
|
|
=> gemini://bbs.geminispace.org/s/Gemini/26089 A few proposals to extend Gemini
|
|
=> gemini://en.arns.lt/f/gemini/29/gemini_status_confirmation_code.gmi Gemini status code for confirmation |