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

gemini:// space

spwhitton.name

Post reply on HN
Print view View original

161–170 of 177 posts

Re: gemini:// space

#161

Post by Semiapies »

bovermyer wrote: post #87

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.

Given that the docs say the biggest thing it needs is actual content, I'm not sure what character it really has.

Re: gemini:// space

#162

Post by Semiapies »

dancek wrote: post #100
Arnavion wrote: post #7

Earlier quoted context omitted.

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.)

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

I also noticed a few cases of trying to use markdown emphasis on the docs. If you can't even write the platform docs without having to work around your markup system, maybe don't go on about how the spec will never need updating.

Re: gemini:// space

#163

Post by bovermyer »

Semiapies wrote: post #161
bovermyer wrote: post #87

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.

Given that the docs say the biggest thing it needs is actual content , I'm not sure what character it really has.

There is rather a lot of content available already. For example, here's a link to a gemlog I enjoy:

gemini://idiomdrottning.org/texts.gmi

Re: gemini:// space

#164

Post by ufmace »

krapp wrote: post #155
ufmace wrote: post #143

Earlier quoted context omitted.

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

>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. Given the aggressive anti-complexity stance of Gemini, isn't that supposed to be a feature? A messageboard isn't a static text document, it doesn't belong there.

It's on the protocol designers and promoters to determine what it ends up being of course. It seems like a bit of a mismatch to me right now. The client cert support as the exclusive way to identify users is a really cool feature of the protocol IMO, but it doesn't seem like it's very useful without dynamically rendered pages. It's certainly possible to do dynamically rendered pages now, but they're also of much more limited use without the ability to send complex data to the server using the same protocol.

Re: gemini:// space

#165

Post by tenebrisalietum »

marshal_mellow wrote: post #148
tenebrisalietum wrote: post #106

Earlier quoted context omitted.

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.

Theres a gemini browser called lagrange that has inline images/audio

Yep, just tried LaGrange. I think I like it better than GemiNaut but it's good there are multiple clients and choices. :)

Re: gemini:// space

#166

Post by tjalfi »

Arnavion wrote: post #7
prepperdev wrote: post #3

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…

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.)

I would argue that being limited to two levels is a feature.

Here's a related quote[0] from Edward Tufte.

"Dr Spock's Baby Care is a best-selling owner's manual for the most complicated 'product' imaginable -- and it only has two levels of headings. You people have 8 levels of hierarchy and I haven't even stopped counting yet. No wonder you think it's complicated."

[0] http://web.archive.org/web/20080610092329/http://blogs.sun.c...

Re: gemini:// space

#167

Post by betwixthewires »

On the last paragraph in the article (criticism of the lack of extensibility of the protocol), Gemini itself is a protocol largely designed to improve on the modern shortcomings of the gopher protocol, so if ever Gemini were to fall short of the demands of the type of people that use protocols like this, the solution is right under your nose: make a new protocol.

I'm a big fan of Gemini. I think the philosophy around light document delivery over the internet is very important. And the lack of extensibility is a core part of that, Gemini cannot be everything to everyone, by design. And no protocol should, I personally find the idea that http is used to deliver news articles and web apps to be a bit ridiculous, the protocol was extended well beyond what it was intended, and I can find no reason for this other than that people don't like typing different things on the left side of the "://", if they ever even type that part at all. Imagine an internet where people routinely use different protocols (and know about it), how much cleaner the experience would be.

Re: gemini:// space

#168

Post by betwixthewires »

h_anna_h wrote: post #25

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

The idea isn't to use more simple tools, but to create an environment where only simple tools can be used.

Http was made to transport documents to people (or machines) requesting them. Then images. Then form submissions. Now, try going to a website where all you're trying to do is read some text and see what you get. The vast majority of web browsing to this day is people trying to read text. Yet the vast majority of links you click go to great lengths to do things other than deliver you text. Wouldn't you say, at least for that use case, that a more restrictive protocol would make everyone's lives a little better? It is not enough to just write documents without the megabytes of cruft packed in, you must make it so that to reach people you cannot pack megabytes of cruft into your documents.

Re: gemini:// space

#169

Post by betwixthewires »

tenebrisalietum wrote: post #106
h_anna_h wrote: post #35

Earlier quoted context omitted.

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: > W…

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.

Please no inline links whatsoever ever in Gemini.

Re: gemini:// space

#170

Post by betwixthewires »

gerikson wrote: post #89
julius wrote: post #9

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)

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.

I felt that way at first, but when I started to understand the reasoning behind it (explained in the Gemini space FAQ and counties meta articles, which is a lot of Gemini documents) it makes perfect sense.

When you're reading a document, it is to enjoy information. Whether that's learning, recreational reading of fiction, or whatever, a subtle part of the experience is the structure of the document. It gives you context and helps maintain a flow of thought. A reference to an external document should be plain as day and stand out. It should not bleed into any other part of the document.

This might sound like an over rationalization, but to get an idea for this, imagine if footnotes or references were tossed in using parentheses wherever they were referenced. The structure of the document is important, sometimes as important as the content.

Post reply on HN