Time Nick Message 04:08 celeron55 the SSSCM api has to be enabled right away and slowly grown 04:08 celeron55 that's the only way it can work 04:08 celeron55 SSCSM* 04:09 celeron55 it could literally only support "hello world" at first 04:10 celeron55 and actual security reviews will have to be done 04:10 celeron55 it has to be compartmentalized in some such way that it can be dealt specially 12:07 hecks about sscsm, there is a small feature set which could be handled first that would be immensely useful 12:07 hecks and it would not be that difficult to secure 12:07 hecks a scriptable render loop 12:30 pgimeno [OT] hecks: you may be interested in this thread: https://love2d.org/forums/viewtopic.php?f=4&t=91198 12:31 hecks I've already explored everything there is to explore regarding GC lag in luajit 12:32 pgimeno this is a different case, it's not that much about GC lag as it is about too many traces 12:33 hecks yeah, you're not allowed to break traces; there's a dozen things that can cause this 12:33 pgimeno he doesn't 13:33 VanessaE [07-04 16:52] also c55 requires that connecting a server doesn't require any third party services 13:33 VanessaE while I'd agree in general, there IS a reasonable exception: a server admin might want to use some kind of 2FA for initial sign-ups, which could for example require the client to reach out to a website via CURL to fetch a code or something. 13:36 VanessaE redcrab had a thing back in his day that somehow sent you an email when you connected, which you had to reply to to get interact; these days that email might instead contain a one-time 2FA code the user has to type-in to the client, which it would match against the aforementioned fetched code. 13:37 rubenwardy that was a server-side mod 13:37 VanessaE yes 13:37 VanessaE point is, clicking a link in such an email would only take the noob to some website, rather than triggering the client 13:37 rubenwardy for initial signups like you mention there could be a link shown in a formspec that opens in a web browser 13:38 VanessaE that's a similar limitation 13:38 rubenwardy the website can be connected to the MT server and update the privs live 13:38 VanessaE clicking a link in an application outside of MT has no real chance of taking the user back *into* MT to proceed. 13:38 rubenwardy well you could use minetest:// links if those were added 13:39 rubenwardy Client-side support for 2FA is super specialist and a bit weird 13:39 VanessaE a minetest:// URI would perhaps be okay but you're still involving a web browser when something much simpler that stays entirely within MT (from the user's point of view) would do 13:40 VanessaE but 2FA was merely the first thing that came to minf 13:40 VanessaE mind* 13:40 rubenwardy Minetest accounts really aren't privileged to justify 2fa 13:40 rubenwardy email verification and password resets sure 13:40 VanessaE it's just an example 13:40 VanessaE don't read anything into it 13:41 rubenwardy I'd like some OAuth-like central account system as an alternative authentication method, it would use either auth tokens or certificates to not rely on the central service being online 13:42 VanessaE NOW THAT I can get behind 13:42 rubenwardy if it used auth tokens or certificates, then the central account system would only need to be online for when the user first logs into a new device 13:42 VanessaE when you run as many servers as I do, having a central account system would be nice, especially if it handles bans as well 13:42 rubenwardy well, for certs at least 13:43 rubenwardy dealing with cryptography is hard though, even with a library 13:43 VanessaE (I can only imagine how much of a pain in the ass it can be for that minetest server hosting guy, or Monte48's team) 13:44 VanessaE (by "handles bans" I mean only auto-synching bans between servers and then letting the servers handle them they way they usually do) 13:49 specing Well 13:50 specing it could support querying for bans and reasons for every connecting player 13:50 VanessaE the big question is, how would you establish identity in the first place though, without making it trivial for the user to "reset" or "clear" it? 13:50 specing then the local admin could decide whether to reject the player 13:53 rubenwardy you can't 13:53 rubenwardy unless you require submitting id cards, you can't establish identity 13:53 VanessaE nah 13:53 VanessaE I don't mean THAT degree of ID 13:53 rubenwardy you can require email addresses, but those are easy to get 13:53 VanessaE I mean simply ... "uniqueness" 13:54 VanessaE in a normal setup, server and client exchange certs that only establish "you and me" without knowing "you" == "a specific person out of 8 billion" 13:55 VanessaE but in a MT or other gaming setup I would imagine we'd at least want to localize "you" to "a specific computer" 13:55 rubenwardy certificates would be signed by the CAS to verify that the holder successfully logged into the account 13:55 VanessaE sure 13:55 rubenwardy a central auth system could do IP grouping (like xban and sban) across more data, although you wouldn't want to expose this to the users or servers 13:55 VanessaE but if the holder deletes that cert, how does the server know it's the same person when the auth system re-generates a new cert? 13:56 rubenwardy the certificate contains the username/CAS user id 13:56 rubenwardy To avoid exposing IP grouping, you would need to have CAS-level banning on server - where the server doesn't get any information unless they've banned that user, and they never get other IPs 13:56 rubenwardy this is fairly dodgy though and IP-based bans suck 13:56 VanessaE and if they delete the cert and use a new username and IP? 13:57 rubenwardy then it's a different user 13:57 VanessaE is it? 13:57 rubenwardy for all intents and purposes, yes 13:57 VanessaE this happens to xban from time to time, the same person signs in from two IPs and two usernames, 13:57 VanessaE e.g. VPN or something alike 13:58 VanessaE any centralized auth system (even if it's just central to a particular group of servers) has to defend against that 13:58 rubenwardy we could use MAC addresses or other hardware IDs to group users, but this is straying into a bad area 13:58 VanessaE well 13:58 VanessaE I thought about that actually... 13:58 rubenwardy there's no good way to defend against it without violating privacy 13:59 rubenwardy although, idk, I suppose mac addresses don't have the same flaws as IP addresses despite still being changable 13:59 VanessaE idk about Windows, but on Linux you can install `lshw`, which even if run as a non-priv user provides a lot of info. suppose you required installation of such a tool, hashed its output, and used that along with username and pw 14:00 VanessaE that would be a fairly strong proof of ID with zero privacy worries 14:00 rubenwardy an alternative to this would be to have more server-side protections (antispam, antigriefing) and moderators 14:01 VanessaE which is infeasible in a lot of situations 14:01 VanessaE sometimes there just aren't enough trustworthy people to go around 14:01 rubenwardy antispam is something that shouldn't be too hard but Minetest doesn't have much of 14:04 VanessaE true 14:05 specing > you can require email addresses, but those are easy to get 14:05 specing email addresses used by accounts being banned could end up on a blacklist 14:06 specing The same could be done with subnets for which a lot of ban reports start coming in 14:06 VanessaE link MT against spamassisssi... assisss.. assassis....... spam killer. (read this in the same way as the opening sequence in "Hot Shots: Part Deux") 14:07 VanessaE specing: *cough* protonmail *cough* 14:07 specing I think flux's (?) verbana does the subnet banning 14:07 specing well, not banning, but everyone new from those subnets comes in with interact/tp removed and is placed in jail 14:09 specing If e-mail verification is used, it could also delay sending the registration email 17:50 MTDiscord It sounds like you’re imagining a problem that has a chance of nearly never occurring 17:51 MTDiscord It’s extremely rare for one person to be that well organised 17:51 MTDiscord Even rarer in teams 18:13 v-rob /msg NickServ IDENTIFY v-rob rent-the-salad-today 18:13 v-rob Shoot, I can't believe I did that 18:15 v-rob hecks: "a scriptable render loop [for SSCSM]". How do you imagine this? I've been working on Lua interfaces for textures and will make interfaces for 3D rendering as well, but I don't know if what I think is similar to what you're thinking about. 18:15 hecks I imagine this as a single Lua chunk with no goto or loops allowed 18:15 hecks that only deals in opaque integer handles 18:16 hecks the point is to have a set of commands like: push/pop render target, push/pop camera, set rendering "context" (utility pass to use), draw scene with a given context or shader 18:16 hecks or draw a fullscreen quad with a given material 18:17 hecks actual resources that this uses may be specified remotely and don't need sscsm api 18:17 hecks the point is to generalize techniques like postprocessing or deferred rendering or shadow mapping into something that the game can override entirely - a completely scriptable render loop 18:18 rubenwardy v-rob: XKCD 4 word passwords only work if randomly generated 18:18 rubenwardy also if you don't paste them in a public chat 18:18 rubenwardy hm, I guess it's a nonsense sentence so could be random 18:18 v-rob I changed it already. I accidentally had a space before the slash. 18:19 rubenwardy common mistake 18:19 v-rob Still, I somewhat doubt people will try to steal my IRC password. It's not a lucrative position 18:20 v-rob Anyhow, I have #10801, but it's a higher level API and has no JIT-oriented performance things 18:21 hecks I imagine the scriptable render loop as its own completely isolated thing 18:21 MTDiscord That was still a pretty great password even if it wasn't really secure :-) 18:21 VanessaE besides why would anyone rent a salad? 18:21 rubenwardy sounds like a shader 18:21 hecks just a handful of functions, basically no keywords except if then else local end 18:22 v-rob So, what I do in the plain (SS)CSM Lua state won't have any bearing on what you want. 18:22 hecks it's not a shader, it's the rendering loop, simple as that 18:23 v-rob That's good, I don't want the stuff I'm working on be a potential limiting problem later on. 18:23 hecks I'll take a look at your api anyway 18:24 hecks cause I'm redoing materials right now and we might need to collab a bit 18:24 v-rob Certainly, especially for the 3D rendering PR. I don't want it to be a direct reflection of Irrlicht's API. 18:25 hecks you seem to have a Texture class for instance 18:25 hecks and at one point or another I might actually create a Texture class on the engine's side that isn't irrlicht's texture class 18:27 hecks but okay, in general this doesn't look like it collides with what I do at all 18:27 v-rob What particular advantages would this non_Irrlicht texture class have? 18:28 hecks not having to beg Irrlicht for the OpenGL texture handle, pretty much 18:28 hecks I've got this problem with meshes right now 18:28 v-rob Couldn't you just modify ITexture then? 18:28 hecks might have to punch quite a few holes in irrlicht to get all the raw handles on everything to make this work 18:28 hecks yeah, for now I'll settle for that 18:29 hecks the end goal is to keep chipping away at irrlicht dependency until nothing remains, right now I'll have to do it for shaders and actually for drawcalls as well 18:30 hecks but good news, this is an opportunity to do gpu skinning 18:30 hecks since GLES2 is the target, this will have to live in the vertex shader - but we can do it 18:30 hecks writing a linear blend skinner isn't a big deal anyhow 18:33 sfan5 what do we need the OpenGL texture handle for? 18:33 sfan5 to use it obviously but right now that goes back through irrlicht which then calls whatever gl method you would have called 18:34 hecks to set the texture uniform my friend 18:34 hecks when the material is being selected for rendering 18:40 hecks there is the option of just moving this code into irr but i don't like it for two reasons 18:40 hecks one is that it's contrary to the goal of getting rid of that thing 18:41 hecks two is that irrlicht is a different license; i'd rather keep this code some flavor of copyleft 18:43 sfan5 okay makes sense 18:44 hecks irrmt needs a better gitignore 18:48 sfan5 I believe you when you say Irrlicht sucks and it shouldn't be in the way of improving much needed parts but getting rid of every small bit of Irrlicht is such a mountainous task that's going to suck up lots of time for questionable benefit 18:49 sfan5 so I think the mid-term goal looks somehat like "move some rendering and GUI out of irrmt" and not "move everything out of irrmt" 18:49 sfan5 +w 18:50 hecks let's re-evaluate this then 18:50 hecks irrlicht is big but we use less than half of it 18:51 sfan5 maybe half of classes but not half of "parts" (whatever that may mean) 18:51 hecks irr has a ton of abstractions because it supports multiple (awful) renderers, but we just discarded those 18:51 hecks and for wrangling OpenGL, it's actually presenting us an API more poor than GL itself 18:52 sfan5 from the top of my head I see little value in rewriting these: OS API interactions for windowing and GL context setup, mesh/media file parsing, ZIP archiving stuff, primitives like vectors 18:52 hecks it provides us with a lot of asset formats, but we use only a handful of those 18:52 hecks it provides us with a skeletal mesh animator, but the most trivial one you could imagine 18:52 hecks and skinning, but it's also trivial linear blend skinning, and CPU only 18:53 hecks the parts that we sort of use, we can carve out and absorb 18:53 hecks like the .x loader which is actually so non-compliant with directx it's almost a fork 18:54 hecks (you can produce .x scenes that only work in irrlicht) 18:55 hecks it wrangles GL proc addresses for us, but there's better tools for this 18:55 hecks it provides events but it's so crappy at it that people are working to replace that too 18:55 hecks and finally a scene graph which is also painfully naive and we barely use it 18:56 hecks so in reality, irrlicht provides very few things of value that we can't just cut and paste into MT itself 18:57 sfan5 that is true 18:58 hecks deprecating non-GL paths and redoing shaders will already blow a huge chunk out of irr's reasons to exist 18:59 hecks and 18:59 hecks irrlicht is costing us a TON in maintenance that isn't noticeable on the surface 18:59 hecks the headers are pretty poorly made and possibly at least double the compile times 19:00 hecks we probably have a lot of questionably structured code just because of how irrlicht forces us to do things 19:00 hecks because we're an engine using an engine 19:02 sfan5 differently put: when you say "get rid of" it reads as "just let me rewrite this" to me, but there are parts where we don't want to do this 19:02 hecks be specific 19:03 sfan5 I gave examples above, just restating my point 19:03 hecks those are the parts i have no plans on touching 19:04 hecks except gl wrangling maybe, SDL would do this better 19:04 sfan5 sure 19:05 sfan5 just saying those parts exist 19:05 hecks but asset importers are fine (they can be a little untangled but they're good otherwise) 19:05 sfan5 so if we want to get rid of irrmt entirely there eventually needs to be consensus about what to do with the leftovers 19:05 hecks pull them down to MT itself 19:05 sfan5 importing a large chunk of foreign code feels bad 19:05 sfan5 but I have no better idea 19:05 hecks don't just blindly cut and paste of course 19:06 hecks but things like asset importers don't sound that hairy to rework to me 19:06 sfan5 you mean do code review on it like you'd do on fresh code? 19:06 hecks yes 19:07 hecks having it all in one repo would definitely help maintenance wise 19:07 sfan5 definitely 19:07 hecks one less thing to maintain, compile, port 19:10 hecks just chip away one feature at a time and we can do it 19:11 sfan5 gonna be a long process 19:11 hecks long in actual time, not in man hours 19:12 hecks but by 2023ish? it can be gone 19:12 sfan5 mt is notoriously short on man hours 19:12 hecks well, yeah 19:13 hecks i pretty much tricked myself into doing this 19:13 hecks would rather work on mibi 19:13 sfan5 you did 19:13 hecks https://paste.uguu.se/?c43265e2de5b4ab8#4fqNs8KYeHoZ5hGbgwBCcTsoGQvuP3kyMnUeRB5Prizz 19:14 hecks the other stuff I'm also doing, on a slow burn 19:14 hecks meshes, renderer, scene graph 19:16 hecks what makes this easier is that i've made an engine before and i can basically just port bits of it as needed 19:32 v-rob On the GUI remake: I'm considering a change of plans. I think it probably would be best to implement the core GUI classes in C++, not Lua, like I previously wanted to. Although I think Lua would be a much nicer choice for a lot of reasons, I think I essentially have to do it in C++, ultimately because of security issues and code that isn't and can't be exposed to Lua. So, yeah, I think I'll be moving what code I have to the C++ side and expose it to 19:32 v-rob Lua from there. 19:34 v-rob One direct advantage, however, is that I can design the SSM API first, and the much less important but fancier [SS]CSM API can be done later. 19:43 v-rob To clarify the security issues: mainly, this consists of functions that shouldn't be exposed to Lua that the GUI needs, and also things like the pause menu or other GUI globals being able to be overwritten, which can easily cause problems, especially if we got SSCSM. And a few other miscellaneous issues. 19:44 v-rob Anyhow, just wanted to let people know, even though it probably doesn't mean much to anyone. 20:33 pgimeno #10801 20:35 pgimeno https://github.com/minetest/minetest/pull/10801 -- Add CSM 2D Drawing API by v-rob 20:35 pgimeno #10801 20:36 pgimeno that's until ShadowBot is back (poking @ShadowNinja) 20:36 rubenwardy #10801 20:36 pgimeno https://github.com/minetest/minetest/pull/10801 -- Add CSM 2D Drawing API by v-rob 20:55 kilbith v-rob: https://github.com/minetest/minetest/pull/10265 why is still pending? 22:53 Pexin /3/2 23:03 specing wooo drawing in CSMs 23:04 specing v-rob: have you checked out SpringRTS's drawing API?