Some of the APIs were not designed as well as they should have been. We’re redesigning and refining them with v1.0 in mind (no ETA yet)

I just took a quick look, and I think the problem is that the relays being added with NONE capabilites. This means they can't do anything (neither read nor write).

Unless you want to use specific capabilities, you can omit that argument in addRelay, so they will be added with the default capabilities (READ + WRITE).

Have you a small example to reproduce it?

I've already adapted FFI APIs but not released anything yet. There are still a some things to rework before the next release.

I think if you fork the repo, you should be able to run the workflow for building them by yourself:

Fork the repo -> Go to "Actions" -> Select the "Publish" workflow -> Click on "Run workflow" -> Select the commit to use, deselect everything except "Build KMP" (the "Swift package version" can be empty) and DON'T select "Publish" -> Run it and you'll find the AAR in the artifacts (called nostr-sdk-ffi-kmp-aar).

Compilation can be done also locally, but unfortunately requires macos as it needs binaries also for iOS, and I didn't found a way to cross-compile them from Linux.

https://github.com/rust-nostr/nostr-sdk-ffi/commit/72c07c61b460c701dcfc93d51bc83e4a1c5eb689

I've published a NIP-17 event with the key in the nostrsdk-debug repo, and now REQ receives that event from auth.nostr1.com

So there were probably no events published for that key on that relay

I've checked this but I can't reproduce the issue. I've tried both the auto-auth implementation and the manual one, and both successfully send the REQ after the AUTH and receive the EOSE.

To debug the messages that the client send, you have to enable the debug level: "RUST_LOG=debug cargo run"

You must enable the "env-filter" feature for the tracing-subscriber dependency, to be able use RUST_LOG

The URL in the AdmitPolicy is to let you know from with relay the AUTH request is coming.
You don't have to add it, it's added by the SDK.

Done at https://github.com/rust-nostr/nostr/commit/07de813024f930803a1dd81942edb50eb8a87ba3

Thanks, I'll check it, but I think that it's due to an unreachable relay that has just been added to the pool.
The disconnected relays are skipped (return error instead of waiting) after the second failed attempt.

To confirm it, can you try to decrease the connection timeout, configurable via the Client Builder? (I've added this feature yesterday in master branch).
Or, have you a small code snippet to reproduce it? And what relays did you used?

Regarding the issues, are perfect here on nostr.
But instead of using the text notes, the NIP34 would be better. Here is the repo: https://gitworkshop.dev/yukikishimoto.com/nostr

For desktop you can use gitplaza, by @dluvian

https://codeberg.org/dluvian/gitplaza

Does this happen with the in-memory gossip store, or with the SQLite one? Or both?

Yes, I've starter working on it a couple of days ago. The PR: https://github.com/rust-nostr/nostr/pull/1252

I'm working on making all the libraries runtime-agnostic. Hope to have a PR ready soon.