Thread NIP

[arthurfranca]

It tries to fix thread building and loading with better rules to follow instead of NIP-10 ones.

Read here

This would only work with major client owners cooperation. Maybe its the last chance to fix this.

[jb55]

Can you include a motivation section with why you would want to use this over nip-10 ?

[arthurfranca]

@jb55 Added motivation section

[vitorpamplona]

Please keep new ideas as Draft PRs.

This makes sense, but I would also add the q tag since it's not yet a NIP. Or find a new way to quote a post.

[fiatjaf]

This causes immense disruption for basically no gain.

[arthurfranca]

@vitorpamplona the q tag is there at the "Mentions" section.

@fiatjaf yes an immense disruption that requires major clients buy-in. Honestly, I don't expect it to be merged but atleast I tried. But "no gain"? Zero? There are open issues or users asking for ways to 1) fetch just root events 2) editable kind:1 3) problems if referencing using a instead of e when replying to replaceable events 4) Impossibility to fetch just root's direct replies 5) No standard to select relays from where to fetch replies 6) All sorts of problems for using e tags with markers while markers can't be used in REQ filters.

We can choose to not fix the problems because it would require massive client cooperation but denying they exist is delusional or dishonest.

[vitorpamplona]

This causes immense disruption for basically no gain.

e got to be a generic way to reference an event. It's similar to the issue you raised in the labels NIP-32 discussion. Most other event kinds use e to not mean reply. So, if we are going to specify the different behaviors for e to avoid using markers, then this is probably an improvement. Otherwise, we should keep using markers.

We just shouldn't have the two strategies (markers and specialized tags) at the same time.

[fiatjaf]

@arthurfranca why do you say "major clients"? Why not the minor clients too? Because you know they will be effectively forced to change once the big clients accept the change? That's a very nasty way of conducting protocol development that happens everywhere but we should at least try to not have here too. I think you should at least be polite and ask the smaller clients even if you don't care.

[fiatjaf]

To your points:

1. I agree this can be a problem depending on your use case, but it has proven to not really be a problem in practice -- it may also be seen as a feature, as you'll end up showing more conversations in your client if you're already forced to download these notes anyway instead of just showing those empty timelines of floating faces talking to the void; there may be other backwards-compatible ways of solving this, like using opt-in special tags.
2. editable kind is a bad thing, not a good thing, it introduces much more complexity than its supposed benefits, and we've had this conversation before. I know some people agree, others disagree, but you're just assuming it is a good thing.
3. I'm not sure this solves that, but I also don't see it as a big problem. Markers probably solve it well enough (again, not perfect).
4. This is not really an issue.
5. This is another problem, we could just have a relay tag for this or something like that if people want it.
6. I think this is the same as 4, which I don't think is really an issue (I know, I know, when we have threads with thousands of replies this will be a problem) -- but no one really reads thousands of replies, and these replies can be loaded in chunks, they will also often be in different relays and you will never get a global view of them all nor you should try to.

[mikedilger]

There are some good ideas here. But if this merged, nostr would fracture into incompatible clients that couldn't work with each other. It is easy to come up with a better idea. It is very hard to develop a real protocol in the face of deployed technologies.

[arthurfranca]

Imo we could be early enough to force minor clients to change, although it isn't good to do it the more time passes. Major clients can't be forced to do anything but I can try to convince them.

Though it is just my opinion.

To your points: ...there may be other backwards-compatible ways of solving this.. we could just have a relay tag for this

Thanks for the real feedback

Yes, there are some backwards-compatible solutions to a subset of the problems. Very hard though to even expect people to add a is_root to the root event for instance when the client owner doesn't care because the problem doesn't affect them. Your relay tag idea most likely won't be added too while some of the major clients simply load replies from the user relay list. Things are so hard to change that I wanted to take a shot and revamp the whole thing and maybe that would be a better pitch cause would touch so many pain points that would possibly convince some client authors each for a different reason.

...these replies can be loaded in chunks

One can't load in chunks when the replies are out of order. They are ordered by desc timestamp yes but they come from different levels deep in the thread. So clients basically just fetch everything at once and order them in memory.

[arthurfranca]

@mikedilger I was in hope that we were early enough to apply these changes. It was the best I could come up with using other people scattered ideas and my own.

