Hi. I have a question regarding the gemini browsers. I came across gemini recently and I was wondering about the browsers. Please correct me if I am wrong in any of my understandings. It seems one of the key components of the gemini project is that once the client makes a request to the server, the server fills the request and then the connection closes. Also - gemini does not have inline image displays. My question is - would it be against gemini protocol to build a browser that would be able to open audio files or http audio streams as well as image files in the same window? Or - has this already been done? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210209/f07d f11a/attachment.htm>
Lagrange supports playing audio. Jose Cruz kirjoitti 9.2.2021 klo 20.18: > Hi. I have a question regarding the gemini browsers. I came across > gemini recently and I was wondering about the browsers. > > Please correct me if I am wrong in any of my understandings. > > It seems one of the key components of the gemini project is that once > the client makes a request to the server, the server fills the request > and then the connection closes. > > Also - gemini does not have inline image displays. > > My question is - would it be against gemini protocol to build a browser > that would be able to open audio files or http audio streams as well as > image files in the same window? Or - has this already been done? > > Thank you! -- Best regards, Nikolay
On Tue, 9 Feb 2021 at 17:18, Jose Cruz <jlcruz2318 at gmail.com> wrote: > > Also - gemini does not have inline image displays. > > My question is - would it be against gemini protocol to build a browser that would be able to open audio files or http audio streams as well as image files in the same window? Or - has this already been done? Why? It's up to the browser to decide that behaviour. Lagrange (from a graphical browser) displays things in-line, but can be told not to. As for console browsers, doing that becomes harder, and not worthwhile. -- Thomas
Jose Cruz <jlcruz2318 at gmail.com> writes: > Hi. I have a question regarding the gemini browsers. I came across gemini > recently and I was wondering about the browsers. > > Please correct me if I am wrong in any of my understandings. > > It seems one of the key components of the gemini project is that once the > client makes a request to the server, the server fills the request and then > the connection closes. > > Also - gemini does not have inline image displays. > > My question is - would it be against gemini protocol to build a browser > that would be able to open audio files or http audio streams as well as > image files in the same window? Or - has this already been done? > > Thank you! In theory, a client can do whatever it wants. There are some guidelines that defines "best practices" that client authors should follow (like don't make requests behind the user back etc). There is at least one browser that I know, Lagrange[0], that is able to display images inline (upon user request), but there can be others too. Cheers, [0]: https://gmi.skyjake.fi/lagrange/
Got it. Thanks everyone! Just wanted to make sure I wasn't On Tue, Feb 9, 2021, 12:27 PM Omar Polo <op at omarpolo.com> wrote: > > Jose Cruz <jlcruz2318 at gmail.com> writes: > > > Hi. I have a question regarding the gemini browsers. I came across gemini > > recently and I was wondering about the browsers. > > > > Please correct me if I am wrong in any of my understandings. > > > > It seems one of the key components of the gemini project is that once the > > client makes a request to the server, the server fills the request and > then > > the connection closes. > > > > Also - gemini does not have inline image displays. > > > > My question is - would it be against gemini protocol to build a browser > > that would be able to open audio files or http audio streams as well as > > image files in the same window? Or - has this already been done? > > > > Thank you! > > In theory, a client can do whatever it wants. There are some guidelines > that defines "best practices" that client authors should follow (like > don't make requests behind the user back etc). > > There is at least one browser that I know, Lagrange[0], that is able to > display images inline (upon user request), but there can be others too. > > Cheers, > > [0]: https://gmi.skyjake.fi/lagrange/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210209/c04e d8f6/attachment.htm>
My personal take is that user privacy and control are cornerstone principles of the Gemini project, and to me that implies that user agents should maximize user choice. Auto-loading images could lead to user tracking, and users should be in charge of when and how they expose themselves to such. But then again, who would use a web browser that didn't show pictures? Not many. A pragmatic choice (and one I'm taking in my own browser) is to have a setting to enable inline image display. Just my two cents. Ben On Tue, Feb 9, 2021 at 10:27 AM Omar Polo <op at omarpolo.com> wrote: > > Jose Cruz <jlcruz2318 at gmail.com> writes: > > > Hi. I have a question regarding the gemini browsers. I came across gemini > > recently and I was wondering about the browsers. > > > > Please correct me if I am wrong in any of my understandings. > > > > It seems one of the key components of the gemini project is that once the > > client makes a request to the server, the server fills the request and > then > > the connection closes. > > > > Also - gemini does not have inline image displays. > > > > My question is - would it be against gemini protocol to build a browser > > that would be able to open audio files or http audio streams as well as > > image files in the same window? Or - has this already been done? > > > > Thank you! > > In theory, a client can do whatever it wants. There are some guidelines > that defines "best practices" that client authors should follow (like > don't make requests behind the user back etc). > > There is at least one browser that I know, Lagrange[0], that is able to > display images inline (upon user request), but there can be others too. > > Cheers, > > [0]: https://gmi.skyjake.fi/lagrange/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210209/0087 4fea/attachment.htm>
Ben Bader <ben at bendb.com> writes: > My personal take is that user privacy and control are cornerstone > principles of the Gemini project, and to me that implies that user agents > should maximize user choice. Auto-loading images could lead to user > tracking, and users should be in charge of when and how they expose > themselves to such. I completely agree with you, I just wanted to emphasise that it's an important cultural thing, as nothing really prevents clients to start auto-downloading images, pre-fetching pages and all that evil stuff. > But then again, who would use a web browser that didn't show pictures? Not > many. > > A pragmatic choice (and one I'm taking in my own browser) is to have a > setting to enable inline image display. > > Just my two cents. > Ben
February 9, 2021 5:44 PM, Ben Bader wrote: > But then again, who would use a web browser that didn't show pictures? Not many. > > A pragmatic choice (and one I'm taking in my own browser) is to have a setting to enable inline image display. To preserve privacy, it's best to only display inline images from the same host. Displaying inline images at all goes somewhat against the vision for Gemini (see the FAQ [1]), but as long as it's constrained to the same host, and to a reasonable file size, I don't see anything wrong with it. [1] gemini://gemini.circumlunar.space/docs/faq.gmi
On Tue, Feb 09, 2021 at 06:50:52PM +0100, Omar Polo <op at omarpolo.com> wrote a message of 21 lines which said: > I just wanted to emphasise that it's an important cultural thing, as > nothing really prevents clients to start auto-downloading images, > pre-fetching pages and all that evil stuff. Pre-fetching images THAT ARE ON THE SAME CAPSULE could be good for privacy, because it would deprive the capsule's admin of some knowledge (no way to know if the user really clicked).
February 9, 2021 8:06 PM, nervuri wrote: > Displaying inline images at all goes somewhat against the vision for Gemini (see the FAQ [1]), but as long as it's constrained to the same host, and to a reasonable file size, I don't see anything wrong with it. Come to think of it, I do. 1. Increased browser complexity and attack surface. Think of buffer overflows in graphics libraries. 2. Inline GIFs... Distracting ads aside, I remember that time when a bunch of imbeciles targeted an epilepsy website with flashing animations in order to provoke seizures. Let's not allow for any of that. At the very least, inline GIFs should not auto-play. 3. Size bombs, the solution to which can lead to browser fingerprinting. A gemtext page may link to enormous images. Downloading them without the user's consent would be wrong, at least on limited mobile data connections. So a responsible browser developer might limit the total size of inline images on each page. But if each browser has a different size limit, servers can identify the user agent by checking how much of the payload was downloaded. And if the size limit is user-configurable, those who change the setting can be fingerprinted... and we're back to the web. February 10, 2021 8:23 AM, Stephane Bortzmeyer wrote: > Pre-fetching images THAT ARE ON THE SAME CAPSULE could be good for privacy, because it would deprive the capsule's admin of some knowledge (no way to know if the user really clicked). I don't think this information is sensitive enough to warrant the complications outlined above. So my recommendation to all Gemini browsers is to *follow the spec* and not display inline images: > clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.). gemini://gemini.circumlunar.space/docs/specification.gmi The one exception I find acceptable regards web proxies, like https://proxy.vulpes.one/ . This is because they can block or resize huge images server-side, to avoid #3. They can also block GIFs or put them behind static images, to tackle #2. And #1 is already present in web browsers.
Hello, Section 5.4.2 of the Gemini spec states: > clients MUST NOT automatically make any network connections as part of > displaying links whose scheme corresponds to a network protocol So Gemini clients can display things however they want, but you can't make a compliant client that automatically loads images. > My question is - would it be against gemini protocol to build a browser that > would be able to open audio files or http audio streams as well as image files > in the same window? Or - has this already been done? In the same window? Sure! Just not automatically. The Lagrange client already does this with audio and images. If you click a link that leads to one of those file types, it will open a player or image viewer inline with the document. https://gmi.skyjake.fi/lagrange/ Hope this answers your question. makeworld
On Sun, Feb 14, 2021 at 05:10:05AM +0000, colecmac at protonmail.com wrote: > Hello, > > Section 5.4.2 of the Gemini spec states: > > > clients MUST NOT automatically make any network connections as part of > > displaying links whose scheme corresponds to a network protocol > adding the rest of that paragraph: > [...] (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.). This reads to me as though automatically displaying links _without_ a network protol (e.g. gemini://, gopher://, https://, etc.) would be okay. That sounds like it applies to relative links pointing to a resource on the same domain with the same protocol. > [...]
On Sun, Feb 14, 2021 at 12:23 AM Thomas Frohwein <tfrohwein at fastmail.com> wrote: > > > clients MUST NOT automatically make any network connections as part of > > > displaying links whose scheme corresponds to a network protocol > > > > adding the rest of that paragraph: > > > [...] (e.g. links beginning with gemini://, gopher://, https://, ftp:// > , etc.). > > This reads to me as though automatically displaying links _without_ a > network > protol (e.g. gemini://, gopher://, https://, etc.) would be okay. That > sounds > like it applies to relative links pointing to a resource on the same domain > with the same protocol. > I don't think so, though the wording is ambiguous. I take it to refer to both explicit and implicit schemes, but to allow automatic fetching of file: links, about: links, and others that don't involve the Internet. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Objective consideration of contemporary phenomena compel the conclusion that optimum or inadequate performance in the trend of competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account. --Ecclesiastes 9:11, Orwell/Brown version -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210215/5674 bbbd/attachment.htm>
> On Feb 13, 2021, at 9:23 PM, Thomas Frohwein <tfrohwein at fastmail.com> wrote: > > On Sun, Feb 14, 2021 at 05:10:05AM +0000, colecmac at protonmail.com wrote: >> Hello, >> >> Section 5.4.2 of the Gemini spec states: >> >>> clients MUST NOT automatically make any network connections as part of >>> displaying links whose scheme corresponds to a network protocol >> > > adding the rest of that paragraph: > >> [...] (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.). > > This reads to me as though automatically displaying links _without_ a network > protol (e.g. gemini://, gopher://, https://, etc.) would be okay. That sounds > like it applies to relative links pointing to a resource on the same domain > with the same protocol. > >> [...] This sounds like an implicit thumbs-up to data:image/png;base64,? URLs, for better or for worse.
---