Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gemini protocol seen by this HTTP client person

daniel.haxx.se

Post reply on HN
Print view View original

81–90 of 113 posts

Re: The Gemini protocol seen by this HTTP client person

#81

Post by junon »

jumpyjumps wrote: post #79
teruakohatu wrote: post #65

Earlier quoted context omitted.

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.

If it's self signed and TOFU you can't be sure there was no proxy in the middle on first use though.

Self signed != inherently insecure. If you have the public key, verified it, and you want to make sure that you're getting content directly from the server, you can do just that. It's just not got a chain of trust with root certs that are built into the browser.

Re: The Gemini protocol seen by this HTTP client person

#82

Post by jumpyjumps »

junon wrote: post #81
jumpyjumps wrote: post #79

Earlier quoted context omitted.

If it's self signed and TOFU you can't be sure there was no proxy in the middle on first use though.

Self signed != inherently insecure. If you have the public key, verified it, and you want to make sure that you're getting content directly from the server, you can do just that. It's just not got a chain of trust with root certs that are built into the browser.

My point is how do you get the public key if you can't trust what has been published? You can't trust the gemini site, you'd have to use another protocol, such as HTTPS signed by a CA in order to verify the public key you are being given was actually signed by the author and not someone in the middle rewriting the authors gemini content.

Re: The Gemini protocol seen by this HTTP client person

#83

Post by vitiral »

ilyt wrote: post #33
ertian wrote: post #27

Earlier quoted context omitted.

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 p…

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

Markdown has loads of bad design decisions for writing a parser... or being the (human) parser.

I've made an attempt to do better, it may be illuminating: https://github.com/civboot/cxt

Re: The Gemini protocol seen by this HTTP client person

#85

Post by vitiral »

majkinetor wrote: post #6

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.

Markdown is pretty bad for a lot of use-cases, like embedding data into text or using data to format text.

I took my own stab at similar constraints: https://github.com/civboot/cxt

Re: The Gemini protocol seen by this HTTP client person

#86

Post by spc476 »

layer8 wrote: post #49
Groxx wrote: post #20

Earlier quoted context omitted.

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 ?

Maybe they really mean IRIs (RFC 3987).

There was some work on using RFC-3987 but it went nowhere as there was contention about how to handle international domain names---do you convert to puny code or not? Seriously, that's where it got hung up on.

Re: The Gemini protocol seen by this HTTP client person

#87

Post by spc476 »

Andrex wrote: post #35

What if... Markdown was its own MIME type and browsers rendered it with a default stylesheet? :thinking_emoji:

Markdown does have a MIME type, as defined in RFC-7763 and RFC-7764. Markdown was rejected from Gemini for being too complex. "text/gemini" can be parsed line by line, which is why it was defined the way it was.

Re: The Gemini protocol seen by this HTTP client person

#88

Post by tpoacher »

stepupmakeup wrote: post #77

does anybody actually use Gemini exclusively, or is it just like Gopher where everybody ends up hosting a HTTP proxy anyway?

Not sure what you mean exclusively. It's not meant to replace the web.

But I often browse Gemini pages, and many people have capsules that don't have web mirrors.

Re: The Gemini protocol seen by this HTTP client person

#89

Post by derekzhouzhen »

gerikson wrote: post #32
derekzhouzhen wrote: post #15

Earlier quoted context omitted.

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.

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.

Your 10k items are probably only 2MB. Spending 5s to parse a 2MB text file is very slow, even for Perl. If you are distributing your file to users, that's 5s for each one of them. If you convert it to html and distribute the html file, your user will spend 1s in parsing, tops. This is exactly why I said Markdown makes a very bad interchange format.

Re: The Gemini protocol seen by this HTTP client person

#90

Post by MrVandemar »

carapace wrote: post #76
ilyt wrote: post #38

Earlier quoted context omitted.

Alternative would need to fill similar function, while it can't even embed an image or put a table.

Hacker News can't even embed an image or put a table, yet here you are? Anyway... _________________ / /| / / | / Table / | / / | /________________/ /|| | __________ | / || | | | || | | | || | | | || | | | || | | |_|/ | | |_|/ | | | | | | |__|/ |__|/

Ceci n'est pas une table.
Post reply on HN