Time Nick Message 01:05 MTDiscord just going to mention https://github.com/luanti-org/luanti/pull/14964 here (sdl scancodes) since the idea was to get it merged early in 5.12 dev cycle and fix issues that crop up 09:53 ashtray Any reviews on https://github.com/luanti-org/luanti/pull/15870 would be welcome. 10:04 sfan5 i can make the necessary changes myself if that helps 10:07 ashtray My idea is to keep this PR simple - it is currently 3 lines - and address changes to server.cpp in a second PR. 10:08 ashtray I am not a big fan of MVP, but I do agree with merge-small and merge-often. 10:09 sfan5 the changes to server.cpp will be 3 lines 10:10 ashtray :-) 10:10 ashtray If you can write those changes in 3 lines, I am happy for you to do it. I was going to move the packet-generation code - it sounds like you have a better idea. 10:17 ashtray Ah, I see your comment on gh re: legacy_pkt - did not see that before. 10:18 ashtray Now I see how it can be done in 3 lines - give me a bit of time... 12:10 ashtray Hmm... looks like the bug is older than I knew ... 12:33 ashtray I do not have a 5.5.1 server to test against :-( 12:33 ashtray Bug-compatibility is hard ... 12:36 ashtray Hah! I have a 5.4 server with dynamic_add_media! I may yet be able to test this ... 12:47 sfan5 personally I wouldn't verify every combination 12:50 ashtray I have not been able to get a version with proto_ver < 40 to test on. 12:50 ashtray And 5.4 is too old too compile on my current machine. 12:51 ashtray It looks like the bug has been present for years, without anybody complaining about it. 12:52 ashtray Which is pushing me back towards "Keep It Simple, Stupid", and not fixing it in a protocol-version-aware way. 12:52 ashtray Make it a one-line fix in the client, all new clients with reasonably recent servers will work. 12:53 ashtray Old servers and clients will be no worse off. 15:15 Krock > static_cast(a.ephemeral) 15:16 Krock we're casting bool to bool for some reason 15:22 Krock also that proposed server.cpp fix takes more than 3 lines if we want to send the correct value to older clients. 1. one more copy of NetworkPacket, 2. another branch for clients older than [insert next proto version here] 15:26 Krock ashtray: https://pastebin.com/raw/pNzhXmiF 15:27 Krock 1. documentation update, 2. clarification of the variable name 15:35 sfan5 the idea is to make it work correctly on current/future server and future client; or future server and old client 15:35 sfan5 and not care about the other combinations 15:36 sfan5 this way we're not adding extra branches 15:39 sfan5 okay I missed the case "old server and future clients" 15:39 sfan5 perhaps it's easier described by saying: the client should learn to properly interpret the value that is sent right now; the server should learn to send the value correctly to very old clients 15:40 Krock where the nitpick is that very old clients aren't used that much any more, thus low benefit. 18:02 Krock Are zstd bombs possible? 18:03 Krock As in: a handcrafted binary blob that may cause system performance degradation due to insufficient RAM (--> swapping) 18:07 sfan5 sure 18:09 sfan5 even without manual optimization you can fit 16 GB of zeros in less than 640K of zstd 18:10 sfan5 the solution we have is to not take compressed data from the client 18:10 Krock at least that protects the server. Let's hope the owners do not pull dirty tricks on the clients. 18:11 Krock Limiting wouldn't work well either - packets could be spammed to re-send the same data. 18:22 MTDiscord There is no need to "protect" clients from DoS via servers, and I'm fairly certain that a server has plenty of ways to DoS a client if it is so inclined already 18:23 MTDiscord (for example even our most basic image formats support compression and I wouldn't be surprised if one of them can be made to blow up; and even if they don't there are still all kinds of funny things you can do with texture modifiers etc.) 18:24 MTDiscord But this is not a problem at all: Players will simply learn not to connect to such servers, should they crop up. Server owners stand to gain next to nothing from pulling a stunt like this. 18:25 MTDiscord As for limiting, I think it could certainly work if the right variable was limited, say, total size of decompressed data over a timeframe, rather than just limiting packet counts. 18:27 sfan5 should the need arise decompressZstd simply needs to have a limit parameter 18:40 MTDiscord i mean, server owners have totally never used bugs to crash certain clients/users they dont want 18:48 sfan5 does anyone know if people widely use remote_media? 18:48 sfan5 or do I need to try to go and check every public server? 18:55 [ And 5.4 is too old too compile on my current machine. 18:55 [ If you use guix, you could use guix time-machine (and if you don't, you could install it) 19:08 MTDiscord sfan5: give me a moment to run a cdb zipgrep 19:08 sfan5 that's a minetest.conf setting 19:08 MTDiscord yeah, sorry, mixed it up with dynamic media 19:08 sfan5 I guess I'll go with idea 2 19:09 MTDiscord idea: sofar might be able to give an answer for the access logs 19:09 MTDiscord *from 19:16 sfan5 another thing: i remember there being this remote server software which would collect the files and give you a http server? anyone has it handy? 19:17 Krock that rings a bell, but the bell is rusty and doesn't sound good any more 19:18 Krock I think s.o.f.a.r has/had a remote media server years ago 19:19 sfan5 https://github.com/minetest-tools/mtmediasrv/ I suppose 19:20 MTDiscord https://minetestmedia.foo-projects.org for the hosted version 20:30 sfan5 the preliminary result is that less than 10% of servers use remote_media 20:30 lhofhansl Hi all... Merging #15878 in a few 20:30 ShadowBot https://github.com/luanti-org/luanti/issues/15878 -- Client: Avoid touching all blocks in range every 0.2s by lhofhansl 20:50 MTDiscord sfan5: Regarding a remote media server ... should we use such a thing? Is that how MT should be used and current servers only use the simple/lazy variant? 20:53 sfan5 only thing it would do is speed up media loading for first-timers 20:53 sfan5 by how much I don't know 21:06 sofar my remote media server is still running and widely used, I can produce usage logs 21:10 sofar here's some stats: 21:10 sofar averaging about 1gb of data daily (very much the same as it has been for a long time afaicr) 21:11 sofar still gets 1000+ hits on index.mth which is the old api :) 21:12 MTDiscord sfan: edited in source link to your pr 21:12 sofar 53% ios, 28% linux, 22% android, rest other 21:13 sofar 20 servers are referring to the media server with the correct referrer fiel set 21:14 sofar there's about 1100 unique visitors in the last 7 days 21:14 sfan5 how many unique media files do you have? 21:15 sofar 138313 21:15 sofar 3.5G total size 21:16 sofar you can see the list of included mods from https://media.foo-projects.org/remotes 21:16 sofar 7597 repos currently 21:16 Krock SSL_ERROR_BAD_CERT_DOMAIN 21:16 sofar huh, weird 21:17 Krock Firefox allows me to ignore that, though. 21:17 sofar oh it's minetestmedia.foo-projects.org apparently 21:17 sofar that's... how did that happen 21:17 Krock a few of 10+1' repository URLs need an update for codeberg :3 21:18 MTDiscord cron job that pulls git repo urls nightly from cdb api perhaps 21:19 sofar yes, it's a cron job job, no idea if it scrubs dead ones 21:19 sofar ExecStart=/var/minetest/media/cdbfetch.py 21:19 sofar I cna post if people are interested 21:21 sofar new mod release: -SX--qos 29362 21:21 sofar well that breaks it, lol 21:21 sofar someone nuke that from cdb so I don't need to fix my script 21:24 sofar actually it looks like the author name is unexpected for that mod 21:24 sofar yeah, username is '-sx-' arg 22:22 sfan5 results posted in #15885 22:22 ShadowBot https://github.com/luanti-org/luanti/issues/15885 -- Make remote media exclusively use GET for hash set by sfan5 22:26 MTDiscord re above @Luanzai > it even seems to be an unique codebase not sure if you have made it open? or are just using someone elses? 22:29 MTDiscord > this user fell victim to not reading our non-existent documentation and his remote media doesn't actually work ๐Ÿ˜ฆ https://docs.luanti.org/for-server-hosts/remote-media/ does exist 22:29 sfan5 if I haven't heard of it, does it exist? 22:31 MTDiscord if a tree falls in the forest, and no one is around to hear it fall, did it really fall? key words are no one, not sfan5 :juanchi_face: 22:32 sfan5 I sorta expected some documentation in the engine repo but I guess this is more wiki territory 22:32 MTDiscord to be completely fair, i expected far worse than the doc actually is. probably still has room for improvement. prs welcome since your now the expert at it ๐Ÿ˜› 22:55 MTDiscord for what it's worth i did also write a remote media server in java because i had too much time on my hands back then: http://github.com/appgurueu/minetest-remote-media-server-java-edition 22:56 MTDiscord re so-far's stats, probably the multicrafters are using remote media a lot? 22:58 sfan5 not on servers on the list at least 22:58 sfan5 raw list https://0x0.st/8u0W.txt 22:59 sfan5 okay there's a few missing due to invalid password 22:59 sfan5 but still 23:10 sofar https://github.com/minetest-tools/mtmediasrv/ my code is here fwiw 23:12 sofar I'd have to recode it in case it no longer POSTs 23:44 rubenwardy !title https://github.com/luanti-org/contentdb/pull/578 23:45 rubenwardy ~title 23:45 ShadowBot Add terms of service to comply with Online Safety Act 2023 by rubenwardy ยท Pull Request #578 ยท luanti-org/contentdb ยท GitHub 23:45 MTDiscord probably should throw in a redirect for the old url? 23:45 rubenwardy I was planning to do that with nginx 23:46 MTDiscord ah ๐Ÿ‘