search

fiatjaf / noscl

Command line client for Nostr.
Other
269 stars 53 forks source link

Discussion: how do we want to handle relay pooling? #40

Open honza opened 1 year ago

honza commented 1 year ago

The go-nostr library deprecated the RelayPool mechanism. We need to implement our own if we want to upgrade to newer versions of the library.

Do we have any thoughts on how to handle that?

fiatjaf commented 1 year ago

I think it depends on the use case you have in mind. I've removed the default RelayPool thing because it was encouraging one very specific naïve way of handling relays (connect to a static list of relays, send the same messages to all every time) that I think should not be used except at some cases. I think Nostr clients should be more flexible and more smart in the way they deal with relays.

I don't know what should be made of noscl. Is it being used for someone actually browsing their social feed and interacting with people? Or is it more like a developer debugging tool? Or what?

What do you think?

bndw commented 1 year ago

I personally use noscl as a developer debugging tool and I think there are many clients better suited for social.

Viewed through this lens, should publish take a flag to specify relays? From a quick scan that seems to be where the configured relays are used.

- noscl publish [--reference=<id>...] [--profile=<id>...] <content>
+ noscl publish [--reference=<id>...] [--relays=<urls>...] [--profile=<id>...] <content>
bndw commented 1 year ago

What if we add an optional --relay flag to publish?

# publish to all relays (current behavior, no change to UX)
noscl publish <content>

# publish to specific relay(s)
noscl publish --relay ws://localhost:9000
noscl publish --relay ws://localhost:9000 --relay wss://example.com

This would allow us to remove the dependency on github.com/fiatjaf/go-nostr v0.6.2 which is contributing to at least one other bug report.

fiatjaf commented 1 year ago

I think it may be time to revamp noscl entirely and make it a pure developer tool, with (optional) stdin inputs and always JSON outputs, probably, so they can be consumed by other tools.

And for having an actual "social" experience on the CLI https://github.com/mattn/algia is probably better (although I haven't tried it).

bndw commented 1 year ago

I think that's a great direction and am happy to help with the effort, as needed.