Minetest logo

IRC log for #minetest-dev, 2024-09-02

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:29 SFENCE joined #minetest-dev
00:52 Lupercus joined #minetest-dev
01:07 SFENCE joined #minetest-dev
01:32 SFENCE joined #minetest-dev
01:50 SFENCE joined #minetest-dev
01:55 v-rob joined #minetest-dev
02:08 SFENCE joined #minetest-dev
02:10 v-rob joined #minetest-dev
02:19 v-rob joined #minetest-dev
02:32 SFENCE joined #minetest-dev
02:33 SFENCE joined #minetest-dev
03:10 SpaceManiac joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
04:18 SFENCE joined #minetest-dev
04:21 cranez joined #minetest-dev
04:28 mtvisitor is it possible to change the minetest product development meeting from sunday to friday ? this is just my personal suggestion.
04:29 mtvisitor product quality and data pravicy is important.
04:30 mtvisitor it is also ideal status that we did not lose any data.
04:37 SFENCE joined #minetest-dev
04:39 SFENCE joined #minetest-dev
04:54 v-rob joined #minetest-dev
05:10 SFENCE joined #minetest-dev
05:52 luk3yx joined #minetest-dev
05:57 sfan5 #15087 ready for review but more importantly further testing
05:57 ShadowBot https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5
08:17 MTDiscord <greenxenith> Was there an issue opened already for error kick messages not wrapping?
10:26 Desour joined #minetest-dev
11:50 MTDiscord <luatic> merging #14557 in 1h
11:50 ShadowBot https://github.com/minetest/minetest/issues/14557 -- Add static glTF support by JosiahWI
11:53 Desour nice, so it's precisely 5d
12:10 Lupercus joined #minetest-dev
12:28 MTDiscord <wsor4035> (In reply to greenxenith) Not that I am aware of
12:50 MTDiscord <luatic> done 🎉
13:13 Desour joined #minetest-dev
13:42 SFENCE joined #minetest-dev
13:53 [MatrxMT] <Zughy> Industry standard, niiiice!
13:53 SFENCE joined #minetest-dev
13:53 MTDiscord <rollerozxa> yoo it's merged
13:54 MTDiscord <wsor4035> i mean, its non animated, so obj is also industry standard. once animated is in, yeah - mt will support an industry standard animated format
13:57 SFENCE joined #minetest-dev
13:59 sfan5 merging #15096, #15099, #15101, #15033 in 10m
13:59 ShadowBot https://github.com/minetest/minetest/issues/15096 -- Use std::string_view in logging code by sfan5
13:59 ShadowBot https://github.com/minetest/minetest/issues/15099 -- Reduce include count in headers by SmallJoker
13:59 ShadowBot https://github.com/minetest/minetest/issues/15101 -- Allow to disable transparency sorting entirely by Desour
13:59 ShadowBot https://github.com/minetest/minetest/issues/15033 -- Show full texture string in generateImage(): Failed to generate errors by Emojigit
14:05 SFENCE joined #minetest-dev
14:09 SFENCE joined #minetest-dev
14:12 MTDiscord <luatic> marked #14685 as ready for review; it is at a manageable ~500 loc now that the static PR is merged.
14:12 ShadowBot https://github.com/minetest/minetest/issues/14685 -- Add animated glTF support by appgurueu
14:15 SFENCE joined #minetest-dev
14:21 SFENCE joined #minetest-dev
14:21 MTDiscord <josiah_wi> Hmm, changes to camera.cpp? Is this fixing a Minetest client bug? 🤔
14:22 MTDiscord <josiah_wi> Ah, it's a rename.
14:22 MTDiscord <luatic> should probably make the PR [nosquash]
14:23 MTDiscord <luatic> this one is https://github.com/minetest/minetest/pull/14685/commits/ca5311a313c28839be0fa00d889f6bf2676cf500
14:23 MTDiscord <josiah_wi> Good idea. You have some commits like "minify" that you could squash manually locally.
14:24 MTDiscord <luatic> yeah i will rewrite history before merge
14:24 MTDiscord <luatic> marked it "manual merge"
14:24 SFENCE joined #minetest-dev
14:24 MTDiscord <josiah_wi> Manual merge is a thing? xD
14:24 MTDiscord <luatic> tbh i'm not quite sure it is the correct term here
14:25 MTDiscord <luatic> because i will just merge via rebase, but before that i will squash commits as is sensible
14:25 MTDiscord <luatic> but if i just wrote nosquash others might assume that the commits are to be merged as-is
14:25 MTDiscord <luatic> if i wasn't lazy i would eagerly rewrite history
14:26 MTDiscord <josiah_wi> Oh yes, this PR also contains a b3d fix haha. The no-inverse-matrix issue.
14:27 MTDiscord <luatic> arguably that i will squash, since it was caused by changes made for animated gltf
14:36 SFENCE joined #minetest-dev
14:37 Desour you could also use autosquash (see `git commit --fixup <commit>` and `git rebase --autosquash <branch>`)
14:44 SFENCE joined #minetest-dev
14:46 SFENCE joined #minetest-dev
15:09 red-001 I thought github already supported autosquash in the UI?
15:11 Desour would be new to me. but I haven't tried merging a PR that has fixup commits left
15:12 red-001 I was probably just thinking of standard squashing
15:35 SFENCE joined #minetest-dev
15:35 Desour joined #minetest-dev
15:35 luk3yx joined #minetest-dev
15:35 MTDiscord joined #minetest-dev
15:35 SpaceManiac joined #minetest-dev
15:35 Eragon joined #minetest-dev
15:35 panwolfram joined #minetest-dev
15:35 nekobit joined #minetest-dev
15:35 red-001 joined #minetest-dev
15:35 Warr1024 joined #minetest-dev
15:35 ivanbu joined #minetest-dev
15:35 vampirefrog joined #minetest-dev
15:35 Pexin joined #minetest-dev
15:35 Evergreen3 joined #minetest-dev
15:35 fgaz_ joined #minetest-dev
15:35 Niklp joined #minetest-dev
15:35 Juri joined #minetest-dev
15:35 thelounge6564 joined #minetest-dev
15:35 jonadab joined #minetest-dev
15:35 BuckarooBanzai joined #minetest-dev
15:35 [MatrxMT] joined #minetest-dev
15:35 izzyb joined #minetest-dev
15:35 book` joined #minetest-dev
15:35 ROllerozxa joined #minetest-dev
15:35 nore joined #minetest-dev
15:35 TheCoffeMaker joined #minetest-dev
15:35 ShadowBot joined #minetest-dev
15:35 hlqkj joined #minetest-dev
15:35 sofar joined #minetest-dev
15:35 Thomas-S joined #minetest-dev
15:35 basxto joined #minetest-dev
15:35 Noisytoot joined #minetest-dev
15:35 pgimeno joined #minetest-dev
15:35 sugarbeet joined #minetest-dev
15:35 swift110-mobile joined #minetest-dev
15:35 clavi joined #minetest-dev
15:35 Mantar joined #minetest-dev
15:35 [0] joined #minetest-dev
15:35 figboot joined #minetest-dev
15:35 hifi joined #minetest-dev
15:35 sfan5 joined #minetest-dev
15:35 calculon joined #minetest-dev
15:35 dv^_^ joined #minetest-dev
15:35 MisterE1230 joined #minetest-dev
15:35 rubenwardy joined #minetest-dev
15:35 Krock joined #minetest-dev
15:35 Soni joined #minetest-dev
15:35 dzho joined #minetest-dev
15:35 citrons joined #minetest-dev
15:35 wsor4035 joined #minetest-dev
15:35 razzlom joined #minetest-dev
15:35 nrz joined #minetest-dev
15:48 v-rob joined #minetest-dev
16:16 sfan5 Desour: have you considered PR'ing the tracy integration
16:17 sfan5 it looks very cool and useful
16:19 Desour I haven't considered, but could do
16:20 Desour is using FetchContent (only if the tracy compile flag is enabled of course) in cmake fine?
16:22 rubenwardy Distros generally don't like that but it's fine as it's a dev tool
16:25 SFENCE joined #minetest-dev
16:28 SFENCE joined #minetest-dev
16:34 SFENCE joined #minetest-dev
16:45 SpaceManiac joined #minetest-dev
16:46 SFENCE joined #minetest-dev
16:46 fluxionary joined #minetest-dev
16:55 SFENCE joined #minetest-dev
17:05 SFENCE joined #minetest-dev
17:11 SFENCE joined #minetest-dev
17:17 SFENCE joined #minetest-dev
17:19 SFENCE joined #minetest-dev
17:21 v-rob joined #minetest-dev
17:26 red-001 cause it doesn't go through their own distro specific package repo?
17:26 Krock hmm interesting. The glTF PR alone managed to add 0.5 MB of code to the binary (gcc, without LTO)
17:27 red-001 not too surprising, it was a hefty PR
17:27 Desour red-001: AFAIK they don't like it because they'd need an internet connection to build the packages
17:28 Desour and they usually build packages in containers
17:29 Desour Krock: 0.5 MB of how much?
17:29 red-001 wonder if the server could convert all meshes to glTF once animation support is there. Trying to make sure one format parser written in C/C++ is secure is bad enough, much less maintaining all those old ones
17:30 red-001 <+Desour> K.r.o.c.k: 0.5 MB of how much?:
17:30 red-001 windows MSVC build outputs are 11 MB, I presume GCC on linux would be somewhere around that or a bit smaller
17:31 Desour it depends on your build options though
17:31 Krock Desour: previously 12.8 MiB, now 13.3 MiB.
17:31 Desour for example, my minetest binary is currently about 257 MiB big
17:32 Desour Krock: oh, so much
17:32 Krock I assume that's Rel with debug info?
17:32 Desour yes, and with tracy linked
17:32 Krock mine's a standard release build
17:34 SFENCE joined #minetest-dev
17:39 red-001 I mostly switched over the network encryption PR to use HACL*, I did look for a dTLS 1.3 library but it genuinely seems like the wolfSSL is the *only* implementation that exists
17:41 red-001 made some progress on getting a formal description of the protocol in proverif, not sure if that would be considered good enough for showing the idea is sound
17:42 SFENCE joined #minetest-dev
17:46 SFENCE joined #minetest-dev
17:50 SpaceManiac joined #minetest-dev
17:50 red-001 I would be happy to switch again to NACL or libsodium if needed
17:50 red-001 even if the formal verification is nice
17:50 Krock does cURL expose anything that we could make use of?
17:51 SFENCE joined #minetest-dev
17:53 SFENCE joined #minetest-dev
17:54 red-001 not reliably I don't think
17:54 red-001 sometimes it comes with openssl, but only sometimes
17:54 rubenwardy Are you basing your decisions off some standard / preexisting way of doing game encryption
17:54 rubenwardy Or just throwing together crypto
17:55 Krock for latter the crypro bros might have some ideas
17:55 SFENCE joined #minetest-dev
17:56 Krock dTLS and QUIC seem to be viable options. except that achieving backwards compat would be somewhat difficult
17:58 SFENCE joined #minetest-dev
17:59 red-001 it could be more standard admittedly, I tried to follow what TLS 1.3 does when it comes to design decisions, just with a lot less features. The choice of using AES-128-GCM with a 96-bit tag was based on the minimal specs for authentication encryption per NIST.
17:59 red-001 the ECDHE should be very similar to the TLS one
18:01 red-001 I did some questionable things with SRP to make it work, but I rolled back those changes and it should be more standard
18:01 Desour I don't have doubts that red-001's protocol is secure (and therefore I don't request a formal verification). but I have worries that we don't want to use a custom protocol. it's less about the crypto stuff and more about having a standardized protocol
18:02 Desour (just my opinion)
18:02 Desour standard dtls, and quic, for example, will not have issues working in other tools, like wireshark
18:03 Desour and we don't have to keep protocol doc and implementation around
18:04 red-001 Would you be okay with tabling that for whenever the protocol in general is replaced? Like I said there is no dtl1.3 implementation with a compatible license yet
18:08 Desour no dtls1.3 lib with a compatible license? I think I missed that
18:08 SFENCE joined #minetest-dev
18:09 Desour gnutls seems to be LGPLv2.1+
18:11 red-001 https://gitlab.com/gnutls/gnutls/-/issues/1019
18:11 red-001 !title
18:11 ShadowBot Add support for DTLS 1.3 (#1019) · Issues · gnutls / GnuTLS · GitLab
18:11 red-001 seems to just support dTLS 1.2
18:15 Desour oh, I see now. sorry!
18:19 red-001 I mean dTLS 1.2 is fine I suppose, I presume most of those protocol bugs have been worked around or fixed by now. Just need to configure a secure cipher suite since the default might be insecure
18:19 SFENCE joined #minetest-dev
18:20 red-001 but it would really work better with a whole new protocol, as in from the very first packet to the very last packet, having everything sent via dTLS.
18:21 red-001 would probably want to use self-signed certificates and do the actual validation in a MT specific way
18:25 Desour I had suggested in the PR to use ecdh to get a key and use that one as fake pre shared key. but we could instead use a fixed fake psk, and leave the ecdh to dtls. that way, and if we knew the server and client are speaking dtls, every packet could be dtls (but the first ones would of course not be properly encrypted)
18:26 SFENCE joined #minetest-dev
18:26 red-001 it's not a bad idea, I see your point about making it easier to use with wireshark, that's certainly a concern
18:28 red-001 I'm not sure just switching to DTLS is a good solution to that however. The issue with decrypting packets with a Lua script mostly comes down to A) having to load a library to do it, which doesn't seem too difficult and B) the seq_num being just the lower 16-bits of a 48-bit counter
18:29 red-001 dTLS would mean I guess including another sequence counter, could just include the extra 32-bits or even just 16-bits and not really have to worry about that anymore
18:29 Sharpman joined #minetest-dev
18:31 red-001 surely no-one would send more than maybe 2^32 packets and if they do, then not much more
18:35 red-001 as for that SRP concern I had, it seems that at least gnuTLS supports an application getting the master key but only for tls 1.2 and lower
18:37 SFENCE joined #minetest-dev
18:38 red-001 ah TLS 1.3 supports key exporters so can use those there
18:38 red-001 https://datatracker.ietf.org/doc/html/rfc5705
18:40 red-001 Desour, I will take a look at implementing this all with dTLS and gnuTLS in another branch, looks like there is a TLS extension for what I wanted
18:41 red-001 and at least gnuTLS implements it https://www.gnutls.org/reference/gnutls-gnutls.html#gnutls-prf-rfc5705
18:50 Desour I'm looking forward to it! ^^  (also, sorry for my half-informed criticism of your work btw., I have been more annoying than necessary. and it's awesome someone is working on this)
18:53 red-001 no worries, always good to get another perspective, that said I'm not sure what the general sentiment will be around pulling in all of gnuTLS, it's a larger library and all
18:53 red-001 I still suspect it might be better to pair that with a general network rewrite
18:54 Desour can't we use the library from the package manager?
18:54 Desour (same for the crypto lib. I saw your PR added 90k lines)
18:57 Desour vcpkg and brew have gnutls. and in linux it's also common, afaik
19:00 v-rob joined #minetest-dev
19:01 sfan5 thanks to Krock for actually testing the performance of my PR
19:02 Krock sfan5: tbh I didn't expect much of a difference and was somewhat surprised to see such difference between the builds
19:02 Krock the older binary was slightly outdated, thus recompiled with a clean master to have an apples-to-apples comparison. well done.
19:05 red-001 <+Desour> can't we use the library from the package manager?
19:05 red-001 Probably can, could have cut down on the amount of HACL* code pulled in too, but wasn't sure that was worth it. Editing a third party library and all.
19:05 red-001 OpenSSL could be included from a package manager too, but still need to ship it for the Windows and Android builds
19:11 Sokomine joined #minetest-dev
19:37 sfan5 merging #15076, #15075, #15106 in 10m
19:37 ShadowBot https://github.com/minetest/minetest/issues/15076 -- [no squash] Ability to handle vertex and index VBOs separately by sfan5
19:37 ShadowBot https://github.com/minetest/minetest/issues/15075 -- Windows/vcpkg instructions: enable i18n by default by Zughy
19:37 ShadowBot https://github.com/minetest/minetest/issues/15106 -- Simplify `TOSERVER_INIT` and `TOCLIENT_HELLO` by red-001
20:03 Sharpman joined #minetest-dev
20:18 MTDiscord1 joined #minetest-dev
20:20 Evergreen joined #minetest-dev
20:20 Warr1024 joined #minetest-dev
20:21 red-001_ joined #minetest-dev
20:35 Desour joined #minetest-dev
20:46 Desour_ joined #minetest-dev
20:46 Desour joined #minetest-dev
20:51 Sharpman joined #minetest-dev
22:36 panwolfram joined #minetest-dev
23:05 Eragon joined #minetest-dev
23:05 MTDiscord <herowl> I pushed a new commit to #15062, hopefully this time explaining the behavior more clearly
23:05 ShadowBot https://github.com/minetest/minetest/issues/15062 -- Document negative saturation by nauta-turbidus

| Channels | #minetest-dev index | Today | | Google Search | Plaintext