Yes, relayFilters stream approach was something that I came up with the outbox in mind, it's been very useful and easy to split filters of a single subscription, I also designed in a way to work batching multiple unrelated subscriptions together, everything becomes a queue at the end consumed by the start() operators, this approach has been working really well for me and haven't touch much in a while.

rx-nostr is indeed too tightly coupled and when I started my mind was mainly focus on the batcher.

The way I been designing things is the core the be completely stateless and lazy, you can create a subscription and the core will never initiate any subscription for you, just like rxjs itself wouldn't, it just gives you the building blocks.

Working with websocketSubjects has been very easy and flexible, I can even push messages before the websocket was connected and the subject will buffer after connected.

webSocketSubjects just like the other subjects are multicasted.

this will only open 1 connection no matter how many subscriptions you have

```ts

const relay = webSocketSubject('wss://relay1.com')

relay.subscribe()

relay.subscribe()

```

now creating multiple webSocketSubjects it will open multiple connections.

webSocketSubjects multiplex will make a unicast subscription, this will make multiple nostr subscriptions in the same connection.

```ts

const relay = webSocketSubject('wss://relay1.com')

const sub = relay.multiplex(() => ["REQ", , ], () => ['CLOSE', ], (msg) => msg msg[1] === )

sub.subscribe()

sub.subscribe()

```

You can pass the webSocketSubject as you wish as it's also a observable, I store relays as webSocketSubjects in a Map in the Pool which doesn't do anything special, just blacklist relays with errors so it doesn't try to connect again.

Current my core/pool is doing the relay subscription which is incorrect, the consumer should be responsible to initiate the relay connection because he could put any policy mechanism for a particular relay, something like a rxjs retry to reconnect or some auth policy, currently my pool exposes a open callback and we could do something like this (pseudo code)

I am still working on auth and trying to think about some flexible way to do it, I'm a little bit hesitant to replay old messages after a a successful auth as I need to store these messages somewhere, but here's a small authenticator (which I think I should rename to createAuthPolicy or something) what takes a pool, a signer a options like whitelist which is an observable as the user can whitelist a observable after the auth was received.

Still half backed as I am still testing locally