Ahh ok. I'll think about that. But it's pretty easy to write a blocking wrapper, including only the stuff you need. This could be a solution for your above request:
```toml
[dependencies]
nostr-sdk = "0.36"
tokio = { version = "1.41", features = ["full"] }
```
```rust
use std::sync::LazyLock;
use nostr_sdk::prelude::*;
use tokio::runtime::Runtime;
static RUNTIME: LazyLock
pub struct ClientBlocking {
inner: Client,
}
impl ClientBlocking {
pub fn add_relay(&self, url: &str) -> Result
RUNTIME.block_on(async {
Ok(self.inner.add_relay(url).await?)
})
}
pub fn connect(&self) {
RUNTIME.block_on(async {
self.inner.connect().await
})
}
pub fn send_event(&self, event: Event) -> Result
RUNTIME.block_on(async {
Ok(self.inner.send_event(event).await?)
})
}
pub fn subscribe(&self, filters: Vec
RUNTIME.block_on(async {
Ok(self.inner.subscribe(filters, None).await?)
})
}
pub fn handle_notifications
where
F: Fn(RelayPoolNotification) -> Result
{
let mut notifications = self.inner.notifications();
while let Ok(notification) = RUNTIME.block_on(notifications.recv()) {
let shutdown: bool = RelayPoolNotification::Shutdown == notification;
let exit: bool = func(notification)?;
if exit || shutdown {
break;
}
}
Ok(())
}
}
```
Do you mean for Kotlin? I would say yes, but this will bring back the maintainability "issues" on my side.
If you need just a basic blocking client I could help to write and integrate it in your project, but you'll have to maintain it by yourself. It can be extended/adjusted depending on your project needs.
Just to know, are there problems with async version in kotlin? Do it increase code complexity?
## rust-nostr v0.36 is out! 🦀
### Summary
Many, many improvements to `Relay` and `RelayPool` performance (reduced atomic operations and switched to async concurrency), add `NostrSigner` trait, better methods and struct names (`fetch_events` instead of `get_events_of`, `sync` instead of `reconcile`, `NostrConnect` instead of `Nip46Signer` and so on), add `LocalRelay` and allow to easily serve it as hidden onion service with the embedded tor client, allow to keep track of negentropy sync progress, almost halved the weight of JavaScript SDK bindings (from ~6.3MB to ~3.6MB), new experimental Flutter package, some fixes and many more!
Note for Python, Kotlin, Swift and JavaScript devs: unfortunately I can't mark things as deprecated in bindings, so this release have many breaking changes, sorry :(
Note for devs who are using `nostr-protocol` (Python), `org.rust-nostr:nostr` (Kotlin), `nostr-swift` (Swift) or `@rust-nostr/nostr` (JavaScript) libraries: these packages are now deprecated. Only the `nostr-sdk` library will be released, which include everything that was in those libraries.
Full changelog: https://rust-nostr.org/changelog
### Contributors
Thanks to all contributors!
* nostr:npub1zwnx29tj2lnem8wvjcx7avm8l4unswlz6zatk0vxzeu62uqagcash7fhrf
* nostr:npub1w80jzxf36fhwgyfp622m6s7tcl3cy5z7xva4cy75q9kwm92zm8tsclzqjv
* nostr:npub17q5n2z8naw0xl6vu9lvt560lg33pdpe29k0k09umlfxm3vc4tqrq466f2y
### Links
#rustnostr #nostr #rustlang #programming #rust #python #javascript #kotlin #swift #flutter
Fixed at 7587fba8ee72041689aa46c1436ecfa73d75d381
Please also check part 2 of the last upgrade, might be easier to read and add some clarifications: https://github.com/nostr-protocol/nips/pull/1553
Thanks!
Found the issue, tomorrow I'll push the fix.
No, my bad. The subscription can fail only if relay not support read operations, if the filter is empty or for timeout. In the log what do you see when it fail and return `not subscribed`?
The `not subscribed` error is returned when subscription fails with all relays. What relays are you using? Maybe is related to NIP42 auth
Thanks, I'll investigate.
In new version (for now in master branch) `NostrSigner::public_key` return the user public key.
In the last release depends by the signer, but during my tests I saw that the same key is used (so the signer key match the user one), at least in amber and nsec.app.
In last version is called `Nip46Signer`. In the next one will be renamed to `NostrConnect`.
Hahah, it was already available, I was just testing it again for some adjustment. I accidentally used my account for test 😂
Testing rust-nostr NIP46 signer [connect]
According to new NIP-46 clarifications, the remote signer public key could be different from the user public key. So I have to adjust it again. This means that if you'll call `NostrSigner::public_key` method with a NIP46 signer, it will block until the signer reply or the timeout is reached. After the first call is executed correctly, the pk is cached.
In general the AUTH requests are handled in another thread, so will not block the main one.
It's sent a `sign_event` request to the signer.
Try this commit: ede2a91ef7d3738b36a03243697fbd20efd335a1
I'm using it here:
https://github.com/DanConwayDev/ngit-cli/blob/4f84dc460c3494286233afe9ca480d3b7c0186b1/src/lib/login/mod.rs#L294 (main branch)
https://github.com/DanConwayDev/ngit-cli/blob/e60a419510696e3fa25a35be6cba35e547b53e24/src/lib/login/mod.rs#L293 (testing-auth-with-patched-signer branch)
The main branch doesn't block when attempting to login but the patched signer branch does.
I would prefer it if it only sent a request to the signer when it has been explicitly called to sign an event. If an AUTH request is received it should attempt to sign it but do this async in the background and not block. What do you think?
Ok, maybe I found the issue. The connection with signer is already initialized on demand. But, the bootstrap is executed when `signer_public_key` method is called... I saw that in your code you are calling the `NostrSigner::public_key` method, that internally call the `signer_public_key` method. For this reason it block.
I'll rework it
nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet, I'm reopening this because whilst `Nip46Signer::new` is not blocking, `NostrSigner::nip46` is. When a nip46 signer is not connected (or not automatically responding) the utility will hang until the signer is connected. this is true of `4dbfa94` but I'm not sure if you have tweaked it since.
The `NostrSigner::nip46` internally only construct the `NostrSigner` enumeration.
At a certain point the `Nip46Signer` have to wait for a response from the signer. Can you point me where you use it in the code?
