91–100 of 194 posts
Gemini was so much fun during lockdown - I loved the distraction of a new simple protocol, and the challenge of writing a gui client for it. Can't say I'm surprised that it hasn't taken the world by storm, but it's still a cozy part of the Internet.
I completely missed out on this :'(
Read the 100 word intro and still don't know what this is. Left.
I have got only two annoyance on Gemini, lack of inline links and _font styling_, and they are by design ( https://geminiprotocol.net/docs/faq.gmi#44-questions-about-t... ) It's fine for something like HN, but I heavily rely on named links and emphasis on all my blogs and is a dealbreaker.
Agreed. * Inline links * Image support * Video/audio support? I /kind/ of like the idea of fonts not being customizable, that it makes people focus on the content rather than over-styling. A lack of server-side font customization would be good for forcing inline links to be obvious, rather than potentially obfuscated.
I have got only two annoyance on Gemini, lack of inline links and _font styling_, and they are by design ( https://geminiprotocol.net/docs/faq.gmi#44-questions-about-t... ) It's fine for something like HN, but I heavily rely on named links and emphasis on all my blogs and is a dealbreaker.
Read the 100 word intro and still don't know what this is. Left.
It's an alternative to HTTP and HTML (primarily). With the protocol sitting, in terms of complexity, somewhere around the early HTTP/1 protocol and gopher, and the geminitext format being suited for a variety of displays and more text oriented rather than for interactive or multimedia use.
I have got only two annoyance on Gemini, lack of inline links and _font styling_, and they are by design ( https://geminiprotocol.net/docs/faq.gmi#44-questions-about-t... ) It's fine for something like HN, but I heavily rely on named links and emphasis on all my blogs and is a dealbreaker.
Agreed. * Inline links * Image support * Video/audio support? I /kind/ of like the idea of fonts not being customizable, that it makes people focus on the content rather than over-styling. A lack of server-side font customization would be good for forcing inline links to be obvious, rather than potentially obfuscated.
Inline links also help with the same, people who dislike it should be able to move them out of the context (like some terminal based browsers).
I don't care about image, video etc, they can just be a link to the resource if/when needed... given alt text/CC is supported or accessibility. Same for color coding stuff and CSS, users should customize their client for that if they want to, not the server.
> Project Gemini I have a theory that the idea you'd call your project "Project X" comes from TV shows. We work with project codenames and we don't call anything Project X. We just call it X. It feels like adding the word "Project" is something a screenwriter would do to make the dialogue clearer.
I would say that it comes from the military, where projects are given codenames that try hard to be opaque random monikers, and spill no beans about the nature of the project. The Manhattan Project predates mass TV, and most of it did not happen on Manhattan.
Earlier quoted context omitted.
It's an alternative to HTTP and HTML (primarily). With the protocol sitting, in terms of complexity, somewhere around the early HTTP/1 protocol and gopher, and the geminitext format being suited for a variety of displays and more text oriented rather than for interactive or multimedia use.
And its simple implementation (client and server) comes from the simple protocol that doesn't seem to need much code to implement. The content seems to be in something similar to Markdown but fewer features. So if one wanted one could achieve the same with simple HTML over HTTP. My guess this is also a community thing.
Now rendering HTML is completely another level of difficulty.
If you ask me, I'd suggest to use Markdown instead of HTML for "simple web", but keep HTTP/1.1. Rendering Markdown is relatively simple and it's rich enough for a lot of document-based websites.
As for "web apps": use webassembly as underlying execution engine, but build something new for rendering, not coupled with any markup languages. Just provide canvas to draw and efficient API to implement draw operations. Application developers will use frameworks and frameworks prefer to draw everything themselves anyway. I think that kind of "web app engine" would be possible to implement with limited development resources, unlike modern web browser.
Earlier quoted context omitted.
There are Gemini clients that can inline images, so visitors to a site could decide to enable that if they wanted to see for instance a list of thumbnails.
Are clients permitted/expected/tolerated to run off and fetch the contents of image links for inline display, once a page containing such links is retrieved?
There are also clients that make a second request to ask for a favicon. In the spirit of the protocol the "icon" is just a UTF-8 symbol, but that behaviour is still controversial.