Replying to Avatar Cesar Dias

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

nostr:npub1cesrkrcuelkxyhvupzm48e8hwn4005w0ya5jyvf9kh75mfegqx0q4kt37c a few weeks back I threw this together as a exercise, It has some bugs with reconnecting and DOS the relay but I liked how the NIP-42 auth turned out and that I was able to write it in <200 lines

https://github.com/hzrd149/applesauce/blob/master/packages/relay/src/relay.ts

I'm not really part of this conversation and I'm distracted by other projects but I still really want to help build a pure rxjs relay connection library 😁

Reply to this note

Please Login to reply.

Discussion

I am don't have yet, gonna try to push something later today, I'm currently underwater with a unrelated refactor 😭

Me too, and getting deeper. I hate falling down these holes 😂

wow, this is looking really good, just found weird req returns "EOSE" | NostrEvent, If I want to listen for "EOSE" I would listen on subscribe({complete: () => {}}) or `finalize` operator, but might going to steal you waitForAuth, I am think I am gonna need it 🤣

REQ don't complete when they receive EOSE, its just a signal that the relay has sent all events but the subscription stays open for new events

Please steal the auth logic, that was the part I spent the most time on :)

Got it, then it makes sense for live subscriptions