Kuba Suder 🇵🇱🇺🇦
@mackuba.eu
Indie Mac/iOS & web developer • Currently building random fun things on ATProto using Ruby and occasionally JavaScript → https://blue.mackuba.eu
"mostly-happy-but-occasionally-grumpy Ruby guy" - Why
🌍 Kraków, Poland 🇵🇱🇪🇺 • ✝️
"mostly-happy-but-occasionally-grumpy Ruby guy" - Why
🌍 Kraków, Poland 🇵🇱🇪🇺 • ✝️
Reposted by Kuba Suder 🇵🇱🇺🇦
how much more explicit does it need to get that X is functionally equivalent to state power now?
bsky.app/profile/robi...
bsky.app/profile/robi...
As I was saying… www.politico.eu/article/us-s...
January 13, 2026 at 12:45 PM
how much more explicit does it need to get that X is functionally equivalent to state power now?
bsky.app/profile/robi...
bsky.app/profile/robi...
See the initial description here: bugs.ruby-lang.org/issues/21824
Bug #21824: performance regression in regexp matching after update to 4.0 - Ruby - Ruby Issue Tracking System
Redmine
bugs.ruby-lang.org
January 13, 2026 at 9:54 AM
See the initial description here: bugs.ruby-lang.org/issues/21824
And now thanks to me, the name "Slackware" will be embedded in the Ruby source code 🙃
![Chris Hasiński, 1 January 2026 at 15:12, 5de4cc5:
in regcomp.c:
if (e->len >= 3) {
reg->exact_end = reg->exact + e->len; (added line)
reg->optimize = (allow_reverse != 0
? ONIG_OPTIMIZE_EXACT_BM_IC : ONIG_OPTIMIZE_EXACT_BM_NOT_REV_IC);
}
else if (e->len > 0) { (removed line)
(added lines from here)
else {
/* Even if BM skip table can't be built (e.g., pattern starts with
's' or 'k' which have multi-byte case fold variants), we should
still use EXACT_IC optimization with the original pattern.
Without this fallback, patterns like /slackware/i have no
optimization at all, causing severe performance regression
especially with non-ASCII strings. See [Bug #21824] */
e->len = orig_len; /* Restore original length for EXACT_IC */
(end added lines)
reg->optimize = ONIG_OPTIMIZE_EXACT_IC;
}](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:oio4hkxaop4ao4wz2pp3f4cr/bafkreih6irc7fdna6s5lnqhbpiza6xwchrzj5v4nlf422taxmljvolyhc4@jpeg)
January 13, 2026 at 4:13 AM
And now thanks to me, the name "Slackware" will be embedded in the Ruby source code 🙃
If the token is not JWT, is there any way to tell if it's expired or not before just trying to use it?
January 13, 2026 at 4:04 AM
If the token is not JWT, is there any way to tell if it's expired or not before just trying to use it?
So here the access tokens are for 2h and refresh tokens for 3 months, and when you refresh (likely after those 2 hours) you get both replaced and the refresh token is again for 3 months from now, moved ahead. (IIRC in OAuth the refresh token has a permanent expiry time that isn't pushed ahead)
January 13, 2026 at 3:03 AM
So here the access tokens are for 2h and refresh tokens for 3 months, and when you refresh (likely after those 2 hours) you get both replaced and the refresh token is again for 3 months from now, moved ahead. (IIRC in OAuth the refresh token has a permanent expiry time that isn't pushed ahead)
Also, it's possible to decode the tokens from base64 and then from JSON, and look at the expiry timestamps there: (this is issue time + expiry time for AT & RT before and after refresh, notice that everything is offset by 40s in the second section)
![> sky.user.access_token.split('.')[1].then { |x| Base64.decode64(x) }.then { |x| JSON.parse(x) }.then { |x| puts "access token: from #{Time.at(x['iat'])} to #{Time.at(x['exp'])}" }
access token: from 2026-01-13 04:58:07 +0200 to 2026-01-13 06:58:07 +0200
> sky.user.refresh_token.split('.')[1].then { |x| Base64.decode64(x) }.then { |x| JSON.parse(x) }.then { |x| puts "refresh token: from #{Time.at(x['iat'])} to #{Time.at(x['exp'])}" }
refresh token: from 2026-01-13 04:58:07 +0200 to 2026-04-13 05:58:07 +0300
> sky.perform_token_refresh
> sky.user.access_token.split('.')[1].then { |x| Base64.decode64(x) }.then { |x| JSON.parse(x) }.then { |x| puts "access token: from #{Time.at(x['iat'])} to #{Time.at(x['exp'])}" }
access token: from 2026-01-13 04:58:47 +0200 to 2026-01-13 06:58:47 +0200
> sky.user.refresh_token.split('.')[1].then { |x| Base64.decode64(x) }.then { |x| JSON.parse(x) }.then { |x| puts "refresh token: from #{Time.at(x['iat'])} to #{Time.at(x['exp'])}" }
refresh token: from 2026-01-13 04:58:47 +0200 to 2026-04-13 05:58:47 +0300](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:oio4hkxaop4ao4wz2pp3f4cr/bafkreiab5qjgpfps7eqrbylyax6lg4vwkgbig5t63sx3vx5qaom2gq6cxu@jpeg)
January 13, 2026 at 3:01 AM
Also, it's possible to decode the tokens from base64 and then from JSON, and look at the expiry timestamps there: (this is issue time + expiry time for AT & RT before and after refresh, notice that everything is offset by 40s in the second section)
For app password, IIRC access token is 2h and refresh token is "very very long"
January 13, 2026 at 2:50 AM
For app password, IIRC access token is 2h and refresh token is "very very long"
I *think* this should be more or less that, unless it was updated again later: docs.bsky.app/blog/oauth-i...
OAuth Improvements | Bluesky
We've been making improvements to the end-user and developer experiences with atproto OAuth, and wanted to share some updates.
docs.bsky.app
January 13, 2026 at 2:48 AM
I *think* this should be more or less that, unless it was updated again later: docs.bsky.app/blog/oauth-i...
And it's the other way around, access token is short, refresh token is longer lived
January 13, 2026 at 2:46 AM
And it's the other way around, access token is short, refresh token is longer lived
I think the answer is very different for OAuth vs. app passwords, might be why you're seeing different answers
January 13, 2026 at 2:46 AM
I think the answer is very different for OAuth vs. app passwords, might be why you're seeing different answers
Why is it still negative??
January 13, 2026 at 1:02 AM
Why is it still negative??
Poor guy, what did he get himself into…
January 12, 2026 at 11:25 PM
Poor guy, what did he get himself into…
It could be painful tbh
January 12, 2026 at 10:44 PM
It could be painful tbh