[HN Gopher] gemini:// space
___________________________________________________________________
gemini:// space
Author : pabs3
Score : 245 points
Date : 2021-02-01 07:14 UTC (15 hours ago)
(HTM) web link (spwhitton.name)
(TXT) w3m dump (spwhitton.name)
| bullen wrote:
| This is the equivalent to creating a new programming language
| instead of just using C syntax with the C++ compiler.
|
| HTTP/1.1 is our final network protocol, just accept it. Just like
| Java is the final serverside programming language. JSON is the
| final data container.
|
| Everything else is completely stupid, indefinitely.
|
| Also: Make your own crypto! Xo
|
| But if Firefox and Chrome bans HTTP/1.1 (which means they will be
| obsolete) AND gemini adds chunking (without which it is
| meaningless) AND port 1965 is opened in every firewall on the
| globe; I might actually consider switching to gemini/v0.14.4 on
| my app server!
| kristopolous wrote:
| Browsing via a remote session
| (https://gemini.circumlunar.space/clients.html) is classic.
| Telnetting to a machine that had a text web browser was a real
| thing back in the early 90s
|
| Someone is either old or has done some serious homework (maybe
| both). Good job.
|
| Note: also, since people who don't know what they're talking
| about occasionally seem to want to challenge me on early
| (pre-1996 or so) web history here's some references:
|
| Page 500 from the 1994 "The Internet Complete Reference" by
| Harley Hahn: http://9ol.es/1994-internet-book.jpg (info:
| http://9ol.es/1994-copyright.jpg)
|
| Page 272 from the 1993 "The Online Users Encyclopedia" by Bernard
| Aboba: http://9ol.es/1993-internet-book.jpg (info:
| http://9ol.es/1993-copyright.jpg)
| h_anna_h wrote:
| I don't understand why the gemini people don't just use http 1.0
| (+ host) with html (or plaintext/markdown/whatever even, without
| js/css). Seems like a case of NIH to me. Don't get me wrong, I am
| not against "reinventing the wheel" for a toy project or to learn
| but gemini seems to have become more popular than just that. If
| someone is really tired of the modern web I would suggest to them
| a distributed alternative rather than this.
| craigsmansion wrote:
| > I don't understand why the gemini people don't just use http
| 1.0
|
| Think of it as cars and bicycles: why do people use bikes if
| cars already exist?
|
| - because it's healthier
|
| - because _given a proper infrastructure_ it 's more pleasant
| (and probably safer)
|
| Of course one can ride one's bike on most car oriented
| infrastructure, but it's nice to know you're not going to be
| hit by a truck if you make a turn somewhere.
| h_anna_h wrote:
| Sorry but I don't see how this analogy fits the situation in
| any way.
| ertian wrote:
| Well, for one thing, you can easily write Gemini pages in a
| text editor, without worrying about HTML, WYSIWYG or other
| markup formats.
|
| You can write your own server or client in a couple days,
| from scratch, without using libraries or worrying about
| corner cases.
|
| You're not exposed to the larger web, accidentally or
| otherwise: no web crawlers, links from modern web sites
| (causing annoyed users who think your site is broken), or
| invasions by thousands upon thousands of 4chan trolls or
| whatever.
|
| So, to go back to the metaphor: a bicycle is not a car, and
| for _most_ use cases it's objectively worse. It doesn't go
| nearly as fast, it exposes you to the elements, it can't
| carry very much. But it's easy to tune and maintain
| yourself with just a few simple tools. It does require
| effort on your part, but the exercise can be enjoyable. You
| don't need to worry about refueling, accidents aren't so
| dangerous, you can go on winding little trails and skip the
| freeways. Traffic isn't an issue. You end up paying more
| attention to your surroundings and noticing details more on
| a bike ride than you would in a car.
|
| One option is very deliberately simple and low-tech, and
| despite that it ends up being (for some people) a more
| pleasant and beneficial experience.
| prepperdev wrote:
| This is covered by their FAQ:
| https://gemini.circumlunar.space/docs/faq.html, Section 2.5
| "Why not just use a subset of HTTP and HTML?"
| h_anna_h wrote:
| I do not buy it. Just use gemini:// rather than https:// to
| refer to that specific subset of https + html. Maybe also add
| a header to the server response that says x-gemini: true or
| whatever.
|
| > It's difficult or even impossible to deactivate support for
| all the unwanted features in mainstream browsers
|
| Just do not use mainstream browsers then. Make your own like
| you do for gemini. They address it a bit later with:
|
| > Writing a dumbed down web browser which gracefully ignores
| all the unwanted features is much harder than writing a
| Gemini client from scratch
|
| And I will disagree on this part, http 1.0 is actually easier
| to implement than the gemini protocol.
|
| > Even if you did it, you'd have a very difficult time
| discovering the minuscule fraction of websites it could
| render.
|
| Except gemini browsers render even less websites right now.
|
| It seems to me that the gemini developers can't really think
| outside the box. This is further proven by their dependence
| on things like TCP, TLS, and DNS.
| tenebrisalietum wrote:
| Every Gemini post on HN has an inevitable post like this.
| Gemini developers want to keep things inside of a box that
| can't be bulldozed by corporate interests. I love it. I
| just wish Gemini browsers would optionally inline media and
| video links, but I'd be surprised if that doesn't happen
| before too long.
| spwhitton wrote:
| One of the two main web-to-Gemini proxies can already do
| this and the gmi2email script I wrote does it too. I
| think other clients probably can too.
| marshal_mellow wrote:
| Theres a gemini browser called lagrange that has inline
| images/audio
| rakoo wrote:
| gemini isn't trying to reinvent the web, to make it P2P or
| serverless or whatever; it's just reusing the ideas of
| gopher and the web but going in another direction. It
| doesn't try to replace the web. From this point of view it
| makes total sense to reuse TCP, TLS and DNS, because
| they're not trying to replace them.
|
| > Maybe also add a header to the server response that says
| x-gemini: true or whatever.
|
| That would require adding headers, which means extension is
| possible, and that's explicitely something gemini doesn't
| want. I believe it makes sense in the goals gemini wants to
| achieve.
|
| > And I will disagree on this part, http 1.0 is actually
| easier to implement than the gemini protocol.
|
| HTTP 1.0 still has multiple headers and multiple verbs.
| It's actually closer to HTTP 0.9. Yes, you can say "don't
| use those" but at some point it's good to refresh the spec
| and see what is and what isn't needed. Moreover HTTP is
| just HTTP, Gemini is transfer + encryption + client
| identification (through client certificates); the latter is
| still the wild west for the HTTP world, there is no clear
| set of "best practices" in this domain
| h_anna_h wrote:
| > gemini isn't trying to reinvent the web
|
| > It doesn't try to replace the web
|
| This is what they claim, yes.
|
| > From this point of view it makes total sense to reuse
| TCP, TLS and DNS, because they're not trying to replace
| them
|
| I do not understand this point. Wanting to replace the
| web is irrelevant to using better and simpler protocols.
|
| > That would require adding headers
|
| Treat any server that contains extra headers as invalid
| gemini then.
|
| > which means extension is possible
|
| Extension is possible regardless, even on gemini. I can
| set my mime to text/gemini-2 and add all kinds of stuff
| in it.
|
| > Moreover HTTP is just HTTP, Gemini is transfer +
| encryption + client identification
|
| HTTP might just be HTTP, https however..
| rakoo wrote:
| > This is what they claim, yes.
|
| No it is not. See the FAQ again at
| https://gemini.circumlunar.space/docs/faq.html:
|
| > 1.4 Do you really think you can replace the web?
|
| > Not for a minute! Nor does anybody involved with Gemini
| want to destroy Gopherspace. Gemini is not intended to
| replace either Gopher or the web, but to co-exist
| peacefully alongside them as one more option which people
| can freely choose to use if it suits them. In the same
| way that many people currently serve the same content via
| gopher and the web, people will be able to "bihost" or
| "trihost" content on whichever combination of protocols
| they think offer the best match to their technical,
| philosophical and aesthetic requirements and those of
| their intended audience.
|
| For the other point you seem to forget that gemini
| doesn't exist on technical grounds but on philosophical
| grounds: it wants to create a new space with its own
| rules, even though the technicalities are close to
| something that already exist. People have written blogs
| (called gemlogs in gemini), and they "hacked" the format
| to build an informal replacement to Atom. The constraints
| of the medium created the requirements and the result is
| a simple, human-readable and human-editable document that
| can replace Atom in most cases: https://proxy.flounder.on
| line/gemini.circumlunar.space/docs/.... It follows the
| philosophy of making this new space more human-centered.
| h_anna_h wrote:
| By "This is what they claim, yes." I meant that they
| claim that they are not trying to replace the web, not
| that they claim that they try to replace it.
| GoblinSlayer wrote:
| I wrote http and xml parsers and I bet text drawing,
| layout, scrolling and ui are much more difficult.
| tannhaeuser wrote:
| > _The problem is that deciding upon a strictly limited
| subset of HTTP and HTML, slapping a label on it and calling
| it a day would do almost nothing to create a clearly
| demarcated space where people can go to consume only that
| kind of content in only that kind of way. It 's impossible to
| know in advance whether what's on the other side of a
| https:// URL will be within the subset or outside it._
|
| Not that I can't see the appeal for the gemini devs to start
| from scratch and roll their own protocol rather than start
| with a browser and subtract the unwanted parts, but that
| justification is, technically, practically, and also
| generally very weak.
|
| Technically, because you can very well limit HTML to a subset
| of markup elements (for example, to exclude <script> elements
| or, likewise, onclick and similar attributes accepting
| script). The whole point of SGML, on which HTML is based, is
| to define markup languages, and also derive restricted
| languages from general ones. The problem here is rather that
| HTML on its own isn't expressive enough for interactive
| things we've come to expect (such as idk menus, table-of-
| content summaries, and other navs or in-page search dialogs
| and other interactive features that are not quite webapps)
| yet is also too powerful with js being inserted everywhere to
| non-heuristically comprehend content for reader mode apps and
| screen readers in the general case.
|
| Practically, because syntax checkers (SGML or otherwise) and
| NoScript exist and have for a long time. It would also be
| cool if search engines could finally come around and penalize
| or at least flag content relying heavily on script and/or
| invasive tracking for ads. One way to make this happen is to
| introduce application/html as opposed to text/html media
| types.
|
| Generally, because HTML and other markup vocabularies have
| been developed using public money for, well, publishing
| hypertext in academia, and it's odd to marginalize that
| original use case just because of the desires of ad
| companies.
| jai_ wrote:
| The argument isn't being technical or practical, it's being
| mental. It's acknowledging the fact that if you given
| humans a different/unfamiliar protocol they will be
| naturally inclined to treat it's content differently, which
| is the entire point.
| wwn_se wrote:
| Yeah markdown only sites would be great!
|
| But the only way to have some success with a old-new web is
| widespread adoption.
|
| I try to host and share trough my own blogs/sites to not put
| everything on the giants. But if 99% does not we will still be
| were we are.
| II2II wrote:
| A big part of the reason is Gemini was developed by people
| interested in Gopher, acknowledged the short comings of Gopher,
| then thought of solutions in the context of Gopher.
| EamonnMR wrote:
| (A defining feature of the Gopher community is wanting to use
| something other than HTTP)
| rakoo wrote:
| It's in the FAQ (https://gemini.circumlunar.space/docs/faq.htm)
|
| > 2.5 Why not just use a subset of HTTP and HTML?
|
| TL;DR: a completely different protocol creates a different
| space; when you're on gemini you _know_ what is and isn 't
| available, there's no need to think about not being tracked or
| not fetching MBytes of images and scripts, even if you don't
| display or execute them, because the protocol says no.
| h_anna_h wrote:
| I just replied to it
| https://news.ycombinator.com/item?id=25986963
| bandie91 wrote:
| > why the gemini people don't just use http 1.0
|
| as i understand they don't want that people start browsing
| supposedly gemini-only web with browsers supporting more than
| that is in the gemini specs. So those people will still get the
| dark side of the modern web.
| zimbatm wrote:
| I respect the sentiment of starting from scratch to get rid of
| technical debt. The protocol is not very different than HTTP/0.9,
| with hindsight applied.
|
| That being said, the protocol interaction model is essentially
| the same as HTTP.
|
| There is another road where browsers get support for the
| text/gemini content-type but still talk HTTP only. It doesn't fix
| everything but it has the advantage of allowing normal users to
| participate in it.
| julius wrote:
| I like how it removes noise for the reader. Links cannot simply
| be put whereever the author pleases. Links have to be put on
| their own line. (and the browser can neatly indicate to you which
| links are same-domain, other-domain, other-protocol)
| gerikson wrote:
| I hate not being able to integrate links in running text - it's
| been a feature of the web since the start, having to awkwardly
| add "see this link:" followed by a newline everywhere would
| drive me mad.
| FrozenVoid wrote:
| Gemini appeals to the 'console-only' aesthetic, I won't bet on it
| replacing the everyday web, but it can be used to construct an
| alternative 'Internet for the terminal'-type experience:
| lightweight news, libraries, etc accessed from shell
| scripts(which is plain text vs web scripts that strip html cruft
| to get real content). The only thing i dislike is the poor choice
| of the name, which clashes with millions of sites about
| horoscopes.
| Mediterraneo10 wrote:
| I really like the idea of having a more bare-bones text-only web,
| but I can't get onboard with Gemini until it offers the same
| support for screenreaders as HTML. (For example, an equivalent of
| span lang=XX tags is missing, so if you quote a foreign-language
| word(s) in your text, you can't let screenreaders know what
| language to read it in). The visually impaired should not be
| second-class citizens in any new internet community.
| miki123211 wrote:
| As a screen reader user, automatic language switching is the
| first thing I disable. A lot of HTML templates just include
| 'lang="en"', and developers rarely notice that, even if their
| website is in another language.
|
| I find Gemini pretty accessible overall. There are no images,
| so including alt descriptions isn't even a concern. There's no
| CSS, so you can't make controls that visually look like check
| boxes, but are much less accessible. In fact, it's way harder
| to make an inaccessible Gemini site than to make an
| inaccessible website. The only gripe I have is the possibility
| to introduce ASCII diagrams, which usually aren't accessible.
| alexwennerberg wrote:
| > I find Gemini pretty accessible overall. There are no
| images, so including alt descriptions isn't even a concern.
| There's no CSS, so you can't make controls that visually look
| like check boxes, but are much less accessible. In fact, it's
| way harder to make an inaccessible Gemini site than to make
| an inaccessible website. The only gripe I have is the
| possibility to introduce ASCII diagrams, which usually aren't
| accessible.
|
| The provides an alt text tag to preformatted text blocks for
| this purpose:
|
| > Any text following the leading "```" of a preformat toggle
| line which toggles preformatted mode on MAY be interpreted by
| the client as "alt text" pertaining to the preformatted text
| lines which follow the toggle line. Use of alt text is at the
| client's discretion, and simple clients may ignore it. Alt
| text is recommended for ASCII art or similar non-textual
| content which, for example, cannot be meaningfully understood
| when rendered through a screen reader or usefully indexed by
| a search engine.
| genewitch wrote:
| > The only gripe I have is the possibility to introduce
| ASCII diagrams, which usually aren't accessible.
|
| CAD software exports .stl files which can be processed into
| instructions for machines. That is, there is already
| software that can take lines on a screen and convert it to
| instructions for a machine. There's probably a way to
| annotate ASCII images of drawings (schematics,
| architectural) and output text "text* drawing of an object
| 14 centimeters by 5 centimeters, ..." Stuff like vinyl
| cutters (and even the proprietary cricut) can take vector
| graphics and convert them to instructions for a machine. so
| it, in theory, might be possible to just paste the ascii
| drawing text into some software: render ascii as
| .svg/vector, convert to 2d stl ("a layer"), convert stl to
| descriptive text. Since the software renders, you don't
| need OCR for the annotations, which are mostly
| instructions.
|
| if there's no annotation, assume the '-', '_', '|', etc are
| to scale, and just use "units" as the dimensions instead of
| centimeters or whatever. |----| = 'two verticals separated
| with a 4 unit line'
|
| Am i crazy?
| GoblinSlayer wrote:
| The specification supports images, any mime types, video,
| pdf, html and javascript, in theory.
| miki123211 wrote:
| Sorry, I meant embedded images, like the img tag in HTML.
| senkora wrote:
| I would argue that that complexity should be handled by the
| screenreader through heuristics rather than the .gemini format
| itself, based on the desire to keep basic clients very simple
| (~100 loc). But that's a really good point!
| TheDong wrote:
| Did you know the chinese character 'Nan ' and japanese 'Nan '
| are spoken totally differently?
|
| Okay, now try to read this comment with a screen reader
| accurately. Someone who knows chinese, japanese, and english
| will be able to pronounced both of those words correctly.
| There's no heuristic that can do the same.
|
| I should be able to annotate each of those characters with
| whether it's meant to be chinese or japanase.
| CamouflagedKiwi wrote:
| Not having the ability to do this forces the screenreader to
| solve the problem, and it's a really hard problem in general
| - something like "real" that already exists in English but
| crops up in Spanish contexts fairly frequently is tough, let
| alone all the proper nouns etc.
|
| On the other hand, there will also be a bunch of cases where
| people don't do the work to mark this up (maybe not even
| realising they need to)...
| jl6 wrote:
| Gemini does support a `lang` parameter to its mime types,
| which can be used to indicate a document is in a mixture of
| languages. That could be enough of a hint for a client to
| tune its pronunciation.
|
| I do agree though that this is a far bigger problem space
| than HTML's `lang` attribute is capable of solving. It's not
| like knowing the language of the text always tells you the
| unique pronunciation of a string of characters.
| mysterydip wrote:
| Fair point, for example is it read or read? Maybe a better
| option would be a phonics tag or attribute followed by
| phonemes that no matter the language of the following
| word(s) would be able to be spoken by a reader?
| ignoranceprior wrote:
| I can't wait until I have to annotate all my documents
| like: <sentence lang="en-US-x-Pittsburgh"
| intonation="falling"><word pos="subject-pronoun"
| ipa="hi">He</word> <word pos="verb-simple-past"
| ipa="red">read</word> ... </sentence>
| carapace wrote:
| That sounds like a fun challenge: make a voice-to-text
| widget that also generates phonetic or semantic
| annotations...
| jl6 wrote:
| That would surely place too great a burden on authors to
| do it and to get it right.
|
| Reading, as a discipline, is hard at the edges, and lots
| of humans don't get it right either!
| Mediterraneo10 wrote:
| Heuristics might work for longer text where the sample is
| large enough to uniquely identify the language, but for
| single words there is not enough information. If I write
| "coin" in my text, for example, am I using an English word,
| French word, or Irish word? The pronunciation varies
| drastically, and screenreaders have to know what to say.
| wwn_se wrote:
| How would a user not using a screen reader know?
| fckthisguy wrote:
| In multilingual text, a foreign word/phrase/snippet is
| often shown between << and >>.
|
| Not always, but often enough that it's an informal
| standard.
| detaro wrote:
| The difference is that the screen reader has to pick a
| pronounciation which could be wrong, a sighted user
| reading matches on the letters. Mentally matching from a
| wrongly-spoken word is harder.
| mlyle wrote:
| Humans need to know what to read, though, too, right?
|
| Obviously humans are a bit better at contextual clues,
| but.. the information has to be there for a human user to
| make the distinction.
| contravariant wrote:
| Well if 'readable by a human' would be enough for screen
| readers then we wouldn't have to worry about
| accessibility surely?
| mlyle wrote:
| Sure. But computers spotting foreign words in context
| similarly to how humans do is a lot more likely than
| getting most foreign words appropriately semantically
| tagged.
| Mediterraneo10 wrote:
| Sure. A quoted foreign word might (but not always) appear
| in some context where any reader will know how to read
| it. However, for the time being, computers won't, and a
| screenreader won't manage without adequate semantic
| tagging.
| microtherion wrote:
| My go to anecdote on this is when I returned to Switzerland
| after several years in the US and walked by a bakery
| displaying a sign advertising a "Pain Surprise".
|
| If anybody ever opens an S&M themed bakery, the problem
| will be accentuated.
| StavrosK wrote:
| Oh that bakery has a gimmick where they throw a loaf of
| bread at your face when you enter.
| knorker wrote:
| Spoiler! :-(
|
| Now it won't be a surprise.
| StavrosK wrote:
| At least the pain remains.
| eternalban wrote:
| Not strictly S&M :) but fresh out of the oven Sangak
| bread of Iran can offer a "pain surprise" followed by
| culinary pleasure! Picking those hot pebbles off the back
| of the flatbread on the way home in the morning is a
| cherished memory of my childhood in Iran.
| nkoren wrote:
| Forwarding this to a friend of mine who owns a BDSM-
| themed coffeeshop...
| amadsen wrote:
| My vision is good and I also don't know if the word you
| quoted was supposed to be in English, French of Irish? The
| point being, a screen reader has no more or less
| information than a human reader.
|
| It might be better then to invest effort in improving
| language inference heuristics, which would help in all
| applications (pdf documents, text files) than to try to
| build in support in each underlying protocol.
| _wolfie_ wrote:
| But some unicode characters are supposed to be rendered
| differently based on the language of the text that
| contains them. So this (language tagging) is required
| even for getting the thing rendered correctly.
| [deleted]
| progval wrote:
| But the screen reader needs to say the word, and the
| pronounciation of "coin" isn't the same in every
| language. I don't know about Irish, but it's radically
| different between French and English, the only sound in
| common is the "k".
|
| This means that if the screenreader picks the wrong
| language, then the user has to guess the spelling from
| the way it's pronounced to understand the text.
|
| Though I'll concede that right now on the web it isn't
| much better; but that's a failing of publishing tools,
| not the format.
| GoblinSlayer wrote:
| Not unthinkable that's how a human will read foreign
| language too.
| Snarwin wrote:
| Seems like the simplest fix is to allow the user to ask
| the screen reader how a word is spelled.
| alpaca128 wrote:
| > a screen reader has no more or less information than a
| human reader.
|
| Indeed, so why not let the human _writer_ clarify it?
|
| Why do you prefer a resource intensive guessing algorithm
| that will never have a 100% accuracy over just having an
| annotation that takes less than 10 bytes and is trivial
| to parse?
|
| In my opinion there's no reason to even consider the
| first option, especially with gemini's focus on
| simplicity in mind. This "what can another little JS
| library hurt" attitude is what lead to gemini in the
| first place.
|
| Add language inference heuristics to cover all kinds of
| formats and now you've got a dependency. Then some people
| need different settings so you add config files and
| parsers/dependencies for those. At some point you update
| the model and now it can't properly differentiate
| Mandarin, Cantonese and short Japanese phrases anymore.
| You start adding cross-platform support and other
| features, and now some people say it's too slow on their
| Raspberry Pi Zero setup. Bloggers complain as they have
| to rearrange some quotes via trial-and-error so the
| heuristics pick up the correct language. Unfortunately
| that makes it worse for people running the older version
| 0.7.
|
| After this rant it should be obvious, but: I prefer just
| adding a ["en"] or similar and stop worrying about it.
| [deleted]
| Mediterraneo10 wrote:
| PDF actually has support for language tagging, and using
| it is a recommended part of any guide to accessibility
| for the visually impaired.
|
| It may be that the language which a quoted foreign-
| language word is meant to read in was mentioned far back
| in the text. Human sighted readers will know how to read
| it, but computers won't yet (and perhaps won't for many
| years if not decades). However, there are visually
| impaired people now who need to be guaranteed the same
| Gemini experience as sighted users.
| eznzt wrote:
| If you like the idea of having bare-bones text-only web then
| you will see how everybody and their granny have a feature that
| they won't get onboard until it is implemented. Then at that
| point we will have HTML again.
| MaxBarraclough wrote:
| I'm more optimistic, I think it might be able to find its
| niche. I agree it would be hard to outright replace the web,
| but there's room for more than one way of delivering text.
| man pages are still around, for instance.
| cabalamat wrote:
| > but I can't get onboard with Gemini until it offers the same
| support for screenreaders as HTML. (For example, an equivalent
| of span lang=XX tags is missing, so if you quote a foreign-
| language word(s) in your text, you can't let screenreaders know
| what language to read it in).
|
| The problem with this you'll get a million other people saying
| "Gemini is a really good simple format that the internet needs,
| but you need to just add feature X". But if Gemini added all
| those features, it would become as bloated as HTML/CSS/JS!
| Mediterraneo10 wrote:
| Gemini is to a large degree a reaction to the
| commercialization of the web, all that huge load of
| Javascript etc. arose through the ad economy. Accessibility
| isn't that, accessibility is something that people trying to
| do business would prefer to avoid. But letting the disabled
| be first-class citizens in an online community alongside the
| rest of the population is a matter of justice. Adding
| accessibility features isn't making a standard "bloated", it
| is simply doing the right thing.
| cabalamat wrote:
| > Adding accessibility features isn't making a standard
| "bloated", it is simply doing the right thing.
|
| Yes, and the other million people are going to say their
| proposed features are "simply doing the right thing".
|
| It may be that marking up what language a short except of
| text is in is a good feature to have (and would be fairly
| easy to achieve if Gemini used the Markdown format as you
| could simply us a <span> tag). A counterargument would be
| that traditional text doesn't do this, so a text file
| format ought not to unless it is aiming at being something
| more than what text does.
|
| But add too many features, the project becomes something
| else, is maybe less useful & doesn't gain traction. A
| Gemini project that is too bloated and thus gains no
| traction helps no-one, disabled or otherwise.
| danShumway wrote:
| > so a text file format ought not to unless it is aiming
| at being something more than what text does.
|
| Gemini does aim at being more than text[0]:
|
| > The "first class" application of Gemini is human
| consumption of predominantly written material - to
| facilitate something like gopherspace, or like
| "reasonable webspace" (e.g. something which is
| comfortably usable in Lynx or Dillo). But, just like HTTP
| can be, and is, used for much, much more than serving
| HTML, Gemini should be able to be used for as many other
| purposes as possible without compromising the simplicity
| and privacy criteria above. This means taking into
| account possible applications built around non-text files
| and non-human clients.
|
| Lots of documents and books contain passages in other
| languages, it's reasonably common -- I don't get why
| people are saying this is a niche concern. Books get
| around that problem because they have controls around
| presentation, and they're not designed to be consumed
| visually, not as a semantic, parseable format. But
| Gemini, at least in theory, is designed to be parseable.
|
| [0]: https://gemini.circumlunar.space/docs/faq.html
| mattmanser wrote:
| Really feel you're on the wrong side of this one. It's
| not the same at all in my book. Especially if, as the
| author of the blog claims, it will never be able to be
| changed.
| Jtsummers wrote:
| > A counterargument would be that traditional text
| doesn't do this, so a text file format ought not to
| unless it is aiming at being something more than what
| text does.
|
| Other text-centric media often emphasize foreign words in
| some fashion. For instance, in an English language novel
| foreign language text is often italicized. Same in many
| articles.
| bzb6 wrote:
| > a matter of justice
|
| Ooof. This kind of wording makes me flinch away.
| Symbiote wrote:
| The lang attribute is also required for embedding Simplified
| Chinese/Traditional Chinese/Japanese/Korean text in a document
| containing two or more of those.
|
| There are differences in the display (font) of the same Unicode
| character.
|
| https://en.wikipedia.org/wiki/Han_unification#Examples_of_la...
| robryk wrote:
| This is first I'm hearing about the lang attribute (edit: for
| something smaller than the whole document), so I'm curious how
| commonly is it used in the "web at large". Do you know?
| fckthisguy wrote:
| I live in a multilingual country and don't see it used as
| often as I would hope, even if it's more common here than
| elsewhere.
|
| I often see it on elements/sections of sites that link to
| content in another language.
|
| Here, German is the "main" language and lots of documents are
| available in German but not English. If you need to link to a
| German page/doc from an English one, it's not uncommon for
| the link text to be in German too.
| jayphen wrote:
| It's very common to use it on the HTML element, less common
| to use it on elements further down the tree. Like many
| accessibility features of the web, it's often neglected by
| developers.
| simias wrote:
| Multilingual accessibility seems to be a niche within a niche.
| I'm bilingual but I seldom read mixed-language content. And
| even when I do I wonder how often the author can/bothers to
| include the markup for it.
|
| If I write "ceci n'est pas du francais" here for instance it'll
| remain untagged.
|
| I think the only websites where you can reliably expect the
| text to be tagged correctly are dictionaries and the like,
| where it can be done unambiguously and at scale (wiktionary
| seems to do it for instance:
| https://en.wiktionary.org/wiki/coin ). In these case it seems
| like it could genuinely be useful.
|
| I've also looked at a few language learning apps (such as
| Duolingo) and none of them appear to use the lang attribute at
| all, even though it seems like it would be a perfect use case
| for it.
|
| I guess my point is that I'm not sure it's fair to blame a
| format that strives to be minimalist for having such a
| shortcoming for lacking such a very specific feature.
|
| Of course if you're a blind linguist you might have a very
| different opinion on the subject...
| madeofpalk wrote:
| Just to be really clear here - accessibility isnt a "niche".
| People being able to use software (which presumably is what
| gemini is about??) is important for everyone, obviously.
|
| Imagine saying accessability hardware - like corrective
| lenses - is niche.
| efsavage wrote:
| Also, accessibility numbers are almost always measured very
| low because people who need those affordances aren't even
| attempting to use it, since so much software ignores it.
| Years ago when browsers let you lock font sizes, I heard
| many times from both designers and usability "experts"
| alike, "well, it's not a big deal nobody ever changes the
| font anyways", not realizing their own self-fulfilling
| prophecies.
|
| I've always loved that the Kindle, even with such a simple
| use case as reading a book, supports so many ways to see it
| and interact with it, so even people without vision or
| motor problems can use it the way they like best.
| Chris2048 wrote:
| > People being able to use software (which presumably is
| what gemini is about??) is important for everyone,
| obviously.
|
| Yes, and a minority of those users are visually impaired,
| hence it is a niche. Maybe you considered "niche" to mean
| "preference" or "novelty"?
|
| " niche, adjective
|
| denoting products, services, or interests that appeal to a
| small, specialized section of the population. "
| jrochkind1 wrote:
| By "niche" here, we mean affecting very few people, I
| think?
|
| Then "accessiblity" in general is not niche, it effects
| everyone or almost everyone.
|
| But "accessibilty" is a broad concept, applying to all
| sorts of different unrelated needs. Vision impairment,
| cognitive differences, mobility needs, etc.
|
| Some of them effect more people than others. Some of them
| will be "niche", effecting few people. it is just a fact,
| right? It is faulty logic to say that because
| "accessibility" effects everyone, every single
| accessibility accomodation is also therefore of use to
| everyone. It's not so.
|
| How much need is there for multi-lingual screen-reading? I
| have no idea. It's obviously not universal -- I don't need
| it for instance, although I may need other kinds of
| accessibility attention -- but there may be lots of need
| for it! But we can't prove it one way or another just from
| language games around the general concept of
| "accessiblity".
|
| Whether developers ought to accomodate even niche
| accessibility needs is a separate ethical or practical
| argument.
| danShumway wrote:
| > By "niche" here, we mean affecting very few people, I
| think?
|
| A text only web is pretty niche. Can this project
| _really_ afford to start slicing off additional portions
| of its userbase? I agree that multilingual blind users
| are in the minority, but those users are probably the
| most likely of anyone to be interested in a text-only
| web.
|
| And even ignoring blind users, it's just... what's the
| point of any of this if Gemini is not going to be
| semantic? It's like religiously adhering to the GNU
| principles of always printing human-readable text on the
| command line, and then not shipping a shell with a pipe
| command or any text parsing capabilities. From just about
| any perspective, whether you're worried about
| accessibility, or parsing, or search -- it's useful to
| know what language a document/section is in.
|
| One of the few advantages of having a limited, well-
| defined, non-extensible spec is that it's easy to work
| with and write parsers around. And immediately Gemini is
| just saying, "filtering sections by language? Good text-
| to-speech support? No need for that."
|
| If nothing else, Gemini is theoretically built
| specifically for generality[0], and it's already
| guaranteeing out of the box that it can't be used well
| with voice assistants. Those things aren't a fad, a
| general-purpose document format kind of needs to support
| them. And trying to have a voice assistant that intuits
| the current language is just a really bad system for
| everyone.
|
| [0]: https://gemini.circumlunar.space/docs/faq.html
| andai wrote:
| One of Gemini's explicit goals is for client
| implementation to be so simple as to be a weekend project
| for the average developer.
|
| That's one reason inline links are not allowed (they have
| to be a separate line): it would complicate the parser.
|
| It shouldn't be too hard to add a "language switch" line,
| so that sections (but not words within sections) can be
| different languages.
|
| Making Wiktionary or Etymonline in Gemini would require
| you to add a line break for each foreign word, which
| seems annoying to read.
|
| I don't see though, why the spec can't allow links that
| are written on a newline for markup simplicity but
| _displayed_ inline? And then the same could be done for
| foreign words.
| spwhitton wrote:
| You could still do multi-lingual content just by having
| it in separate .gmi pages and then linking between then.
| And your screenreader could follow links by embedding the
| text in the other language in the first page.
|
| I agree with you that those behind Gemini should take
| this issue seriously, but maybe something like what I've
| mentioned is what they have in mind as their answer. Not
| sure.
| arbitrage wrote:
| you seem to be confusing "any" with "all".
|
| it would be nice to have more accesible interfaces for
| everyone. helping one person doesn't mean you fail to
| help everyone, in fact, helping one person in terms of
| accessibility generally has the effect of helping
| everyone.
|
| we're asking for some access. not all the access. scoped
| properly, it doesn't seem to be that insurmountable of a
| development goal, honestly.
| jrochkind1 wrote:
| > in fact, helping one person in terms of accessibility
| generally has the effect of helping everyone.
|
| How does facilitating multilingual screen-reading help
| someone who is neither multilingual nor uses a screen-
| reader? How can it possibly help everyone? (like
| literally 100% of people, you are suggesting?) What am I
| missing?
| danShumway wrote:
| - better client displays (allowing a user client to
| switch out fonts based on the language, for example)
|
| - better support for users who are not multi-lingual (a
| client could try to auto-translate sections that are not
| in the user's native language)
|
| - better search capabilities (find me all documents that
| contain a French passage)
|
| - better voice-assistant support (if a document is being
| read out loud for any reason, it would be nice to be able
| to handle multiple languages well. This also combines
| with the auto-translate capabilities above.)
|
| Basically, all of the reasons why Gemini includes a
| "lang" attribute in the first place, except recognizing
| that parsers and clients want to be able to make use of
| that on a section-by-section basis rather than purely at
| the document level.
|
| Sometimes documents are big and expand across multiple
| languages. It's just a bad abstraction in general to
| assume that each document would only have one language
| type[0]. Documents/books in the real world don't work
| that way, and a document format that can't accurately
| represent a giant portion of classic literature isn't a
| very good general-purpose format.
|
| [0]: yes, technically Gemini allows you to specify
| multiple top-level languages, but that's not useful for
| anything. If I'm parsing a document, I don't want it to
| tell me "hey, there's some French in here somewhere, good
| luck!" Tell me where it is.
| computeruser000 wrote:
| Fair in general, but for this example accessible writing is
| maybe more the issue - whoever made the content should
| avoid mixing languages if they want to be accessible.
| grosswait wrote:
| Except it currently is even if it should not be. The number
| of people that know how to make documents or websites 508
| compliant is surprisingly low
| Symbiote wrote:
| Accessibility in the web standards and specifications
| isn't a niche, even if most implementations don't bother.
| zamadatix wrote:
| How so?
| buttercraft wrote:
| > Just to be really clear here - accessibility isnt a
| "niche".
|
| This is uncharitable. They were specifically talking about
| _multilingual_ accessibility. You responded to something
| they didn 't write.
| madeofpalk wrote:
| I specifically responded to the "niche within a niche"
| comment, which I interpreted as referring to multi-
| lingual documentments as a niche within the niche of
| "accessibility" in general.
| timknauf wrote:
| I read "niche within a niche" as referring to multi-
| lingual accessibility within the 'niche' of Gemini.
| simias wrote:
| A quick internet search tells me that between 50 and 74% of
| adults (depending on the source) need some for of vision
| correction. That's very much not niche. Also it's a pretty
| bad example because very rarely do you need to worry about
| "corrective lense accessibility", except maybe for things
| like VR helmets.
|
| A better example would be things like wheelchair
| accessibility for instance, which is indeed very much not
| implemented everywhere.
|
| To be clear I'm not saying that it's a bad idea to
| implement accessibility features, It's actually quite
| commendable. I just feel like in practice it's a lot of
| additional work to get it right and even then it may not do
| much good at all. Again, while the "lang" attribute is
| technically supported by HTML, I struggle to find places
| where it's used in the wild, even in places where it
| doesn't seem like it would be technically difficult to do
| it (like dictionaries and language learning websites).
|
| If I was a gemini developer I'd definitely listen when
| people complain about bad accessibility, but I would also
| take the time to understand how people deal with things
| like multilingual content in practice and how to make it
| easier, because clearly at the moment "lang=" is not it.
| madeofpalk wrote:
| > A quick internet search tells me that between 50 and
| 74% of adults (depending on the source) need some for of
| vision correction. That's very much not niche.
|
| That's my point :)
|
| > Also it's a pretty bad example because very rarely do
| you need to worry about "corrective lense accessibility",
| except maybe for things like VR helmets.
|
| Ahh, but what corrective lesnses points to is degregation
| in eyesight. So ways to make viewing/experiencing content
| _without_ glasses is definitely a concern to between
| 50%-70% of adults.
| leesalminen wrote:
| I've been wearing glasses full time for 25 years and have
| never wished a website was designed for me to use without
| glasses. Ever.
| madeofpalk wrote:
| On the other hand, my parents have the font size turned
| up on their phones because their eyesight degraded with
| time. I imagine, within time, my eyes will fail more and
| that'll be me.
| CoolGuySteve wrote:
| I'm not necessarily a fan of your tone, seems pretty
| shrill.
|
| But at Apple we were well aware that accessibility features
| like closed captions were often used by people with no
| disabilities. We would add stuff knowing that all sorts of
| people would find uses for it.
|
| I can easily imagine a language tag would also be useful
| for filtering out a German-language gemini for instance.
|
| This was a double edged sword however. Like with closed
| captions/subtitles, we knew that many people using them
| that had hearing issues were older and also likely had out
| of date glasses prescriptions.
|
| But this didn't stop the AppleTV designers from lowering
| the contrast of the font by displaying it over a
| transparent background, lowering the font size, using
| Helvetica instead of an accessible font, and removing the
| positional text feature that indicated who was speaking.
| And in typical Apple style, there was no option to make the
| text more legible.
|
| All of these choices were made to appease people without
| disability who were using the feature for whatever reason.
| I didn't like it.
|
| So I guess what I'm saying is, accessibility features are
| good for all sorts of reasons but don't lose sight of the
| much, much smaller group of users who require the feature
| in order to use the product at all.
| Semiapies wrote:
| Not a fan of the concern-trolling ( _Accessibility is
| great, but what if you ask for it and it 's done badly?_)
| madeofpalk wrote:
| > I'm not necessarily a fan of your tone, seems pretty
| shrill.
|
| I think it is important to be honest and upfront when we
| talk about accessability in software because I've seen so
| many times when developers and product owners dismiss it
| entirely. I really want to stress the point that thinking
| about accessebility as a niche is exclusionary and
| unethical.
|
| I think about my time working at Net a Porter - UK
| upmarket online fashion retailer - where I brought up
| some accessability concerns especially around their
| terrible in-house captcha and it was dismissed as "they
| arent our target market" which is so blanetly untrue, but
| all stems from this myth that accessability is only for a
| small group of users.
|
| > don't lose sight of the much, much smaller group of
| users who require the feature in order to use the product
| at all.
|
| The people who need to use captions/subtitles are not a
| "much smaller group". I think about foreign language
| media, where i need the subtitles (like when I watched
| Dark on Netflix), or even primarily English media but has
| some forign language (I watched Lost recently - there's a
| fair bit of Korean and Arabic in that). Or even when
| you're watching TV around someone who's sleeping.
|
| Everyone needs "accessability", and if you don't now, you
| will eventually.
| michaelanckaert wrote:
| An interesting tool is the Gemini portal over at
| https://portal.mozz.us/gemini/mozz.us/
|
| This allows you to browse Gemini space through a classic Web
| browser.
| fallat wrote:
| http://len.falken.ink/web/perceived-relations-between-gopher...
| bovermyer wrote:
| I found this quote on a gemlog by Alex Wennerberg:
|
| > Gemini's obscurity and lack of utility means that there are no
| analytics, no metrics, no ways to go viral, to monetize people's
| attention, build a career or even a minimally-functional web
| platform. No sane business would build on top of Gemini, and that
| is exactly why it is capable of having the character that it
| does.
|
| I like this sentiment.
| Thorentis wrote:
| Just a meta-comment, but is this blog meant to be stream-of-
| consciousness? I found the prose very hard to read, and the
| phrasing to be quite jarring. Possibly too many commas or
| separate phrases?
| oneeyedpigeon wrote:
| Obviously take this with a pinch of salt, but it's the first
| piece of writing I've seen achieve a 'post-graduate'
| readability rating on Hemingway.
| MrYellowP wrote:
| > I now have a games console at home for the first time in some
| years, which I bought in response to the ongoing pandemic, and
| one thing that I have noticed is that using it feels like being
| offline in a way that playing games on a regular computer never
| would.
|
| I agree with you. The structure of his thoughts could use some
| improvement.
| spwhitton wrote:
| Sorry to put you through that! I normally go back and edit my
| blog posts at least a little bit, but I wasn't very happy with
| this one, so I didn't bother. I didn't expect it to have a
| readership beyond whoever happened to look at planet.debian.org
| yesterday.
| [deleted]
| trap_chateau wrote:
| While I think gemini is a cool 'hideout' on the web, it seems a
| lot of content served over gemini is also served over http. Does
| anyone know of any message boards like The Midnight Pub[1] that
| are served over gemini only? After some browsing, I couldn't find
| any.
|
| [1] https://midnight.pub/
|
| gemini://midnight.pub/
| ufmace wrote:
| That's kind of the trouble with Gemini now. Since you can't
| send significant amounts of text to the server, you can't
| really make a message board kind of thing in pure Gemini. The
| content submission has to be done via HTTP or a terminal
| interface to the server.
|
| But then, if HTTP is the simplest and most secure way to allow
| posters to make submissions, then is there really a point to
| allowing the messages to be read over Gemini? Might as well
| make a simple HTTP layout and have the whole thing run over
| HTTP.
| fgaz wrote:
| I'm hosting a very simple one at gemini://gemini-
| textboard.fgaz.me but it's mostly just a demo for my gemini
| Haskell libraries: https://sr.ht/~fgaz/haskell-gemini/
|
| Another one I know of is gemini://geddit.glv.one/
| gioscarab wrote:
| You should try to run gemini over PJON
| https://github.com/gioblu/PJON that could really change the game.
| ilaksh wrote:
| If I understand correctly they insist on no re-use of
| connections. That one makes no sense to me and guarantees any
| compliant client will be slow. So people will make "fast clients"
| that just ignore that rule.
| ufmace wrote:
| I've been messing with Gemini some off and on. A little unsure
| about what to build given the limitations. It seems to expect the
| user to use direct SSH access to servers for anything that would
| normally involve sending more than trivial amounts of data to the
| server.
|
| The most interesting part IMO is the restriction to use user-
| managed TLS client certs as the exclusive way to identify a user.
| Nice way to both securely manage user identity without clumsy
| passwords and all of the issues they bring, and easily allow the
| user to have zero, one, or many identities and switch among them
| anytime they feel like it. Eliminating cookies and other such
| things in favor of it eliminates third-party tracking and puts
| the user in charge of who knows who they are and when.
|
| I don't know if Gemini itself has a big future beyond a niche
| circle of bloggers. I would like to see the client cert feature
| be widely adopted within HTTP though. Maybe, among other things,
| Gemini can also be a lab to test out ideas that might make the
| mainstream web a better place too.
| Ambolia wrote:
| Really nice project, seems like some keys to open up the internet
| again would be:
|
| - Decoupling of data (articles, videos, ...) from platforms.
|
| - Decoupling authorship claims from platforms
|
| - Decoupling online identities from platforms.
|
| - Decoupling of user networks from platforms.
|
| - Distributed archiving, some years ago if you had an
| article/manifesto or whatever on Napster or any other P2P system
| it was trivial to find it again anytime you wanted, now dead
| blogs, videos disappearing from Youtube, or broken links to
| Twitter are the norm. You have to archive stuff yourself or hope
| somebody did it.
|
| - Related to decoupling user networks from platforms, it would be
| nice to decouple comment sections from platforms and from the
| articles themselves too. People could comment the same article in
| different curated comment sections with different moderation
| policies using their own decoupled online identity.
|
| - Create decentralized networked chains of trust (could help
| revitalize some scientific communities too).
|
| Seems like very interesting things going on with projects like
| gemini, Urbit, IPFS, still on the early stages and only usable by
| power-users, but hopefully they will keep growing.
| bandie91 wrote:
| i strongly agree with these points.
|
| let me add some more:
|
| - decouple documents from the transport layer: many web
| vulnerabilities and complexity are due to the strong connection
| between http and html
|
| - decouple documents from styling: every document should be
| legible with any stylsheet (bring back 'userstyle'), cut back
| css features which lead to nasty things like keylogging via
| css, transparenting elements for clickjacking, hide text to
| manipulate clipboard, etc.
| wwn_se wrote:
| Something like rss or similar so aggregation can happen client
| side
| spwhitton wrote:
| Commenting on posts is something that Gemini enthusiasts are
| still figuring out. Currently people post Re: posts to their
| own gemlogs and then mail a link to the person who made the
| original post, but I think they are hoping to have a less
| effortful convention.
| cabalamat wrote:
| > gemini, Urbit, IPFS
|
| There could be a distributed blogging/wiki platform where the
| articles are all written in Gemini markup (or maybe Markdown)
| and hosted over IPFS.
| alexwennerberg wrote:
| Gemini is fantastic. For anyone interested in experimenting with
| it without setting up a server, I've been working on a simple
| Gemini site builder that works over HTTP and serves the content
| via Gemini and HTTP proxy:
|
| https://flounder.online/
|
| In my view, Gemini's bare-bones text format is its killer
| feature. Non-technical users have been able to easily write
| Gemtext based on a few examples and a bit of experimentation.
| This gets users away from WSIWYG without forcing them to learn
| something as complex as HTML. And unlike Markdown, it is clearly-
| specified, universal, and doesn't compile to anything else.
|
| Many people criticize Gemini for lacking this or that feature,
| and being basically useless for "practical" applications. I wrote
| an blog post about this:
|
| https://alex.flounder.online/gemlog/2021-01-08-useless.gmi
| h_anna_h wrote:
| > No other "alt web" technology approaches the internet with
| such extreme and radical skepticism
|
| Except hypercore/dat, ipfs, freenet, tor, i2p, gnunet, ...
| alexwennerberg wrote:
| I deleted that part of my comment because it wasn't my main
| point
| krapp wrote:
| >This gets users away from WSIWYG without forcing them to learn
| something as complex as HTML.
|
| To be fair, though, tons of non-technical users were able to
| handle HTML in the old days. It's not that complicated.
| mattowen_uk wrote:
| Beyond using TLS for the connections, I struggle to understand
| what Gemini offers over Gopher. Gopher's document type is bare
| bones text also. Gopher is an open standard also. There's many
| clients and servers for many platforms, and it's easy to
| implement.
|
| I've been subscribed to the Gemini mailing list for a while
| now, and browse the conversations on it (it's _very_ active),
| and I 'm still yet to be convinced it's a viable alternative to
| the web that will gain any traction outside of it's core
| hobbyist user base.
| alexwennerberg wrote:
| I don't come to Gemini from the Gopher community, but the
| advantages are listed in section 2.2 of the FAQ:
| https://gemini.circumlunar.space/docs/faq.html
| michaelanckaert wrote:
| I've been diving head first into the Gemini space this weekend
| and discovered some really great content. It takes me back to web
| of the early 2000's where you had websites with manually curated
| content (webrings! link rolls!) instead of corporate milked
| content aggregators.
|
| Combined with my love for minimalistic websites (hello
| http://motherfuckingwebsite.com/) I find Gemini a perfect _small
| web_ to enjoy.
|
| I've even started updating my static site generator to update
| both HTML and Gemini output.
| eternalban wrote:
| > discovered some really great content.
|
| I just downloaded Lagrange and ended up here:
| gemini://cbrews.xyz/literature/the-castle-of-otranto.gmi
|
| It does remind of early web surfing(my ref is 90s).
| michaelanckaert wrote:
| Thanks for the nice link :)
| agumonkey wrote:
| Tried using gopher back, I like frugal but it's a tad too bare..
| interesting nonetheless. Ultra light for sure.
| prepperdev wrote:
| Gemini is a cool piece of simple tech. I had a genuine pleasure
| reading the spec:
| https://gemini.circumlunar.space/docs/specification.html
|
| I've entertained an idea to build a set of tools for contemporary
| development (version control, code review, CI, etc) which would
| only speak Gemini. That would be both the UI and the API.
|
| Blockers came fast:
|
| * no way to upload anything that exceeds 1024 bytes,
|
| * escaping is subtly broken and so it would be impossible to
| review code written in Python or Markdown (triple quotes)
|
| * No text editing capabilities, pretty much.
|
| Which is fine: Gemini is great because it's restricted. It's
| nearly impossible to abuse. It will find its users, even if it
| would not be me.
| Freak_NL wrote:
| From https://gemini.circumlunar.space/docs/faq.html:
|
| > Of course, it is possible to serve Markdown over Gemini. The
| inclusion of a text/markdown Media type in the response header
| will allow more advanced clients to support it.
|
| So not as the default markup language, but available.
| prepperdev wrote:
| What I meant is having markdown pieces within code regions in
| a text/gemini doc.
|
| Imagine a code review tool that tries to show a diff as
| text/gemini.
| b3kart wrote:
| That's just not the kind of use-case the protocol has been
| designed for. Think "documents", not "tools".
| [deleted]
| dancek wrote:
| True, text/gemini is not really suitable for UIs. I did write a
| wiki engine where the editing is done with sed commands and all
| responses are text/gemini. It works but people used to modern
| web apps are not going to love the UX.
|
| You _can_ serve other mimetypes over gemini (the protocol).
| That 's useful for some use cases (eg. ansi.hrtk.in serves
| modem download emulated versions of ANSI art; requires a
| streaming-capable client).
|
| But all in all, Gemini tries hard to _not_ be an application
| platform. These exercises in stretching the limits are fun and
| IIRC have also guided the development of the spec. But the
| focus of the project is on text-based content.
| makeworld wrote:
| > triple quotes
|
| Just to clarify, triple quotes work fine in gemtext. It's
| triple backticks that start and end preformatted sections.
|
| So only a line that exactly starts with triple backticks can't
| really be shown properly. Everything else can.
| Arnavion wrote:
| The one thing that puts me off the most is the limit of two
| levels of headings.
|
| (There are three, but you need one for the page title, and it
| would be awkward to reuse the "title" heading level for
| "section" headings. Even if you got over this awkwardness,
| three levels is still annoyingly constraining.)
| spwhitton wrote:
| Yes, this really bothers me too. Title, sections, subsections
| and subsubsections is not too much sectioning.
| dancek wrote:
| IMHO you could just use # Page title
| # 1. First heading
|
| and go from there. The format is meant to be human-
| understandable, not machine-readable.
|
| But your point is a good one, and made me wonder how the
| documentation of Gemini itself handles the issue. And behold,
| the Gemini FAQ [0] itself has the first level 1 heading as
| ## 1. Overview
|
| and the second one as # 2. Protocol design
|
| That's really disturbing once you notice, but I'd wager that
| hundreds of people have read the page and not noticed.
|
| [0]: https://proxy.vulpes.one/gemini/gemini.circumlunar.space
| /doc...
| annadane wrote:
| It's a sad indictment on the tech industry that so many of you
| are just dismissive of Gemini
| [deleted]
| ryannevius wrote:
| Are there any other protocols that have similar aims? I love the
| idea of a "corner" of the web that is reminiscent of the plain
| markup/pre-JS days, and occasionally use w3m to get a taste of
| it.
| Minor49er wrote:
| I'm not sure about protocols, but I've been browsing Neocities
| lately. There are thousands of sites. Many of them are a
| satisfactory throwback for my tastes:
|
| https://neocities.org/browse
| EamonnMR wrote:
| I keep getting pulled toward the small internet by various
| forces, but I never seem to find the center of it, the place
| where the good content starts. I want to find the good phlogs and
| the secret message boards. I've connected to modern day BBSs and
| could never get used to the keyboard layout. What am I missing?
| Aeolun wrote:
| I think the idea that Gemini cannot be extended is a bit silly.
| Clearly it can be, it's just not inherent in the specification
| that it will.
| spwhitton wrote:
| They've tried to make it really difficult, though -- for
| example, how there is only one type of request.
|
| Extending text/gemini is more feasible indeed.
| jl6 wrote:
| The author is 100% right about the effect of having formally
| designated spaces for things that you would think could happily
| exist as informal subspaces of a wider environment.
|
| Cold engineering logic drove us to see that everything is just
| bytes and so everything can be served over HTTP.
|
| The same logic is used in the retail world to optimize away
| culture and quirk and nuance and difference: everything is just a
| product, so everything can be sold in just one superstore.
|
| I see the small Internet movement as not just about nostalgia
| (although it's definitely a little bit about nostalgia), but
| about countering monoculture by prioritising things other than
| efficiency.
|
| Gemini doesn't need to be extensible because if you want to do
| something different, you can use a different tool and they can
| happily coexist, because the objective is not to achieve a
| winner-takes-all network effect victory.
| tenebrisalietum wrote:
| > Gemini is one technological piece in attempts to make a version
| of the Internet which is healthier for humans - the so-called
| "small Internet" movement - and maybe there will be new ideas
| about how the small Internet should be which would benefit from a
| new version of the Gemini specification. So it seems risky to
| lock-in to one version.
|
| If there are better ideas or fundamentals on which to build the
| root of another space, then what the Gemini is protocol is saying
| is that -- make your own protocol and name it something
| different.
|
| I don't think it's risky to lock-in to _the_ Gemini protocol
| because: It 's very minimal, so A) clients should be minimal as
| well, and B) Gemini documents are human readable without a
| client. So if Gemini doesn't work out, your *.gmi files will
| hardly be useless blobs of tags.
| badsectoracula wrote:
| My main annoyance for gemini not having http is that i do not
| want to run a VPS. My (web) site is running on shared hosting
| where keeping (or not) software up to date, keeping up with the
| latest and greatest way Gmail breaks email and any other admin-
| level stuff i handled by someone else (and also it is cheaper) -
| i just upload a bunch of static HTML files and anything else i
| need to share and leave it at that.
|
| If Gemini used http 1.0 (like others mentioned) it'd work out of
| the box - not just for me, but for everybody else. But the custom
| protocol pretty much requires a VPS and that opens a can of worms
| i'm not interested in opening again.
|
| FWIW i used to have my own "gopherhole" but since that one also
| needs a custom server, i dropped it after i switched from VPS to
| shared hosting. I still have the client i wrote though[0] and
| considered making a Gemini one at some point but the fact that i
| can't make my own site does hamper things a bit (and TBH i
| haven't updated the Gopher client for years either).
|
| [0] http://runtimeterror.com/tools/gopher/
| andai wrote:
| There's a great FAQ which explains the motivation behind the
| project and behind the design decisions:
|
| https://gemini.circumlunar.space/docs/faq.html
___________________________________________________________________
(page generated 2021-02-01 23:02 UTC)