Some approaches were discussed somewhere in the NIPs repo, but as far as I remember they would put too much unnecessary burden on relays. We should standardize kind-6 with stringified ugliness now and hopefully in the future we can come up with new ideas to make it obsolete.

I do think the "e" tag must still be included in any case, and with the relay hint too if possible.

I think just asking a relay for everything they have and expecting the relay to provide you with interesting stuff is a space with multiple design possibilities and very worth of exploring. Relays have to be restricted in some way for this to happen. Or they can be aggregators of other relays. In any case it must be done. And (some) clients must favor that kind of exploratory relay browsing in their UX.

I would like the Nostr Report to exist outside of Nostr, so that people on the outside can see that things are happening here and jump in.

This was the best solution I could think of: https://github.com/nostr-protocol/nips/pull/158

Hello:

But to your point, that's a nice name. I am not sure it makes sense to translate the name of Nostr, but you can try. Would fit better as the name of another client, though.

Nostr is meant for things that you _want_ others to see.

This was the best solution I could think of: https://github.com/nostr-protocol/nips/pull/158

No, but we need these things ASAP to incentize decentralization and better client behavior. Do you volunteer? How would you ensure that the content would fit the relay requirements?

Please send the event reference with a parsed structured tag instead of the note1... as a string, otherwise I can't browse to it.

I don't like the Damus-style kind-6 with stringified event JSON in the contents, but I accept it. I'll take that over this aberration. Someone must write a NIP to document it, please. Who volunteers?

I meant to say "# [ 0 ]" for all you magic parsers out there. Do you know, #[0] #[3] #[2] #[1]?

Who is making these kind-6 events with content set to "#[0]"? Please.

(In my defense I did have in mind that these relays would become more personalized and more an integral part of the experience as time went on, I just didn't know how to do it at the time and it wouldn't make sense since there were no relays or users. Again in my defense I also think that pattern was kinda "obvious" and if I hadn't done it others would do it anyway since it "fits" the basic patterns that most non-nostr apps use today.)

I think the model of the client that tries to follow someone automatically is not incompatible at all with the model of the client that allows you to switch relays view and puts relays at the forefront of the experience. They are very compatible and the synergy between the two models can create interesting experiences. I wouldn't be unhealthy for some clients to specialize in one model of browsing while others specialize on the other, but a mix would be desirable too.

Also the algorithmic follow-by-heuristics method may work on Twitter-like experiences, but for most of other use cases that can be done with Nostr the browse-relays experience seems to fit much better.

Anyway, the only thing I think is terribly unhealthy is the current ubiquitous model of a "settings" page with a list of boring and meaningless relay URLs and people selecting these once (if at all) and never thinking about them again. This is horrible, centralizating, unscalable, a terrible anti-pattern. I take the blame for writing the first Nostr client with that experience.

I'm following 50%.

Why can't the relay get really smart? We can have smart and dumb relays living together.

The key point is that these things shouldn't be restricted to a settings panel, they should be made an integral part of the experience.

I see, why wouldn't it work? The "+" event would have a reference to the first event.

But in your picture relay.ski.fan is doing the filtering on behalf of its users, which is what I asked.

Your desired scheme is the one from below, right?

#[1] what do you think?

I didn't know Coracle supported that. That's good.

`note` is a cosmetic thing that should probably be used only inside the apps. For sharing externally `nevent` should be preferred. Same thing for `npub` and `nprofile`. I am pretty sure Damus will implement support for these eventually.