💾 Archived View for makeworld.space › cgi-bin › gemini-irc captured on 2022-04-29 at 11:02:02.
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Logs from #gemini on tilde.chat
The most recent 100 lines.
Scroll to the bottom for the latest.
-----------------------------------------
[2022-04-28T21:08:26.122Z] *** leomd (dbb090cfd64@tilde.team) joined
[2022-04-28T21:11:59.127Z] *** dimkr (~dimkr@5.22.128.168) quit (Ping timeout: 120 seconds)
[2022-04-28T21:21:11.694Z] <sysrq> pandoc is bloated
[2022-04-28T21:33:28.119Z] *** leomd (dbb090cfd64@tilde.team) left (#gemini)
[2022-04-28T21:46:25.738Z] <nihilazo> pandoc is cool
[2022-04-28T21:46:34.666Z] <nihilazo> it's big because it does so much stuff
[2022-04-28T21:47:25.820Z] <nihilazo> I'd only say it's "bloated" in that for some stupid reason arch linux packages it as a non-compiled haskell program by default and you need all the haskell deps instead of just a static binary
[2022-04-28T21:47:32.527Z] <nihilazo> but that's an arch problem not a pandoc problem
[2022-04-28T21:48:12.669Z] <nihilazo> and it should run on ARM, ghc runs on ARM so there is no reason pandoc shouldn't
[2022-04-28T21:49:59.166Z] *** jtecca (jtecca@tilde.institute) joined
[2022-04-28T22:35:51.332Z] *** santiago (~Santiago39@2800:a4:1596:1500::cd0) quit (Ping timeout: 120 seconds)
[2022-04-28T22:38:34.291Z] *** jtecca (jtecca@tilde.institute) quit (quit: WeeChat 2.9)
[2022-04-28T22:48:30.889Z] *** santiago (~Santiago39@2800:a4:15f0:4200::cd0) joined
[2022-04-28T22:53:21.690Z] <kelbot> mhj: no a Pinephone
[2022-04-28T22:54:40.887Z] <kelbot> nihilazo: ah, well alpine only packages it for x86 for some reason.
[2022-04-28T23:01:25.017Z] *** gast0n (~g4570n@tilde.vhost) joined
[2022-04-28T23:02:22.124Z] *** leomd (dbb090cfd64@tilde.team) joined
[2022-04-28T23:26:21.431Z] *** santiago (~Santiago39@2800:a4:15f0:4200::cd0) quit (Ping timeout: 120 seconds)
[2022-04-28T23:41:38.463Z] *** santiago (~Santiago39@r167-61-158-42.dialup.adsl.anteldata.net.uy) joined
[2022-04-29T00:00:07.777Z] *** leomd (dbb090cfd64@tilde.team) left (#gemini)
[2022-04-29T00:19:15.698Z] *** zephryn (fe93d8363dc@tilde.team) left (#gemini)
[2022-04-29T00:24:03.781Z] *** Strengths (~chmod@2001:4479:e000:db00:ac79:f1c8:12f6:d3a0) joined
[2022-04-29T01:49:35.006Z] *** zephryn (fe93d8363dc@tilde.team) joined
[2022-04-29T02:01:25.125Z] *** leomd (dbb090cfd64@tilde.team) joined
[2022-04-29T02:07:46.477Z] *** carriunix (~carriunix@189.123.130.96) quit (Ping timeout: 120 seconds)
[2022-04-29T03:02:15.389Z] *** gast0n (~g4570n@tilde.vhost) quit (quit: Bye, see you soon! 👋)
[2022-04-29T03:25:02.030Z] *** cyberwolf (~cyberwolf@h83-174-227-134.static.bashtel.ru) joined
[2022-04-29T04:03:50.703Z] *** rainingmonkey (~TRM@5ec358a7.skybroadband.com) joined
[2022-04-29T04:07:47.610Z] *** leomd (dbb090cfd64@tilde.team) left ("Error from remote client")
[2022-04-29T04:31:27.128Z] *** santiago (~Santiago39@r167-61-158-42.dialup.adsl.anteldata.net.uy) quit (Connection reset by peer)
[2022-04-29T04:33:13.420Z] *** santiago (~Santiago39@r167-61-119-61.dialup.adsl.anteldata.net.uy) joined
[2022-04-29T04:38:52.721Z] *** rainingmonkey (~TRM@5ec358a7.skybroadband.com) quit (Ping timeout: 120 seconds)
[2022-04-29T04:55:58.545Z] *** zephryn (fe93d8363dc@tilde.team) left (#gemini)
[2022-04-29T05:10:34.699Z] *** Strengths (~chmod@2001:4479:e000:db00:ac79:f1c8:12f6:d3a0) quit (quit: Ambassador 1.3.0 [UXP 4.5.9/20200424040914])
[2022-04-29T05:50:21.255Z] *** dimkr (~dimkr@5.22.128.168) joined
[2022-04-29T06:26:59.609Z] <nihilazo> huh
[2022-04-29T07:08:23.292Z] *** epoch (~epoch@98.159.74.235) quit (The TLS connection was non-properly terminated.)
[2022-04-29T07:33:40.389Z] *** wyfnt (~wyfnt1232@103.51.58.113) joined
[2022-04-29T07:34:17.140Z] *** lukaso666 (~lukaso666@193.106.209.236) quit (quit: все, пока!)
[2022-04-29T07:35:04.154Z] *** xq (~xq@v43666.php-friends.de) joined
[2022-04-29T07:53:14.206Z] *** wyfnt (~wyfnt1232@103.51.58.113) quit (quit: Leaving)
[2022-04-29T08:01:44.362Z] *** cyberwolf (~cyberwolf@h83-174-227-134.static.bashtel.ru) quit (quit: WeeChat 3.5)
[2022-04-29T08:30:41.347Z] *** JmaJeremy000 (~JmaJeremy@cpe989d5df07979-cm989d5df07977.cpe.net.cable.rogers.com) joined
[2022-04-29T08:49:55.112Z] *** Strengths (~chmod@2001:4479:e000:db00:64a8:2aa4:214f:5ff8) joined
[2022-04-29T08:55:28.086Z] <dimkr> anyone with experience with libtls?
[2022-04-29T10:01:25.729Z] <sysrq> rtfm
[2022-04-29T10:08:02.498Z] <Laerte> is it written in the manual who have some experience with libtls?
[2022-04-29T10:08:17.405Z] <Laerte> dimkr sorry, I don't
[2022-04-29T10:08:58.065Z] <dimkr> the manual isn't great, the only way to distinguish between closed socket and end-of-response is hacky
[2022-04-29T10:33:26.123Z] *** leomd (dbb090cfd64@tilde.team) joined
[2022-04-29T10:33:40.571Z] <koalillo> (I suspect TLS doesn't have the two generals problem [but I'd like to know for sure], so this is not due to that problem... but if by chance you're not familiar with the two generals problem, it's worth a read)
[2022-04-29T10:35:03.034Z] <dimkr> the problem isn't TLS, but the implementation of Gemini servers
[2022-04-29T10:35:30.233Z] <dimkr> some don't do the close_notify thing and just close the socket after the response is sent
[2022-04-29T10:36:35.794Z] <koalillo> for some purpose, it's a bug, or a gap in the protocol spec? I don't know much about those matters, I'm just fascinated by the two generals problem
[2022-04-29T10:36:57.705Z] <dimkr> the spec says "Gemini servers MUST send a TLS `close_notify` prior to closing the connection"
[2022-04-29T10:37:20.592Z] <dimkr> but as far as I see some servers don't do that
[2022-04-29T10:38:28.126Z] <koalillo> interesting. well, it's the kind of thing that it's easy to forget to implement. given the characteristics of the protocol, that's a bad problem :(
[2022-04-29T10:38:58.353Z] <koalillo> I wonder how Gemini will fare with implementation-specific "bugs". hopefully better than HTTP/HTML :D
[2022-04-29T10:39:29.315Z] <dimkr> "This is essential to disambiguate completed responses from responses closed prematurely due to network error"
[2022-04-29T10:39:33.504Z] <koalillo> (obviously, well done to the spec by specifying that clearly)
[2022-04-29T10:39:43.383Z] <koalillo> (exactly, lack of content-length, I assume)
[2022-04-29T10:39:45.360Z] <dimkr> it will end up having the same problem as Gopher unless all servers obey the spec
[2022-04-29T10:40:32.757Z] <koalillo> it's frequent for Gopher responses to be cut? honestly, I never used Gopher frequently. I did play with it a little bit recently for curiosity, but I didn't go far with that
[2022-04-29T10:41:36.987Z] <dimkr> it probably doesn't happen 100%, but it's probably a worse problem in Gemini with things like .mp4 files, which may still be valid if cut
[2022-04-29T10:42:51.025Z] <koalillo> yeah. I think it's pretty okay-ish to use HTTP links for big media files. Although there should be a modern FTP equivalent :) (probably someone already wrote one?). Or maybe some bittorrent-based thing?
[2022-04-29T10:43:32.937Z] <ew0k> dimkr: the spec hasn't always required the close_notify. It was left out because of oversight
[2022-04-29T10:44:06.283Z] <dimkr> I thought this was problem #1 or #2 to fix with Gopher :)
[2022-04-29T10:44:20.899Z] <ew0k> dimkr: that said I believe the idea is that a human will look at the received file and notice if it's incomplete
[2022-04-29T10:44:54.283Z] <koalillo> maybe... a trailing mark would be a good idea? I'd think it might be nicer for implementors
[2022-04-29T10:45:35.256Z] <dimkr> any sequence of bytes can randomly appear in binary files
[2022-04-29T10:45:59.589Z] <dimkr> the only solution is at the transport layer, close_notify is perfect for this
[2022-04-29T10:46:16.259Z] <koalillo> you could define it at the beginning? but yeah, I hadn't thought of that.
[2022-04-29T10:46:21.523Z] <ew0k> koalillo: it was discussed early on but rejected. The rationale was that gemini will primarily be used for small files and 99.9% of the time it's very unlikely that an initiated connection will fail before transfer is complete.
[2022-04-29T10:47:17.198Z] <ew0k> the protocol is unsuitable for big file transfers. Not only for the common lack of close_notify, but also because it has no mechanism for chunking or resumption, for example
[2022-04-29T10:47:54.040Z] <ew0k> and that's a conscious design choice. Basically gemini should be used for what it's good at and leave the rest to other protocols :)
[2022-04-29T10:48:55.364Z] <dimkr> do large file downloads over HTTPS and count unique users there :p
[2022-04-29T10:50:07.344Z] <ew0k> dimkr: if downloaded through a browser using cookies, yeah :) Otherwise I guess IP is the only distinguished feature of users. Am I right?
[2022-04-29T10:50:25.201Z] <dimkr> user agent, resolution, etc'
[2022-04-29T10:50:33.036Z] <dimkr> all the stuff that's used for user fingerprinting
[2022-04-29T10:50:40.672Z] <koalillo> user agents and... see panopticlick :)
[2022-04-29T10:51:11.633Z] <ew0k> well, those are mostly provided by web browsers though. You could always download with any http lib, like libcurl for example
[2022-04-29T10:51:30.487Z] <ew0k> curl, wget, even if from the CLI
[2022-04-29T10:52:07.984Z] <ew0k> best would of course be if the gemini browser could download files like that, but I guess the assumption is that you'll have your own favourite tool for it :)
[2022-04-29T10:52:58.564Z] <koalillo> I think having good ways to integrate Gemini clients with other protocol clients would be nice. Otherwise the "dream" of easily implemented Gemini clients might "worsen"
[2022-04-29T10:53:11.484Z] <ew0k> yeah
[2022-04-29T10:53:34.913Z] <ew0k> I know AV-98 and a few more have config options for which tools should be used to open other links or file types
[2022-04-29T11:17:57.400Z] *** grufwub (~grufwub@static.148.168.119.168.clients.your-server.de) joined
[2022-04-29T11:35:00.747Z] *** Guest55695 changed nick to omni
[2022-04-29T11:52:23.727Z] <ew0k> Crapilicious. Antenna is failing to find one feed and generating the links wrong for another. And I might not have time to have a look at it until tomorrow
[2022-04-29T13:03:53.034Z] *** dimkr (~dimkr@5.22.128.168) quit (quit: Page closed)
[2022-04-29T13:08:06.008Z] *** yottatsa (foobar@tilde.gay) quit (Ping timeout: 120 seconds)
[2022-04-29T13:09:28.548Z] *** yottatsa (foobar@tilde.gay) joined
[2022-04-29T13:38:21.021Z] *** aexoxea (~aexoxea@2001:44b8:111e:a700:2a21:701b:5ea2:abf0) joined
[2022-04-29T13:46:40.796Z] <kelbot> ew0k: Oh no.
[2022-04-29T13:47:37.937Z] <kelbot> ew0k: Amfora has a nice set of options for specifying what to do with different file types in the config. I have it opening images with an external image viewer and videos with mpv.
[2022-04-29T14:21:22.483Z] *** rainingmonkey (~TRM@5ec358a7.skybroadband.com) joined
[2022-04-29T14:29:10.054Z] *** d0 (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) quit (quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[2022-04-29T14:31:26.029Z] *** rainingmonkey (~TRM@5ec358a7.skybroadband.com) quit (Ping timeout: 120 seconds)
[2022-04-29T14:32:49.231Z] *** d0 (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) joined
[2022-04-29T14:47:41.126Z] *** zephryn (fe93d8363dc@tilde.team) joined