| Time |
Nick |
Message |
| 01:05 |
MTDiscord |
<wsor4035> 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 |
| 01:21 |
|
hwpplayer1 joined #luanti-dev |
| 01:21 |
|
SFENCE joined #luanti-dev |
| 02:09 |
|
hwpplayer1 joined #luanti-dev |
| 02:13 |
|
SFENCE joined #luanti-dev |
| 02:47 |
|
SFENCE joined #luanti-dev |
| 03:00 |
|
SFENCE_arch joined #luanti-dev |
| 03:04 |
|
SFENCE joined #luanti-dev |
| 03:34 |
|
hwpplayer1 joined #luanti-dev |
| 03:41 |
|
SFENCE joined #luanti-dev |
| 04:48 |
|
SFENCE joined #luanti-dev |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 05:38 |
|
SFENCE joined #luanti-dev |
| 07:08 |
|
fluxionary joined #luanti-dev |
| 09:08 |
|
fluxionary joined #luanti-dev |
| 09:40 |
|
ashtray joined #luanti-dev |
| 09:48 |
|
ashtray joined #luanti-dev |
| 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:22 |
|
cx384 joined #luanti-dev |
| 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<bool>(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. |
| 15:42 |
|
Fleckenstein joined #luanti-dev |
| 15:48 |
|
Fleckenstein joined #luanti-dev |
| 17:06 |
|
TheCoffeMaker joined #luanti-dev |
| 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 |
<luatic> 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 |
<luatic> (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 |
<luatic> 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 |
<luatic> 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 |
<wsor4035> i mean, server owners have totally never used bugs to crash certain clients/users they dont want |
| 18:41 |
|
Desour joined #luanti-dev |
| 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 |
[ |
<ashtray> 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 |
<wsor4035> sfan5: give me a moment to run a cdb zipgrep |
| 19:08 |
sfan5 |
that's a minetest.conf setting |
| 19:08 |
MTDiscord |
<wsor4035> yeah, sorry, mixed it up with dynamic media |
| 19:08 |
sfan5 |
I guess I'll go with idea 2 |
| 19:09 |
MTDiscord |
<wsor4035> idea: sofar might be able to give an answer for the access logs |
| 19:09 |
MTDiscord |
<wsor4035> *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 |
<wsor4035> https://minetestmedia.foo-projects.org for the hosted version |
| 20:29 |
|
lhofhansl joined #luanti-dev |
| 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 |
<bastrabun> 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 |
<wsor4035> 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 |
<wsor4035> 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 |
<wsor4035> 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 |
<wsor4035> > 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 |
<wsor4035> 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 |
<wsor4035> 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 |
<luatic> 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 |
<luatic> 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:34 |
|
panwolfram joined #luanti-dev |
| 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 |
<wsor4035> probably should throw in a redirect for the old url? |
| 23:45 |
rubenwardy |
I was planning to do that with nginx |
| 23:46 |
MTDiscord |
<wsor4035> ah 👍 |
