[HN Gopher] The Gemini protocol seen by this HTTP client person
___________________________________________________________________
The Gemini protocol seen by this HTTP client person
Author : maaarghk
Score : 178 points
Date : 2023-05-28 14:56 UTC (8 hours ago)
(HTM) web link (daniel.haxx.se)
(TXT) w3m dump (daniel.haxx.se)
| majkinetor wrote:
| Markdown is way better IMO, also very simple yet allowing for
| better visuals and more expressivness, and new protocol should be
| designed to use it as its text format.
| derekzhouzhen wrote:
| No, Markdown is a format for authoring HTML. It makes a very
| bad interchange format because the it leaves too much ambiguity
| in parsing. Also, parsing speed of Markdown is much slower than
| the parsing speed of a strictly conforming XML file.
| gerikson wrote:
| I have a blog focussed on small entries (tweet length)
| consisting of Markdown in a fortune file format, that renders
| +10k items in about 5 seconds. Using Perl.
|
| Parsing Markdown is fast enough.
| majkinetor wrote:
| That is all easily solvable.
|
| Parsing speed, really? In this age?
|
| It has its problems but its easy, widely adopted, with
| hundreds of tools, and simply way more capable than gemtext
| (which is simply very bad).
| carapace wrote:
| Markdown is, uh, not so good, it just won a popularity cintest.
| E.g. _Creole_ is much better.
| https://en.wikipedia.org/wiki/Creole_(markup)
| gerikson wrote:
| This is the first time I've heard of Creole (I've been
| authoring in Markdown since 2004).
| majkinetor wrote:
| We will never have good things. Just good enough. As it has
| enormous traction, and you can explain it to anybody in 5
| minutes, it is good enough.
| ilyt wrote:
| Doesn't look like better in anything ?
|
| No markup syntax is straight up worse
| sshine wrote:
| Why is Creole better?
|
| To me they look much the same.
|
| Except I prefer Markdown for the looks and how widespread it
| is.
|
| I was a Wikipedia contributor for many years before Markdown
| came along, and I think Markdown has a better flavor for
| hyperlinks. "[link text](url)", "[link text][footnote] +
| [footnote]: url" are just great. I write like this even
| without any expectation of rendering it as anything but
| plaintext.
| carapace wrote:
| Years ago I read a well-reasoned comparison of a handful of
| markup languages and the author made a strong case for
| Creole (which I had never heard of before or since. I use
| markdown just like everybody else. ;)
|
| Unfortunately, I can't remember the arguments and I've
| never been able to find that article again.
|
| So I can't tell you _why_ it 's better. But try it and see
| what you think?
| akkartik wrote:
| Oh I like it. It looks unambiguous, and it feels just as
| mnemonic as Markdown. I can't believe I haven't seen it
| before..
| graypegg wrote:
| Gemtext is weird, it's hyper-focused on a very specific form of
| text publishing. It's not trying to be "old internet" featuring
| the creative freedom of its users, it's just text content and
| that's it. Not even inline links or images! Which I personally
| think makes it a bad format for the old-internet mainstay of
| "website about one specific interest of mine".
|
| I run a little capsule but I find myself with not much to do
| because I'm really not interested in writing long blog posts. I
| made a crappy HN reader over gem, it's not very usable
| predictably haha
|
| I still think HTML is the ideal creative-indy-internet format.
| SoftTalker wrote:
| Gemtext seems to be more like wanting to be an online
| typewriter. Back when typewriters were used to write
| documents, there was one typeface and font, and no hyperlinks
| or images. To reference other documents you could use
| footnotes or a bibliography. Margins and line spacing (except
| maybe for block-quotes) were fixed. A lot of useful
| information was communicated in this format, but it does seem
| a bit too austere today.
| graypegg wrote:
| That's a good analogy, that does seem to be the guiding
| aesthetic they're going for.
|
| It's austere but I can see why people like it if they're
| really into writing as this raw "doesn't need anything
| else" medium. I like my silly little pictures and syntax
| highlighted code samples though.
| SoftTalker wrote:
| The weird thing is you _can_ write like that in HTML if
| you _want_ to. <html> Lots of
| plain text </html>
|
| Will render just fine. I don't think any browsers really
| even require those opening and closing tags.
| rhn_mk1 wrote:
| It will not. You'll lose line breaks.
| SoftTalker wrote:
| Yes that's true, I'll amend my comment to say that
| there's nothing about HTML that prevents you from writing
| in this austere styling if that's all you want to do.
| Quickly scanning the gemtext intro, it looks like you
| have headings (three levels), links (but not inline),
| lists, blockquotes, and preformatted text. That's it. So
| with these tags you're there: <h1> <h2>
| <h3> <p> <ul> and <li> <a>
| <blockquote> <pre>
|
| Granted gemtext markup is slightly more terse, but it
| would hardly matter in practice.
| Karellen wrote:
| You'll need to do a little bit more if you want
| paragraphs in your text, because otherwise HTML will just
| smush them together.
| [deleted]
| progre wrote:
| The problem with markdown, as I understand it, is that it's not
| possible to correctly render without reading the entire
| document.
|
| I think the gemini format is attempting to make it possible to
| basically render the document line by line.
| graypegg wrote:
| Oh that's a good point! I guess things like bold markers
| reaching over multiple lines does complicate parsing somewhat
| if you had to find the paired delimitators. But considering
| that Gemtext considers the pre formatted text block that
| starts and ends with backticks to be a "mode switch" I don't
| see why you couldn't consider spec-ing a sort of state-
| machine markdown. (Maybe that's already the current
| understanding of it!)
|
| If you leave off the ending * then everything till the last
| line will be bold, for example.
|
| That's gemtext though. Mandatory TLS on the gem protocol
| makes most of this moot IMO. It's 10x harder to view a
| gemtext document in a gemini browser. What simplicity did we
| gain with markdown--?
| giantrobot wrote:
| If only HTTP could serve text/plain documents. If only!
| stepupmakeup wrote:
| does anybody actually use Gemini exclusively, or is it just like
| Gopher where everybody ends up hosting a HTTP proxy anyway?
| tolciho wrote:
| No, but browsing the web with w3m isn't much different than
| browsing gemini with amfora. And with xterm*colorMode:false
| set, of course. The web can be a lot worse than gemini, but
| that's the modern web for you.
|
| (Yes, I know your http log says that this browser is "User-
| Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 8.0;
| WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR
| 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C;
| .NET4.0E; MS-RTC LM 8)"; it is not. It is rather amusing to see
| what sites break because of this.)
| satchlj wrote:
| People writing negative things about Gemini who haven't actually
| used it should start by reading the Gemini FAQ:
| https://gemini.circumlunar.space/docs/faq.gmi
|
| It's not meant to replace http. Use Gemini for the things it's
| meant for and http for the things it does best.
| spenczar5 wrote:
| The high-level criticism, which is that Gemini's specification is
| too loose and vague, seems very, very convincing, even if the
| specifics aren't.
|
| In a subtle way, this is a significant hurdle for any competitors
| to the HTTP world. They have to overcome 30 years of technical
| debate and refinement as ambiguities have been hammered down.
| Apreche wrote:
| I agree. I think a lot of the problem can be solved with
| discipline rather than a new spec entirely. If HTTP offers
| features that are offensive or unwanted, simply don't use those
| features. Make an HTTP server and client that only implement a
| subset of HTTP. Then use a subset of HTML, or another content
| type entirely.
|
| This means anyone still using a popular browser like Chrome can
| visit your sites, but people using a more limited client can as
| well. It also means you still get to lean on the 30 years of
| technical refinement rather than reinventing many wheels.
| josefx wrote:
| > If HTTP offers features that are offensive or unwanted,
| simply don't use those features. Make an HTTP server and
| client that only implement a subset of HTTP.
|
| Just make sure it never ends up in a security critical
| context. Various larger companies already got screwed over
| when their front end code did not detect the size of a http
| message the exact same way their backed code did.
| ertian wrote:
| > This means anyone still using a popular browser like Chrome
| can visit your sites
|
| I think this would be seen as more of a drawback than a
| feature. If you're trying to build a tight-knit little
| hobbyist community, random people popping in and complaining
| that "these pages are boring, where are all the images?!"
| isn't helpful.
| giantrobot wrote:
| Gemini doesn't support POST so no one can possibly pop in
| to say anything.
| halicarnassus wrote:
| Given that there are microblogging
| (gemini://station.martinrue.com/), reddit with optional
| git connection to allow for issue tracking
| (gemini://geminispace.org/), it seems you're wrong.
| ertian wrote:
| Well...exactly. Working as designed.
| solarkraft wrote:
| Some people hate what has become of the current thing so much
| that they want to throw all of it away. This is that.
|
| The goal would be entirely achievable using your suggestion,
| but then you can't make something "simple" and "elegant".
|
| Of course don't take my cynicism to mean that people
| shouldn't invent new things - they totally should, that's how
| we move forward. Mess around all you like. I just don't see
| it catching on. But I think that's not really the goal
| anyway.
| krapp wrote:
| Gemini makes sense when you realize it's the protocol
| equivalent of running off to join an anarcho-primitivist
| commune or ascetic monastery, a technical solution to an
| emotional problem (disgust with the web and modern
| capitalist society.)
|
| It being too basic and rigid to the point of hostility
| towards anything but pure text is the entire point.
| teruakohatu wrote:
| > anarcho-primitivist commune or ascetic monastery
|
| Even monks liked some illustrations (illumination) in
| their manuscripts. Gemini is closer to babylonian clay
| tablets delivered over TCP.
| carapace wrote:
| Gemini isn't a _competitor_ to HTML, it 's an _alternative_.
| ilyt wrote:
| Alternative would need to fill similar function, while it
| can't even embed an image or put a table.
| carapace wrote:
| Hacker News can't even embed an image or put a table, yet
| here you are?
|
| Anyway... _________________
| / /| / / |
| / Table / | / / |
| /________________/ /|| | __________ | / ||
| | | | || | | | || | | | || | | | ||
| | | |_|/ | | |_|/ | | | | | |
| |__|/ |__|/
| stonogo wrote:
| That's not what alternative means. A passenger train is an
| alternative to a bus, but you can't drive a train on a
| freeway. "Alternative" in no way implies "feature parity".
| Getting addicted to meth and dying in a shootout with the
| police is an alternative to completing a medical degree and
| retiring to the Poconos, but they do not fill similar
| functions.
| ilyt wrote:
| I mean if you want to use that as an example it would be
| like taking a bus or walking 50km to the next town...
| saghm wrote:
| To be fair, I think it's pretty reasonable to say that
| walking 50 km isn't competition to taking a bus, but just
| an alternative. To be competition, it would have to be a
| _good_ alternative...
| Andrex wrote:
| What if... Markdown was its own MIME type and browsers rendered
| it with a default stylesheet? :thinking_emoji:
| lmm wrote:
| What if browsers had a default stylesheet that doesn't suck?
| The fact that twitter bootstrap had to exist at all should
| embarrass browser vendors. If people could write their html
| like motherfuckingwebsite and trust the browser to make it look
| decent, the web would be a much better place.
| snerbles wrote:
| As long as any actual formal standard contains the term
| "markdown", John Gruber will find a way to torpedo it.
|
| https://news.ycombinator.com/item?id=8274870
|
| https://blog.codinghorror.com/responsible-open-source-code-p...
|
| https://blog.codinghorror.com/standard-markdown-is-now-commo...
|
| https://daringfireball.net/projects/markdown/license
| Kwpolska wrote:
| Fine, `text/commonmark`, with a `.md` extension since Gruber
| doesn't use that?
| rvense wrote:
| The standard answer to this is that there's too many variants.
|
| I think it should be a thing anyway. If Blink, Webkit and
| Firefox have compatible implementations there can be some sort
| of de facto standard and it will be fine for a number of
| actually useful things, even if it's not perfectly defined to
| pocket protector standards.
| ilyt wrote:
| This protocol looks like someone didn't exactly know how HTTP
| worked, and more importantly, from where the bloat came from,
| then tried to do something too simple.
|
| Then went on not understanding why people value Markdown, and do
| something entirely worse, without any good reason.
| tenebrisalietum wrote:
| It's really not too simple unless you're trying to abuse a text
| document access/display system into an application platform.
|
| Gemini is Gopher with TLS and without the Gopher document
| types.
| ertian wrote:
| I think you just misunderstand the point. A lot of criticism of
| Gemini seems to make the assumption that it's intended to
| replace HTTP and that it's badly thought through for that use.
| In fact, I think it basically came from a niche group of Gopher
| hobbyist users who wanted to fix a few longstanding annoyances
| with Gopher. They wanted something that anybody could write a
| client or server for as a fun little weekend project, not
| something that requires end-to-end 3rd-party-verified proxiable
| SSL security.
| ilyt wrote:
| Right but if you want simple why not "just" use markdown
| (with maybe HTML support cut off?). Why make something
| subtly-similar-but-incompatble ?
|
| If you want protocol to be light and low on bandwidth, why
| would you not include at least the simplest of caching
| semantics ?
|
| It is just bad design decision after bad design decision
| halicarnassus wrote:
| Markdown is not context-free and therefore hard to parse.
|
| Caching can be abused for tracking.
|
| That's why both are solutions to the problems the Gemini
| project is trying to solve.
| ertian wrote:
| Why _not_? Why is it necessary to use existing approaches,
| even if they add a lot of incidental complexity? What does
| it hurt _you_ that Gemini has their own custom markup
| language that 's different than Markdown? You can set up
| your own little Markdown HTTP server, they're not stopping
| you.
| giantrobot wrote:
| > In fact, I think it basically came from a niche group of
| Gopher hobbyist users who wanted to fix a few longstanding
| annoyances with Gopher.
|
| To me Gemini looks like it was made by people that fetishized
| the _idea_ of Gopher after reading about without ever have
| actually used it.
|
| Gopher was not about _reading_ documents, it was a way to map
| to resources. Those resources might be files or other
| servers. It was an improvement over FTP since gophermaps
| (menus) could be customized and link to servers rather than
| just files.
|
| You could abuse information messages in a gophermap to make a
| readable document but it wasn't part of the RFC. You also had
| to make some terminal width assumptions because there wasn't
| a good way to control text reflow.
|
| Gopher was interesting up until you used the web.
| satchlj wrote:
| Whatever it "looks like" to you, the fact is that Gemini
| was made by people who had been using Gopher extensively.
| MatthiasPortzel wrote:
| > Gemini documents certainly are never visually very attractive
|
| As a proponent of the Gemini protocol, I take issue with this
| line. The Gemtext format is a minimal markup format for text
| documents. It's a way of semantically indicating "this part is
| plaintext", "this part is a link", "this part is a header".
| Unlike HTML/CSS, it does not provide a mechanism for the author
| to style their documents. Instead, it is up to the client to
| render the text document, however the client chooses. If most
| clients render text in an unattractive way, that's not a fault of
| the format. And I mean, I don't think plaintext is ugly.
|
| Re: URL discussion
|
| The author interprets "URL needs be UTF-8 encoded" as meaning
| that any escape codes in the URL need to use UTF-8. I interpreted
| that as meaning that the URL string as a whole should be UTF-8
| encoded. In the author's example where there's a "%C5 in the
| URL", I'd just encode "%", "C", and "5" according to UTF-8. Maybe
| it goes without saying that the URL-line doesn't use UTF-16; but
| I think Solderpunk included it to be clear.
| Apreche wrote:
| URL discussion: This is exactly one of the author's points. The
| wording in the spec is too ambiguous. Different people reading
| it are interpreting it differently. No human language is really
| 100% unambiguous, but better technical writing here could
| increase clarity dramatically.
| Groxx wrote:
| UTF-8: how does that view mesh with
|
| > _This scheme is syntactically compatible with the generic URI
| syntax defined in RFC 3986_
|
| ^ that defines the percent encoding scheme.
|
| About the only way I can think of is if Gemini URLs are a
| superset, and don't _need to_ use percent encoding... but that
| means ambiguity when someone hands you a percent-encoded URL.
| Did they mean %C5 or _%C5_?
| layer8 wrote:
| Maybe they really mean IRIs (RFC 3987).
| ilyt wrote:
| > As a proponent of the Gemini protocol, I take issue with this
| line. The Gemtext format is a minimal markup format for text
| documents. It's a way of semantically indicating "this part is
| plaintext", "this part is a link", "this part is a header".
| Unlike HTML/CSS, it does not provide a mechanism for the author
| to style their documents. Instead, it is up to the client to
| render the text document, however the client chooses. If most
| clients render text in an unattractive way, that's not a fault
| of the format. And I mean, I don't think plaintext is ugly.
|
| Okay? But why it isn't markdown? What does it add that markdown
| does not have ?
|
| It is just taking few things from markdown but changing enough
| that markdown interpreter won't work. _What 's the point of
| that?_. Different for sake of being different ?
|
| I can understand say removing any support from HTML elements in
| markdown if you want to make something entirely new, but the
| changes are just entirely pointless and not make it more
| readable.
|
| There appears to not even be a support for a basic table, while
| calling itself "rich document" format
|
| But the cherry on cake gotta be this part of paragraph:
|
| > You may have noticed that gemini supports links to other
| protocols (the above example includes a web link, beginning
| with `https`, and a gemini link, beginning with `gemini`).
|
| The author is using `the markdown code/monospace font`
| backticks from markdown, _in document describing this shitty
| format_ , where they are not implemented, out of habit of using
| them in markdown.
| zimpenfish wrote:
| > What does it add that markdown does not have ?
|
| "a satisfactory rendering can be achieved with a single pass
| of a document, processing each line independently" - from
| what I understand of Markdown parsing, it's a lot more
| complex than this because of the spec.
|
| > There appears to not even be a support for a basic table
|
| Given the number of Markdown table attempts I've seen over
| the years, I don't blame them for wanting to avoid that
| plague pit. Plus then rendering tables is another hellscape
| of torment.
| graypegg wrote:
| Gemtext has the pre formatted text fence that it specs as a
| mode-switch. Is that impossible with markdown? I think you
| could probably design every control symbol in markdown as a
| switch to "bold mode", or "link content mode" and leave it
| at that. State machine style I guess?
| zimpenfish wrote:
| > Is that impossible with markdown?
|
| No, that bit is the simple bit.
|
| > you could probably design every control symbol in
| markdown as a switch
|
| You need a layered mode though - you can have bold,
| italic, monospaced, header and link all active at the
| same time - which means you've got 32 states right there.
| But also! If you do something like `# Header _*bold-
| italic`, that italic and bold don't apply because the EOL
| stops the header state and retroactively cancels those
| bold-italic attributes. But on a non-header line,
| `_*bold-italic\nstill bold-italic*_` works fine because
| EOL doesn't cancel them. But also also! If you mismatch
| the order, it won't match both. Or, at least in Marked 2,
| if you mismatch the order on both sides of a non-
| attributed word, that word will get the wrong styling
| (`_*with mismatched_* middle *_attributes*_`).
|
| In summary, Markdown parsing is a clusterfuck.
| ilyt wrote:
| > You need a layered mode though - you can have bold,
| italic, monospaced, header and link all active at the
| same time - which means you've got 32 states right there
|
| Requiring like, a byte, for state is hardly a complex
| requirement.
|
| > But also! If you do something like `# Header _ _bold-
| italic`, that italic and bold don 't apply because the
| EOL stops the header state and retroactively cancels
| those bold-italic attributes.
|
| And an IF statement or two.
|
| > But also also! If you mismatch the order, it won't
| match both. Or, at least in Marked 2, if you mismatch the
| order on both sides of a non-attributed word, that word
| will get the wrong styling (`__with mismatched_* middle
| __attributes_ _`).
|
| Fair enough, but you can't expect to get correct output
| if you put wrong data in, you are trying to italicize it
| twice. If the interpreteation was "either * or _ turns
| italics on/off" you'd also have not what you expected.
|
| My complaint about markdown here is really that there are
| 2 ways to make italics and 2 ways to make bold text.
| "Just" having * for bold and _ for italics would on top
| of making parsing easy also make it clearer. Less typing
| too.
| zimpenfish wrote:
| > Requiring like, a byte, for state is hardly a complex
| requirement.
|
| Add in table header and table cell to get to 128 states.
| You can probably get it above 256 quite easily. But the
| storage requirement isn't the point - it's that you have
| a complicated state machine where you can't just say "in-
| bold", "out-bold" as suggested because you also need "in-
| bold-whilst-italic", "in-bold-whilst-header", "in-bold-
| whilst-header-italic", etc. with the associated
| transitions.
|
| Or you have a state machine for each attribute. But then
| `\n` can affect multiple of them at the same time and
| also require unwinding your state over a bunch of
| characters. You can say "this isn't beyond a competent
| developer", yes, but it is a long way from trivial to get
| correct.
|
| > you are trying to italicize it twice.
|
| Ah, HN mangled my example markdown. I should have
| remembered that happens.
| ilyt wrote:
| >> What does it add that markdown does not have ?
|
| >"a satisfactory rendering can be achieved with a single
| pass of a document, processing each line independently" -
| from what I understand of Markdown parsing, it's a lot more
| complex than this because of the spec.
|
| If your device don't have enough memory to parse the
| markdown document it can _just display it_. That 's not an
| useful feature of a format. Hell, if it is really a problem
| use subset of it instead of using half, then inventing own,
| worse way, to add URLs into the text.
|
| >> There appears to not even be a support for a basic table
|
| >Given the number of Markdown table attempts I've seen over
| the years, I don't blame them for wanting to avoid that
| plague pit. Plus then rendering tables is another hellscape
| of torment.
|
| If you don't we're back in ugly land of mono font manually
| setting it up, that's why I think that should be included
| in bare minimum of any markup format. But that's kinda
| beside the point as originally MD didn't had it either.
| saghm wrote:
| > It is just taking few things from markdown but changing
| enough that markdown interpreter won't work. What's the point
| of that?. Different for sake of being different ?
|
| Maybe an attempt to follow the philosophy of "avoid success
| at all costs", like the Haskell mantra?
| Karellen wrote:
| > But why it isn't markdown? What does [Gemtext] add that
| markdown does not have?
|
| I think that's the wrong question. Based on what I've read of
| Gemini, its focus is on _simplification_. The question the
| Gemini authors are interested in would be "What does Gemtext
| _remove_ from Markdown? "
|
| To which the most obvious answer, as you point out, is
| "HTML".
|
| As for "Why not use markdown with the HTML elements taken
| out?" - does the world really need _another_ markdown variant
| that 's less capable than the current lowest common
| denominator?
|
| I would argue it's actually a better idea to just call it a
| different format altogether, rather than attempting to
| fragment the markdown landscape even further. It also helps
| to forestall the question of "Why not add HTML support, like
| all other markdown renderers?" If adding HTML support is an
| anti-goal (which I believe it is) then making it so that
| adding that support requires someone to actually implement an
| HTML renderer puts up more of a barrier than leaving the door
| open for someone to just switch out the markdown engine for
| one that already does.
| [deleted]
| MatthiasPortzel wrote:
| The right comparison is comparing Gemtext to Markdown. I
| don't think Solderpunk or other Gemini users have any
| complaint with Markdown in particular.
|
| The biggest problem with Markdown is that the vast majority
| of Markdown libraries convert Markdown to HTML. These are of
| course useless to implementing a native client that isn't
| based on HTML. (In addition, the CommonMark test suite is
| concerned with defining the correct HTML to output for a
| given Markdown input.)
|
| So while Gemtext is heavily inspired by Markdown, there's no
| reason to introduce a reliance on Markdown.
| StrangeATractor wrote:
| I love the idea of Gemini, but I feel like you could do the same
| thing, but better, with git and plaintext or markdown, maybe make
| a specialized client for browsing/rendering these git pages.
| "Gemini" as a protocol and name is just there for the community
| to nucleate around.
| lagniappe wrote:
| I'm from the telnet generation. It's sad that Gemini got so
| popular while underdelivering [0] or missing the mark in some
| areas. That makes me sad because even if a project came along to
| 'do things right', I don't even have the bandwidth to adopt
| another protocol I'll hardly use, and then invest the time to
| build content and gather links.
|
| [0] - maybe underdelivering is the wrong word, but a mutual need
| was articulated and what was delivered was suboptimal
| rhabarba wrote:
| Unpopular opinion: Gemini is Gopher done wrong. There is no need
| for a TLS layer in a protocol that won't let you POST, and there
| is nothing Gemini can do that Gopher(+) could not, except that it
| features "some" formatting - and then again, why not just stick
| with HTML?
|
| There's no place for Gemini.
| teruakohatu wrote:
| Without TLS you cannot be sure the content was not modified
| after it was sent to you but before you received.
|
| It is a reasonable requirement in the 2020s.
| rhabarba wrote:
| I see my mistake. Sorry.
| jumpyjumps wrote:
| If it's self signed and TOFU you can't be sure there was no
| proxy in the middle on first use though.
| halicarnassus wrote:
| TLS assures that nobody can tamper with the payload during
| transit. And while there's no POST, you can still post limited
| amount of data, which the linked article talked about.
|
| Gemtext is a hyperlink format, Gopher is plain text. And some
| formatting takes you a long way.
|
| HTML cannot easily be read in TUIs and needs layout engines
| only billion dollar companies can maintain.
| i2cmaster wrote:
| [dead]
| satchlj wrote:
| > There is no need for a TLS layer in a protocol that won't let
| you POST
|
| You don't need POST. You have queries (and many Gemini people
| use Titan as well).
| russellendicott wrote:
| I first came across Gemini after making my own HTTP alternative
| TUI-over-the-wire protocol (uggly)[1].
|
| Gemini has the same motives as I had when I started, but I didn't
| switch to it for all the same criticisms that are mentioned in
| the article (e.g. TOFU, no visualization support, no stream/data
| support, no cookies for login support, etc).
|
| I'm really glad to see that the desire for a simpler protocol is
| still going strong though.
|
| [1] - https://github.com/rendicott/uggly
___________________________________________________________________
(page generated 2023-05-28 23:01 UTC)