Hi, on v26.04+dev.ecd3a2b7 my login is stuck at the passcode step. After several wrong attempts I hit ErrJuiceboxLocked ("Too many incorrect passcode attempts. X Chat is locked."). I went into X mobile and did "Reset chat encryption", which destroyed my encrypted DM history. X mobile accepted my new passcode and let me back into Chat normally, but the bridge still gets GuessesRemaining=0 from the realms with the same fresh passcode. Drove the login through the provisioning API to be sure (cookies step always succeeds, PIN step always 403s). Also tested through a residential SOCKS5 proxy, same result, so it is not IP-based.
One thing that might help: the JWT sub returned by GetPublicKeys was identical across every single attempt and had the form <user_id>:<13_digit_ms_timestamp> where the second component never rotated, including before and after the reset. If a successful Register is supposed to rotate that, then the X mobile "Reset chat encryption" flow might not actually be hitting Register, even though it wiped my chats locally.
ERR Failed to submit input error="Too many incorrect passcode attempts. X Chat is locked." component=provisioning
DBG Received software realm response response_len=20 status_code=200
DBG Received hardware realm response response_len=624 status_code=200
DBG Received hardware realm response response_len=624 status_code=200
Hi, on
v26.04+dev.ecd3a2b7my login is stuck at the passcode step. After several wrong attempts I hitErrJuiceboxLocked("Too many incorrect passcode attempts. X Chat is locked."). I went into X mobile and did "Reset chat encryption", which destroyed my encrypted DM history. X mobile accepted my new passcode and let me back into Chat normally, but the bridge still getsGuessesRemaining=0from the realms with the same fresh passcode. Drove the login through the provisioning API to be sure (cookies step always succeeds, PIN step always 403s). Also tested through a residential SOCKS5 proxy, same result, so it is not IP-based.One thing that might help: the JWT
subreturned byGetPublicKeyswas identical across every single attempt and had the form<user_id>:<13_digit_ms_timestamp>where the second component never rotated, including before and after the reset. If a successfulRegisteris supposed to rotate that, then the X mobile "Reset chat encryption" flow might not actually be hittingRegister, even though it wiped my chats locally.