Replying to Avatar unclebobmartin

Why would I trust that a relay would hold kind:0 indefinitely? I don't think that's a requirement. Moreover, relay X may have started long after any kind:0 for user xyz was sent, so it may never have that kind:0 for user xyz.

Is it more private to use a kind filter? I don't see why. If the data is available, it's available.

Is it more efficient to use a kind filter? I suppose, but the traffic of metadata messages on the network doesn't seem particularly burdensome compared to the event traffic.

The more-speech use-case is apparently quite a bit different from some other clients. Some clients treat nostr as a kind of twitter replacement. But more-speech uses nostr more as a news channel; a place for longer articles and prolonged threaded discussions.

As such, more-speech does not use the REQ filters to follow users. Rather more-speech gathers every message on the network, and then allows the user to pick and choose which users and topics they wish to follow by separating them into various tabs on the screen.

So, if I want to see all the 'bestofhn' stuff, I can go to that tab. If I want to see 'RobosatsOrderbo' I can go to that tab. Indeed, I have a tab set up for this particular discussion.

>From: Giszmo47 at 07/29/22 09:58:43 on wss://nostr-relay.wlvs.space

>---------------

>For that you use a kind filter. Get all replaceable events without a "since" and all other content "since" last connection loss - 1day or so. Other clients do it that way and it's certainly more efficient and private.

Your posts are too long. I'd like to reply to one argument at a time ...

Reply to this note

Please Login to reply.

Discussion

As I said, we appear to have very different use-cases for nostr. I like long messages. Nostr is not necessarily a short-message protocol.

>From: Giszmo47 at 07/29/22 10:45:40 on wss://nostr-relay.wlvs.space

>---------------

>Your posts are too long. I'd like to reply to one argument at a time ...

agreed! just because damus optimizes for twitter workflows doesn't mean other clients need to do the same for kind1

>From: unclebobmartin at 07/29/22 11:16:57 on wss://nostr-pub.wellorder.net

>---------------

> As I said, we appear to have very different use-cases for nostr. I like long messages. Nostr is not necessarily a short-message protocol.

long messages for the win. I love the idea of nostr as a viable replacement for RSS feeds. one can imagine kind 1 messages with markdown formatted articles, with the kind 0 message pointing to formatting, a message kind for enclosures to support podcasts, etc. but it doesn't need to be shoe-horned into the RSS mold, that's just the closest functioning analog, and an obvious crossover point. @fiatjaf has rsslayer in this space, which does RSS->nostr. I've roughed in some code that does nostr->RSS. but in the long run, I'd much rather receive new reading content/notifications and podcast updates via nostr.