I see this won't get merged and no problem, clients will still work; just not that well.

[fiatjaf]

Your relay tag idea most likely won't be added too while some of the major clients simply load replies from the user relay list.

I don't think this is true, I think this is a good idea that could be implemented gradually, it just takes one person to start adding it, then others can check if it's present or not and then default to whatever other strategies they may use.

Clients are already each using a different strategy for loading replies, as far as I know. We just barely notice because of some crazy syncing that happens in the background causes all relays to have all the events, but that will eventually end.

[fiatjaf]

One can't load in chunks when the replies are out of order.

I agree it's hard, but you could load the first 100, then the next 100, and as they come you would insert them into your thread tree structure. It's not the prettiest or easiest thing in the world and the UX will not be the best, but honestly it isn't very good in Twitter or anywhere either, mostly because no one can read these many replies.

Having the ability to load "all the first-level replies" wouldn't help very much either. Who is interested in that? I think most users would probably prefer to follow some replies that lead to longer conversations and split into multiple threads than to read all the first-level replies first, no?

What I imagine Twitter does is they try to load the "replies that interest you" using some algorithm -- which is something that we can achieve on Nostr by using some combination of carefully constructed queries, relay selection and DVMs or something.

[fiatjaf]

Honestly I think having two separate kinds for top-level posts and replies would have been a better choice if we were to start again, but starting again isn't an option and I'm not sure of that either. I keep switching between that being a better choice and not, there are pros and cons for both sides.

[arthurfranca]

starting again isn't an option

This sums up everything.

I think of all the thread problems, the worst offender is NIP-10 markers because it assumes the correct is to download a bunch of events and filter them client-side ignoring the easy win of filtering a bit more relay-side. I hope we learn the lesson of not overloading an indexable tag with more than one meaning for a specific kind. IMO e for kind:1 should've just meant the event one is replying to.

Just to illustrate, its very bizarre having to download "mentions" that may not even be part of the thread along with replies of replies of replies to the root event when I just want the direct replies to the root event. That's why this PR proposes 3 different tags: e (reply), o (root), q (mention).

Funny that I just found out NIP-10 was introduced as #1, the very first PR. Long before I came. Almost no one ever had a chance of discussing it.

[weex]

if this merged, nostr would fracture into incompatible clients that couldn't work with each other.

Might this be an opportunity to bump the note version?

[fiatjaf]

There can be no versions and no bumps if we want to stay decentralized.

[fiatjaf]

Funny that I just found out NIP-10 was introduced as #1, the very first PR. Long before I came. Almost no one ever had a chance of discussing it.

I know this feels bad, but bad decisions will be made. If this proposal here was adopted and Nostr grew and we found out in a couple of years that it was a bad idea what would all the new people think of it? "oh this proposal was adopted 2 years ago and none of us were even aware of it at the time!".

[jb55]

On Wed, Nov 15, 2023 at 04:17:01AM -0800, fiatjaf_ wrote: > Funny that I just found out NIP-10 was introduced as #1, the very > first PR. Long before I came. Almost no one ever had a chance of > discussing it. I know this feels bad, but bad decisions will be made. If this proposal here was adopted and Nostr grew and we found out in a couple of years that it was a bad idea what would all the new people think of it? "oh this proposal was adopted 2 years ago and none of us were even aware of it at the time!".

I honestly think nip-10 is fine, and that this NIP is super nitpicky and has obscure use cases. By all means build a client that uses these features, but they won't be visible in any other client. Maybe that's ok for arthur's client? I suspect there will be many different kinds of incompatible threads for different use cases. For example, loading very large and long-lived threads. I still think it's doable with nip-10 with a little elbow grease and a local database, so even then I find this spec sus.

[arthurfranca]

so even then I find this spec sus

sus in suspicious like I'm a bluesky employee trying to destroy nostr merging crappy nips? heheh

enough feedback Ima close it

[mikedilger]

sus in suspicious like I'm a bluesky employee trying to destroy nostr merging crappy nips? heheh

Are you even on nostr? I can't find an arthurfranca to follow. I bet your from Microsoft! 😲

[fiatjaf]

I'm a bluesky employee trying to destroy nostr

I knew it!

[arthurfranca]

My npub is a random faceless one till #158 rises from grave