Four years of Gemini… And so what?
2023-06-26
TL;DR: this is a bit polemic but for the good, if you planned to have a long Gemini week party then do not continue reading… 😈
This years I won't celebrate about the fourth anniversary of Gemini, I believe that we have wasted enough time and we should settle the pending stuff once and for all.
People that are arriving recently and missed the hystorical evolution, for instance I missed the first year and a half, are having (or will have) hard time to understand how to implement the specifications and to make their own projects since specs aren't closed nor clear.
A quick round on Geminispace.org and I found a bunch post that confirmed my suspects:
This uncertainty might also explain why there is still only a small group of active implementer rather than more people involved.
A call to change the leadership again
It is very cute reading Solderpunk being so surprised about this fourth anniversary:
However, as I wrote before, since everything is still a mess there would be more involvement if the specs were finalized.
Solderpunk, no hard feeling, we all owe you one, but for the second time you have disregarded your commitments! It is time for you to step back definitely.
Ad-interim leader
We need an "ad-interim" leadership to settle down conflicts when there is no common or major agreement. Someone that has a broad knowledge on how implementing Gemini in every aspect. I have my personal preference and for such role I would summon Skyjake.
I really like his vision of Gemini, I love his commitments, I can understand that some others can have a different bias over a Skyjakecentric vision of Gemini and therefore we need another (and possibly last) round table!
Who should sit around the table?
Personally these seats belong to all the implementer that have been actively working on making Gemini a vibrant space!
Please, sit together one last time and settle down all the bit that are still missing, pending or compelling.
How will the Gemini's elite closing the specs?
As first step I suggest to establish a new mailing list or to use Bubbles directly; also, a great dude that didn't get very well the Gemini's spirit gave us some good recommendations:
- Split the spec into three separate ones: protocol, URL syntax, media type. Expand the protocol parts with more exact syntax descriptions and examples to supplement the English.
- Clarify the client certificate use to be origin based, not host name.
- Clarify the UTF-8 encoding requirement for URLs. It is confusing and possibly bringing in a lot of complexity. Simplify?
- Clarify how proxying is actually supposed to work in regards to TLS and secure connections. Maybe drop the proxy idea completely to keep the simplicity.
I removed these two points because this is — in my pebcak opinion — when Mr. Haxx did not understand the goals of the Gemini Protocol, and confused design features as design flaws...
- Drop the TOFU idea, it makes for a too weak security story that does not scale and introduces massive complexities for clients.
- Consider a way to re-use connections, even if that means introducing some kind of “chunks” HTTP-style.
What about the not-implementers a.k.a. the authors?
Unless you are within the last arrived, thus I recommend you just to watch and to stay aside, I recommend to each active author to focus on few topics and spill the beans the very last time.
My beans…
While I am generally happy with the current GemText rules I believe if we add a couple of lines more it won't affect the original spirit while will boost significantly the writing and reading experience:
- I would really love have ordered lists; I can live without them but are semantically important!
- Basic table management through client. Tables are difficult to make fluid but are annoying to write manually, so we can stick with the verbatim line, but we can ask the clients to format the text for us. So basically after the first ``` if we add (5,4) the client should interpret that there are 5 rows with 4 items separated by the empty areas:
```(5,4) Ro1Co1, Ro1Co2, Ro1Co3, Ro1Co4 Ro2Co1, Ro2Co2, Ro2Co3, Ro2Co4 Ro3Co1, Ro3Co2, Ro3Co3, Ro3Co4 Ro4Co1, Ro4Co2, Ro4Co3, Ro4Co4 Ro5Co1, Ro5Co2, Ro5Co3, Ro5Co4 ```
To render:
Ro1Co1 Ro1Co2 Ro1Co3 Ro1Co4 Ro2Co1 Ro2Co2 Ro2Co3 Ro2Co4 Ro3Co1 Ro3Co2 Ro3Co3 Ro3Co4 Ro4Co1 Ro4Co2 Ro4Co3 Ro4Co4 Ro5Co1 Ro5Co2 Ro5Co3 Ro5Co4
To recap:
``` ([Rows][Marker][Columns]) ```
The Marker can be any character for instance: ; - | / — just be smart! However everything beyond the given rows and columns won't be formatted and left as-is.
However we could add other two request as in (B)asic and (R)each — it is relevant only the first letter (case insensitive) — only B and R are authorized all the others letters must be ignored.
"Basic" will consider the first row as the header:
```(5,4) B-asic Ro1Co1, Ro1Co2, Ro1Co3, Ro1Co4 Ro2Co1, Ro2Co2, Ro2Co3, Ro2Co4 Ro3Co1, Ro3Co2, Ro3Co3, Ro3Co4 Ro4Co1, Ro4Co2, Ro4Co3, Ro4Co4 Ro5Co1, Ro5Co2, Ro5Co3, Ro5Co4 ```
to render something like:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ro1Co1 Ro1Co2 Ro1Co3 Ro1Co4 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ro2Co1 Ro2Co2 Ro2Co3 Ro2Co4 ──────────────────────────────────── Ro3Co1 Ro3Co2 Ro3Co3 Ro3Co4 ──────────────────────────────────── Ro4Co1 Ro4Co2 Ro4Co3 Ro4Co4 ──────────────────────────────────── Ro5Co1 Ro5Co2 Ro5Co3 Ro5Co4 ────────────────────────────────────
"Reach" will emphasize both first row and column:
```(5,4) R-each Ro1Co1, Ro1Co2, Ro1Co3, Ro1Co4 Ro2Co1, Ro2Co2, Ro2Co3, Ro2Co4 Ro3Co1, Ro3Co2, Ro3Co3, Ro3Co4 Ro4Co1, Ro4Co2, Ro4Co3, Ro4Co4 Ro5Co1, Ro5Co2, Ro5Co3, Ro5Co4 ```
To render (more or less):
┌───────────────────────────────────────┐ │ Ro1Co1 ┃ Ro1Co2 Ro1Co3 Ro1Co4 │ │ ━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │ │ Ro2Co1 ┃ Ro2Co2 Ro2Co3 Ro2Co4 │ │ ━━━━━━━━┫ ────────────────────────── │ │ Ro3Co1 ┃ Ro3Co2 Ro3Co3 Ro3Co4 │ │ ━━━━━━━━┫ ────────────────────────── │ │ Ro4Co1 ┃ Ro4Co2 Ro4Co3 Ro4Co4 │ │ ━━━━━━━━┫ ────────────────────────── │ │ Ro5Co1 ┃ Ro5Co2 Ro5Co3 Ro5Co4 │ └───────────────────────────────────────┘
In case to render more complex case the use of a CSV files can be an alternative, however you would need to request the resource and won't be the same thing as having the table already inline into the page.
- Rules; I don't see any restriction why we can't resume this basic typographical element; Rules are elegant, easy to implement even over a terminal, and very useful to separate arguments. Rules made with verbatim text doesn't play nicely with the viewport. I am totally fine if rules are considered optional, basic clients can decide to entirely ignore it.
Other people beans I heard about
Two eligible Geminauts for the round table — friends of mine — brought to my attentions even more important topics:
- Standardizing if after each line, for instance (*), space must be mandatory or not.
- Fragmented URL; this is another feature interesting to define, I propose to use the number's line as anchor so:
But these elite guys told me they prefer more:
Nobody is preventing to make both valid but at the discretion of the client, which may support both, only one or nothing.
Wrapping this up
Some stuff like fragment URLs or space after the line are important to settle down. Other beans are nice to have but aren't a priority, however after four years and before to finalize the specs — if we will actually take this resolution seriously — a second thought won't hurt anyone and would avoid to create a Gemini2 (at least that will delay it considerably).
For comments or suggestion write me at: