Support the Gemini protocol (kinda like gopher but new)
-
@wildente I was intrigued by Gemini so I checked it out over the last week. I knew Gopher, but Gemini was news to me. Suffice to say I like the project/community very much. I tested quite a few clients and in the end settled for Amfora, which is terminal based.
But on to Vivaldi’s role in this…
I think this might actually be a good "marketing gag" in terms of return on invest.
Perhaps, and it might even benefit the Gemini community, since Vivaldi can bring new users in. But expecting existing Gemini users to switch to Vivaldi is highly unlikely in my opinion. The whole project is about independence from the mainstream web and using light tools. One of the outlined project goals is that developers should be able to write a fully functioning client over a single weekend. Vivaldi doesn’t fit in there. The client implementation would have to be the best around for anyone even considering switching. There would have to be fully functioning keyboard navigation, authentication and handling of edge cases, especially in terms of linking.
I'm not a dev, but given what Vivaldi can do already I would assume implementation of the protocol is not taking too much time.
I have to disagree. The opposite is the case. Everything Vivaldi has done so far gets in the way of implementing a clean Gemini client. In my opinion it would be really hard to detach and protect Gemini so that e.g. keyboard shortcuts and bookmark system don’t clash with each other and everything works smoothly. Some kind of Gemini mode would have to be introduced with full custom themeing, shortcuts and tab handling.
But lets say Vivaldi goes forward with it and dedicates resources and doesn’t half‐ass it. Could get interesting. For example Vivaldi could let authenticated members host their own Gemini capsules. Far more interesting than the current wordpress stuff in my opinion. Vivaldi could also offer a system of publishing capsule content both on Gemini and their own blogging system à la Flounder/smoll pub. Well, the possibilities are endless, but unless there are developers already into Gemini and willing to push this to its limits I say this either won’t happen or the results will be disappointing.
-
I gave this some more thought. I believe a desktop Gemini client in Vivaldi is a bad idea after all. But it just so happens that all Gemini clients for Android are trash. So a battle plan could look something like this:
- Embrace Gemini. Get behind it and try to support it.
- Let Vivaldi members publish capsules on Vivaldi servers.
- Create an official Vivaldi community on Gemini where a feed of these capsules is being featured and some networking and community stuff happens.
- Integrate a Gemini mode in Vivaldi browser for Android/iOS (should iOS ever be a thing) and make it the best mobile Gemini client out there (not too hard), with full functionality (e.g. capability to import certificates).
Should people start using Vivaldi for Android it’s only a little stretch to entice them to use Vivaldi Desktop for their
www
needs. -
I just think Vivaldi could help the accessibility of Gemini without taking it hostage - it could be a bit symbiotic with moderate effort. Get some publicity for both Vivaldi and Gemini, make Gemini more readily accessible. Vivaldi's built in translation might even lower some language barriers in the Gemini space, helping that community to exchange across language barriers. Not sure if the Gemini community would even welcome Vivaldi adding a Gemini client.
But I assumed that it wouldn't take much to implement, which might turn out to be more tricky than I imagined.
-
@wildente I don’t intend for Vivaldi to attack Gemini or take it hostage. I would see Vivaldi in a role supporting its users becoming accustomed to Gemini and providing options to interact with the protocol actively (capsules). What shouldn’t happen is Vivaldi running an advertisement blog on Gemini…
-
@luetage said in Support the Gemini protocol (kinda like gopher but new):
I don’t intend for Vivaldi to attack Gemini or take it hostage.
ah sorry. I was referring to my own words "marketing gag"; as you said the Gemini community seems to want to be independent from the mainstream web and wants light tools. So support from Vivaldi for the sake of a marketing gag might seem to them like being taken hostage for the benefit of some business interest.
@luetage said in Support the Gemini protocol (kinda like gopher but new):
What shouldn’t happen is Vivaldi running an advertisement blog on Gemini…
fully agreed, but then again, I have no doubt in the ethics of Vivaldi.
-
This would be great. It probably wouldn't entice any Geminispace users to switch over from their preferred browser, but it could introduce Vivaldi users to Gemini.
That said, I'd be surprised if this was added, since Vivaldi doesn't even have support for Gopher. (Though that was removed upstream; I don't know if adding a removed protocol back in would be more or less difficult than adding in a completely new one.)
If Gemini were supported, @luetage's idea of letting members publish capsules would be a killer feature, by the way. Gemini is a great project, but less technically-inclined users often have a hard time figuring out how to publish their own content. The easiest method is to send a request to join a tilde server, which still involves making yourself an SSH key. Since Gemini is mostly text-based, capsules likely wouldn't be more of a strain to host than blogs currently are. I assume, anyway.
-
@luetage said in Support the Gemini protocol (kinda like gopher but new):
In my opinion it would be really hard to detach and protect Gemini so that e.g. keyboard shortcuts and bookmark system don’t clash with each other and everything works smoothly. Some kind of Gemini mode would have to be introduced with full custom themeing, shortcuts and tab handling.
I think it would be a fair amount of work yes, despite the simplicity of the protocol (everything is more work than one would initially expect) but I am not sure why the shortcuts would be such a problem. Each Gemini client can have its own shortcuts. All our current shortcuts related to things likes bookmarking, opening tabs or focussing the address field, etc. could work the same way. Similarly for page navigation without a keyboard. Indeed, I see no reason for example why tabbing or spatial navigation would not work pretty well for link handling, unless there are hundreds of links on a page perhaps (e.g. a long directory listing).
As for theming, a typical, rendered gemtext does not look a world away from reader mode and we have an option to use the theme for those. I would imagine something similar could be done.
Personally, I would be more concerned with how the self signed certificates would be (well) handled given those would require (one might imagine) quite big changes to Chromium that would have to be patched for every Chromium update (I doubt upstream would be interested). This would mean carrying a fair overhead and additional work forever, rather than one off work to get this implemented.
Far more interesting than the current wordpress stuff in my opinion. Vivaldi could also offer a system of publishing capsule content both on Gemini and their own blogging system à la Flounder/smoll pub.
That is somewhat tricky I would imagine. Not impossible I presume but integration with what we have now and handling the very different expectations around things links (which cannot be embedded within regular text bodies) certainly carries with it complications.
Do I think we would do any of this? I suspect it is pretty unlikely if I am honest but sure, I can at least raise the idea(s) internally.
-
@ruarí Do raise
, that’s more than we could have hoped for.
I don’t think tabbing and spatial navigation are a good way to navigate any UI, less so one whose only interactive elements are links. Labels would be far more appropriate. But that’s my personal opinion about it.
-
@luetage said in Support the Gemini protocol (kinda like gopher but new):
@ruarí Do raise , that’s more than we could have hoped for.
Happy to help but do not raise them (your hopes) too high. Even the idea of Vivaldi offering capsules (or at least gemlogs) using the same backend as our blogs is fraught with issues.
- Are people who want to publish a gemlog going to also want to use our HTML based UI to generate it? Won't that be… I don't know… kind of odd?
- What format would they create content in? If they use the graphical editor then it is not going to be a case of WYSIWYG is it? Should they post in markup as HTML, Markdown, Gemtext then all but the latter is going to be tricky to handle with regards to links since you cannot embed them within a paragraph. Even if you allow Gemtext going forward the blog version is going to look identical to the gemlog version since all links will be forced into their own section (perhaps that would be considered a good thing for some?) and what about older content before gemtext was allowed?
Keep in mind that even someone like Solderpunk ("founder and de facto BDFL of the Gemini protocol") has struggled with how best to handle the linking issues when publishing to both his gopherhole and capsule, since Gemini also handles linking slightly differently then not just HTML but also Gopher.
- HTML allows linking anywhere in the document
- Gopher only allows linking from menus (type 0), while most content is plain text (type 1)
- Gemini has most of its content as Gemtext, which is pretty much plain text (lightly marked up) but the links can only be within 'link lines' (i.e. not within a paragraph with non linked text).
Here are Solderpunk's thoughts on serving Gopher and Genimi content using a single source (presumably Gemtext) and how that makes it harder to handle his gopherspace (which he still maintains),
You can certainly do it, but only by serving all Gopher content as item type 0 so it can contain links - people do this, but it's an ugly hack with non-trivial network overhead, and the fact that so many people are doing this to work around Gopher's strict directory/content dichotomy was part of my motivation for erasing that distinction in Gemini, so it would pain me to start doing it myself! […] I really am going to have to write some kind of micro CMS-ish thing to automate the whole shebang, which sucks.
-
@ruarí Yeah, I read about it before. Gopher and Gemtext don’t play well together. Would you have in mid to support Gopher too?
Converting from Gemtext to HTML is straightforward and it’s possible to convert Markdown to Gemtext. Most people know how to write markdown so that would be a good starting point for writing a blog entry. And yes, links are an issue, but I think the Gemini way makes quite some sense. You don’t litter your regular text with links and it’s easy to distinguish for the reader. Reading on Gemini is a joy, because it’s free of distraction.
-
@luetage said in Support the Gemini protocol (kinda like gopher but new):
[…] it’s possible to convert Markdown to Gemtext.
OK… but how is that handled because you still have the link issue since Markdown allows links within normal text and Gemtext does not?
Most people know how to write markdown so that would be a good starting point for writing a blog entry.
I do not think it is worth encouraging people to write Markdown if the output is going to be Gemini. You might as well start in Gemtext because
- It is (mostly) even simpler–an incredible statement I know
- You do not get surprised by lost formatting (bold, emphasis, numbered lists, etc.)
- Links are more easily handled.
And yes, links are an issue, but I think the Gemini way makes quite some sense. You don’t litter your regular text with links and it’s easy to distinguish for the reader. Reading on Gemini is a joy, because it’s free of distraction.
I am not saying links of this form are not a good idea. I get some of the appeal but it still is a difference and hence an issue that would have to be dealt with (good idea or not).
Consider, this small snipped of valid Markdown:
Check out the [Vivaldi Blog](https://vivaldi.com/blog) for more information
Normally (as rendered HTML) it would be output as:
Check out the Vivaldi Blog for more information
But that is not valid Gemini output/formatting so it will not look like that in any Gemini client. Now you could have our blog back end convert and output as the following Gemtext
Check out the Vivaldi Blog for more information => https://vivaldi.com/blog Vivaldi Blog
So that it is formatted by the Gemini client like this:
Check out the Vivaldi Blog for more information
→ Vivaldi BlogHere the the text is left in place but the hyperlinked section is copied (with a link) to the first line below the paragraph. So yeah, initially you might think that 'kinda' works.
But what if your Markdown looks like this:
More information [here](https://vivaldi.com) and [here](https://vivaldi.net).
This would then become:
Now granted I realise that doing links that way (using just the word 'here' as a link) is bad practice but people do it all the time, so you do have to handle it.
Perhaps we could try numbering with superscript:
Better yes but keep in mind that many (but not all) Gemini clients also number links for you. In those clients it will then look like this:
This is ugly but more than that, it looks very redundant and IMHO annoying in the most common use case where people do label their links correctly. Here is that first example again, rendered by a client that numbers for you:
Check out the Vivaldi Blog¹ for more information.
→ [1] Vivaldi Blog¹You could choose to only show a superscript number when multiple links have the identical text but then those two sets of numbers will get out of sync with the numbering automatically applied by some clients, e.g.
Check out the Vivaldi Blog for more information, or go here¹ and here².
→ [1] Vivaldi Blog
→ [2] here¹
→ [3] here²(And don't start thinking we could detect the client and do something different for those that automatically number. That is full of issues, starting with, "Gemini clients do not have User Agents for privacy reasons")
Maybe you could number all links in the paragraphs but only show superscript numbers in the link lines for those links that have identical text, e.g.?
Check out the Vivaldi Blog¹ for more information, or go here² and here³.
→ [1] Vivaldi Blog
→ [2] here²
→ [3] here³To me, it still looks oddly redundant (even though it isn't) but anyway at this point you can probably appreciate the problem. This is getting complex fast and this is with only a very basic sample text. If you are already looking for compromises now… wait until you have a more complicated document.
Handling links is problematic because HTML and Gemtext have such very different conventions. In addition I do not think you want to encourage people to write in Markdown if they want Gemini output. Firstly, those truly interested in Gemini almost certainly will not want to do that, and those with only a passing interest in Gemini may be very confused by the output that looks nothing like what they have come to expect from years of using Markdown.
- It is (mostly) even simpler–an incredible statement I know
-
@luetage said in Support the Gemini protocol (kinda like gopher but new):
Would you have in mi[n]d to support Gopher too?
I didn't… and now I fear you might ask for it
-
Speaking of links. Another issue is link conversion between https:// and gemini:// Consider that our user blogs are hosted on subdomains of vivaldi.net. Should all links in a blog be converted from https:// to gemini:// when they end with *.vivaldi.net?
If we do not convert them then someone browsing with a Genimi client looking at the
blogsgemlogs will constantly be pushed back to the web, even when one post links to a sibling post on the same site. However, if we do convert all the links then every page on vivaldi.net that isn't converted to Gemini (it might not even be practical to convert everything) will also result in broken links, when browsing from the Gemini side of things.Can some reasonable compromise be found. Probably but it will never be perfect and it will take time and testing to get to something "reasonable". Once again… this is not an "easy win" IMHO. I am certain it is a lot of work for the small number of people who might appreciate it.
-
Side note. Our forum breaks Gemini links?
Bug!!!
From dev tools
That was formatted in Markdown as follows:
[Source: Solderpunk Gemlog [Identity Crisis]](gemini://gemini.circumlunar.space/~solderpunk/gemlog/identity-crisis.gmi)
-
Do Gopher links work?
-
No @ruarí, they do not!
-
It seems to be something to do with with the URL sanitation included in our backend. I guess we have
a whitelistan "allow list" of permitted protocols only. -
@Ruarí You are raising some good points. If users write in Markdown, they aren’t aware how it will look in Gemtext and any workarounds could lead to ugly results. Since it would be the user’s decision to publish on Gemini additionally, writing in Gemtext directly makes sense. Then the only thing that is needed is converting the Gemtext to HTML for consumption on the web.
About Gopher, personally I have no use for it and it would complicate things even more.
@ruarí said in Support the Gemini protocol (kinda like gopher but new):
Speaking of links. Another issue is link conversion between https:// and gemini:// Consider that our user blogs are hosted on subdomains of vivaldi.net. Should all links in a blog be converted from https:// to gemini:// when they end with *.vivaldi.net?
If we do not convert them then someone browsing with a Genimi client looking at the blogs gemlogs will constantly be pushed back to the web, even when one post links to a sibling post on the same site. However, if we do convert all the links then every page on vivaldi.net that isn't converted to Gemini (it might not even be practical to convert everything) will also result in broken links, when browsing from the Gemini side of things.Well, when using a Gemini client you will have some sort of bookmark or subscription to access a blog hosted by Vivaldi. Any links in such a blog leading back to the web will be marked as outside links by the client itself and the reader will be aware they are redirected. Browsing with the Vivaldi web browser one should see no difference, because all the blogs should be accessible, since Gemtext is being converted to regular HTML in this case.
And no, I don’t think it makes sense converting existing Vivaldi blogs. It should be the choice of the content creator alone to publish on Gemini additionally and they will have to write in Gemtext for this purpose. It’s also reasonable to only publish specific content on Gemini and still content of another type only on the web.
-
I would lie if I claimed I get all you are talking about
. Are we not taking it a little too far by talking about hosting Gemini pages on Vivaldi.net and writing gemtext with Vivaldi? I think just the ability to access existing Gemini space pages and allowing to search for them with Vivaldi would already be cool to just open that realm to a wider audience. Also I believe even the most hardcore Gemini User still needs to access the regular web all the time, and might appreciate a browser that can access both. Not that it wouldn't be cool to od more in step 2...
-
@wildente said in Support the Gemini protocol (kinda like gopher but new):
Are we not taking it a little too far by talking about hosting Gemini pages on Vivaldi.net and writing gemtext with Vivaldi?
Yes, indeed it is now two requests. The original one Vivaldi supporting the Gemini protocol and an additional request to allow the publishing of Gemlogs via the blogging platform we already have in place.
Each could be considered separately. I'll pass on the original idea first but again I am not promising anything and suspect it might go nowhere.
P.S. None of you have found my Gemlog yet then it seems.