Emelia Smith

I'm fairly certain this is because you haven't specified a port in the SMTP URL: ``` PDS_EMAIL_SMTP_URL=smtps://SMTPUSERNAME:[email protected]:SMTPPORT [email protected] ```

> Since specifying URLs will be deprecated in the future, I'm saying we should add the feature now. Where are you getting this from? No such deprecation has been made...

Currently this is only validated in the config loading for the PDS implementation: https://github.com/bluesky-social/atproto/blob/0c20539c7185f6070d4337dbda3da92c39a3434f/packages/pds/src/config/config.ts#L86 It should probably also be checked in the creation of the OAuthProvider.

@knotbin are you setting the application type to `native`? (it's the `application_type` property in the Client ID Metadata Document)

Actually, I think I know what it is: for private use, you only have a single slash apparently, so try `com.example.app:/` Found this via: https://github.com/bluesky-social/atproto/blob/main/packages/oauth/oauth-types/src/uri.ts#L197

The tests are being flaky here, but not because of my changes.

Just thinking on this, this doesn't change the PDS supporting JWTs, but does allow reusing the PDS code to build an entryway. The other way to go here would be...

I'd love to get this implemented, the blocker I saw initially was on DPoP for that flow. After a conversation with Aaron Parecki (on bluesky no less), he's written up...

@matthieusieben I'm not sure if this is a failure due to a dependency failing, or if it's a failure due to outdated snapshots? Looking at the code, it looks like...

I think the reason better-sqlite3 was failing was because `@atproto/pds` depended on `npm:@atproto/[email protected]` which in turn depended on `[email protected]` which does not support node.js 22, so perhaps by bumping that...