when you create a reply, the only tag you care is if there's a root to include because you already have the reply at hand, so searching for `root` is what's needed, otherwise you get into a if / else war to know if there's no `root` because it's a root or because it doesn't mark tags.. the root id is the constant on a thread.
Discussion
I mean if there's a reply tag that does also show that it's coming from a source that uses markers. I see what you're saying about the root being the constant throughout the thread though.
I've updated all my code so that I'll be marking as root from now on.
if you use `reply` as first and if you search for a root and don't find one, then you need to see if there's a reply..
if you use `root` as first and don't find one, then you know the reply is the root.
in the first case you increase the effort by having to make another check and make it more error prone.
I also had it backwards at first, but it makes the most sense if you think about it
So if you come into possession of the root, can you can query for all posts that have the same root in a single query using NIP-12? Rather than getting the parent, then the next parent, then ...
depends on what you're trying to achieve, you can still use the two scenarios to reconstruct a thread.
If you want the whole thread, then you can do `{"ids":["root_id"]}, {"#e":["root_id"]}` as a request to get the root event and all events that reference it. you can of course refine that search with any other field that suits your case, like only certain `kinds` or only from `authors` you follow, etc, OR, you can simply reconstruct a particular discussion on a thread by going up the reply chain one by one.