definitely not single handedly but I'm not goign to pretend they aren't helping quite a bit. All the foss parts mostly existed before valve got involved
If I'm understanding correctly, they are storing the last password change timestamp in the db: local_user.validator_time and then when they fetch the logged-in user details for a request they compare the timestamp of the token to that validator_time and reject the jwt if it's greater.
I don't think lemmy is using jwt because they really needed the low overhead, most of these requests need to hit the db regardless, they are (IMO) just using it because it was simple to use initially.
This does make me wonder if there are some API requests which don't call check_validator_time() and would still be usable after a pw change
after years and years of microsoft being awful I finally got a few of my techy gamer friends onto linux in the past ~3 years, and they're running with it!
The EU countries investing in FOSS may also make a dent
The websocket thing is going away when we update to the latest version (soon, I think the rebase is already done). you can look at basically any federated lemmy instance if you want to see what the network traffic looks like for the HTTP API, its pretty straightforward iirc, and there is some documentation, though it leaves a lot to be desired lol
What I mean about the cookie is that they are (or were? haven't checked recently) literally encoding it into the URL iirc, like instead of just sending the cookie along in the headers or putting it in the request body somewhere the URL would be /api/v3/endpoint?auth=<your-JWT-here>
And then some error pages would have the URL in the error message, so you had users posting their whole tokens when they asked for support Not sure if that's fixed or not
These are really funny, and maybe we've already had this struggle session, but can we not call people glowies? You know its short for "glow n-words" right?
I tested it on hexbear, it does seem to get invalidated on password change. I saw the relevant GitHub commit last night but I didn't read into the exact implementation. They might somehow be adding in a password hash to the mix? Or maintaining a blocklist of invalidated jwts but that would be ugly
But yeah. I kinda get why JWTs are like that now, but Lemmy isn't a massively distributed system and the tokens are valid for a nearly indefinite period lol. And baked into request URLs
It seems like by the time you implement all the shit people are suggesting in the GitHub you've completely defeated any simplicity JWTs once had and would be better off just tracking it all in the db
it's a site you go to instead of google, or youtube, or twitter, that serves you the same results you'd see as a logged out user on one of those sites, but without that platform being able to track you, fingerprint your browser, know your IP, etc
another note: there have been 13 mod enforcement actions on the site in the past 24 hours. I think our 16 admins and god knows how many more comm mods can handle that load
That really isn't my point though, I'm advocating a different system, not just doing the current process sooner. The problem isn't "nothing ever gets approved" it's that sillier and more niche things collectively still add value to the site, and that the whole process of getting a comm added is unnecessarily long and demoralizing, and feels arbitrary, when most other sites using lemmy are just open to comm creation.
Even if we don't open it up wide open, can't we have some kind of more standardized, expedited process to get a new comm opened? For example the process could be something like: make a post in commrequest with the proposed sub name, any additional rules, and a list of moderators. people tagged in the moderators list chime in in the comments saying "yes I'll mod this comm" or "no wtf you didn't ask me about this", and within a couple days the admins review the request, make sure there are enough moderators (say a minimum of 2 or 3), make sure the proposed content is allowed/appropriate, and then create it. There's still room for admin discretion there, but it is a faster yes or no answer, and much more standardized, so it doesn't arbitrary
Rather than having "moderator of some random comm" be treated like a highly important and trusted position, it could be more proportional to the size of the comm. Or even if the mod process is kept entirely intact, just formalizing and speeding up the approvals process (and IMO, being less strict about comms that may have some overlap), would make the whole process much less frustrating and get more comms approved.
basically I'm of the opinion that allowing more people to become mods of more smaller comms encourages people to take some ownership over their posting, and become power users and makes the site richer for everyone.
Edit: it's also unfortunate that commrequest isn't in the default subscribed list. Many users may not even see proposed new comms. Idk how many people browse by subscribed tbf
like, why can we have https://hexbear.net/c/chapotraphouse3 right away, but c/mycology needs to hurry up and wait? I'm all for having both, but it seems pretty arbitrary.
I know we have particularly nasty wreckers at times, and that now may be a pretty quiet time, but the entire site has had 13 mod enforcement actions in the past day. Unless new comms somehow bring in tons of new users overnight I think we can handle the moderation load.
s
Glad I piped up then
Not sure if that's fixed or not
Aye that sounds like a big improvement, and tho I still feel like open creation could be cool, there are plenty of other places for that.
definitely not single handedly but I'm not goign to pretend they aren't helping quite a bit. All the foss parts mostly existed before valve got involved