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

Castor: A browser for the small internet (Gemini, Gopher, Finger)

sr.ht

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#71

Post by anthk »

Grumbledour wrote: post #47
cookiengineer wrote: post #35

Earlier quoted context omitted.

From an implementor's view I decided to not implement Gemini as it is specified, because I do not like its text/gemini default format. They should either decide for a specified full file format, e.g. CommonMark or HTML5 (with index.html as default routes) or don't try to implement a file format inside a network protocol at all. In my opinion, file structures (and layouts thereof) should have nothing to do with a netw…

I agree on the own text format. It just seems needlessly complicated without really offering benefits. The argument of focusing on text over styling is a fair one, but it would also have been easy to only support a subset of HTML/CSS. If one has to create a new format for Hypertext, it should however do more than HTML does and really innovate on the concept. That would have been interesting, to make it for example mo…

Html and css are bloated and XML based. They suck. Gemini is easy to implement and parse.

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#72

Post by anthk »

qwerty456127 wrote: post #62
caribousoup wrote: post #61

Earlier quoted context omitted.

I think this is the wrong solution. We need strong whitelist controls in all of the browsers. Because when you connect to a website, you have no idea if it's going to start downloading 30 MB worth of images and 40 Javascript requests. It's gone completely out of control. I say this as a web dev on a rural connection. Not only is it slow, I PAY for this, bandwidth is limited. For some lazy dev who doesn't compress the…

> If browser preferences has options for auto disabling Javascript on a webpage that initiated X amount of outbound connections, or auto stops when there are 30 img requests on page load, I should be in control of not allowing that. I should be in control of setting that threshold for different request types. I doubt this is hard to implement. Somebody can build a Firefox/Chromium fork (or even an extension perhaps?)…

UBlock Origin can do that. It can block media over X MB, and lot of nasty JS things too.

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#73

Post by sloum »

badsectoracula wrote: post #28
moonchild wrote: post #25

Earlier quoted context omitted.

TCP and IP are not exactly trivial, though certainly much simpler than TLS. There's no shame in using a library for TLS, either.

Sure but a socket interface is available pretty much universally and there is only one API per OS about it to access it, so no worries about breaking libraries or whatever - and really all OSes pretty much use the same API. TLS on the other hand has multiple implementations and the situation is different per OS. I'm not sure how stable the APIs are either or if you can release -say- a binary that can expect that the…

Solderpunk, the originator of the gemini idea and main shepherd of its direction, has on his git repository examples of clients and servers in The original idea was that it should be something anyone can implement as a weekend project. Most major languages seem to have fairly stable TLS libs (I know from the current clients that Go, Rust, Python, and some version of Lisp - cant remember which - all do).

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#74

Post by sloum »

taborj wrote: post #63
petercooper wrote: post #54

I maintain a .plan file and finger server at peter@tcp.rip / finger://peter@tcp.rip/ if you want to try something out.

I need to get my NodeMCU weather station back online so I can feed it to my .plan file and run fingerd again. Back in the 90s, it was good fun seeing all the stuff people put out on finger. Aside from the link someone else posted to Shodan, is there a list of finger servers anywhere?

The author of Castor hosts an awesome finger server. Try finter://typed-hole.org

(fingering the main host will give you a list of quirky options, including how to get the current server cpu temperature)

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#75

Post by sloum »

edraferi wrote: post #60

These technologies could be used to create a valuable network of low-distraction reference resources. They might dodge the Eternal September problem simply due to the the high barrier to entry and win mindshare among sophisticated users by delivering real value. This would require a community focus on tooling and content. First, common tools must support Gopher/Gemini output: * Pandoc * Template engines like Jinja an…

There is currently a partial lobste.rs mirror hosted at typed-hole.org over gemini (as well as gopher). Gopher also has gopherpedia which mirrors wikipedia (many clients for gemini also support gopher). While I dont think mirroring should be the end goal, I agree it is a good stepping stone to original content to have , as you put it, low-distraction access to these resources.

Recent work has gone on to allow git cloning over gemini and there is syntax support for the, admittedly minimal, text/gemini format in vim and emacs.

I would love to see pandoc support (and believe someone recently mentioned working on on the mailing list). Great ideas! Pick one and build!

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#76

Post by sloum »

anthk wrote: post #57

Gemini needs a sacc like client: - written in C - Dumb simple - Fast Bombadillo is a bit sluggish for my taste.

Bombadillo dev here. When you say sluggish do you mean at the transmission layer or in the user experience? I'm working on adding in some concurrency for both screen drawing and requests that should eventually result in increased speed for the user when navigating around (less blocking going on overall). Sadly, I am a little ways away from having time to complete it. Would love patches if you are interested though ;)

Also: I definitely agree a sacc-like client would be great!

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#77

Post by anthk »

sloum wrote: post #76
anthk wrote: post #57

Gemini needs a sacc like client: - written in C - Dumb simple - Fast Bombadillo is a bit sluggish for my taste.

Bombadillo dev here. When you say sluggish do you mean at the transmission layer or in the user experience? I'm working on adding in some concurrency for both screen drawing and requests that should eventually result in increased speed for the user when navigating around (less blocking going on overall). Sadly, I am a little ways away from having time to complete it. Would love patches if you are interested though ;)…

screen refreshing is -sometimes- slow, getting the content is as fast as sacc.

    .go version
     go version go1.13.1 openbsd/amd64
Also, I'd love to go back/forward with h/l.

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#78

Post by rdrey »

apatters wrote: post #5
kick wrote: post #2

For anyone curious, because Gemini is relatively new and kind of has flown under the radar: ### 1.1 What is Gemini? Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files. Gemini is intended to be simple, but not necessarily as simple as possible. Instead, the design…

I was delighted when I saw that Gemini is maintained by someone on SDF (named Solderpunk, never heard of him before). This seems as good a time as any to plug https://sdf.org , a great little community which has the feel of a 90s BBS that never went offline.

Wow, this lead me down quite a rabbit hole. I hadn't heard of SDF, thanks!

Re: Castor: A browser for the small internet (Gemini, Gopher, Finger)

#79

Post by sloum »

anthk wrote: post #77
sloum wrote: post #76

Earlier quoted context omitted.

Bombadillo dev here. When you say sluggish do you mean at the transmission layer or in the user experience? I'm working on adding in some concurrency for both screen drawing and requests that should eventually result in increased speed for the user when navigating around (less blocking going on overall). Sadly, I am a little ways away from having time to complete it. Would love patches if you are interested though ;)…

screen refreshing is -sometimes- slow, getting the content is as fast as sacc. .go version go version go1.13.1 openbsd/amd64 Also, I'd love to go back/forward with h/l.

I can definitely add h/l into the next release :) As to the screen refresh, I am not in love with the current method for screen drawing and hope to have that incrementally improved over time. Thanks for the info/feedback!
Post reply on HN