liek i said... server (remote) initiated... connection started by local, message sent by remote... this is a subscription

there would be no need for the confusing EOSE if you just cut the protocol in two and socket for subscription, starting now (after eose) and query, for up to now

queries use a different algorithm, they ask the database, where subscriptions are when the server receives messages and they are to be propagated to subscribers

this is one of the dumbest things about the nostr protocol, using sockets to do queries and then assuming that the client wants to subscribe when usually they don't, and often aren't even listening for them, but they hold the socket open anyway

Reply to this note

Please Login to reply.

Discussion

I just implemented what I needed for Step 1a and 4a in the interaction diagram. The rest is good ole https gets and posts.

https://github.com/trbouma/safebox/blob/nauth-refactor/docs/NAUTH-PROTOCOL.md

Interesting. I caught up on this thread because I was the person who pointed Tim towards Websockets / SSE for his ongoing projects. I also believe in only using the most basic tool for the job, but do you think that it's less complex for clients to make one query, wait until it's resolved and then make another?

I think that EOSE is a fairly useful tool to combine those two requests into one, and any half-decent implementation can send a CLOSE after that point if they aren't interested in subscribing.

Yes, I am very grateful for the tip, and it has paid back in dividends. I use it only very sparingly.

the problem isn't whether it's technically possible

it's that mashing together a request/response model with a subscribe model is just bad and confusing for the HUMAN developers

I can do whatever I want.

you can reap the harvest from the seeds you sow, indeed