Define l-tag on Text Events

[Giszmo]

Clients currently have no way of querying only root Text Events, which is all they need for a timeline for example. To improve this, the l-tag allows querying root-events or even improve loading of replies on very busy threads by only loading the next level at a time.

[staab]

Unfortunately I don't think this really solves the problem, as long as there are events clients care about that don't have these tags (which is all past events, and any future ones published by non-conforming clients). Switching to nip 22 would lose us new-style comments, switching to this PR would lose us old-style roots. I am skeptical that nip 10's problems will ever go away.

[arthurfranca]

This alternative was already discussed (though the proposal had also extra e tags to keep track of which branch of the reply tree to fetch x levels deep, explained here)

[Giszmo]

@staab if we don't innovate, the problem of loading too much will not go away. If we introduce a reply-kind, the problem goes away on the top level but not for deeper levels in a thread. If we mark levels, the problem will go away eventually on all levels. The advantage of my proposal is that clients that are not aware of the change will not degrade, so the cutting edge clients can have an eye on the situation, can lobby the clients that don't join the improvement and eventually they can profit from this.

@arthurfranca thank you for the reference. I see how you would indeed need all these e-tags to get the full benefits of what I thought my nip would provide. All the e-tags is bloaty. I get why people would not want that. If only the respective next level is getting queried, which makes sense in social clients, the mere l-tag is a big benefit though, as you read a thread from start to finish along different paths. Your many-e-tags on the other hand help to efficiently load the full thread of any deep reply which can be very helpful in the case of some big influencer root post with thousands of direct replies and dozens of deep threads.

[staab]

I think the nip 22 approach is ultimately better, because it relies on a new format in addition to nip 10 replies. This means that the number of unwanted replies getting fetched will be never be reduced for legacy events, but it can be for the new format. This PR relies on dropping support for unmarked root level replies, which means that old roots will stop getting fetched. Basically, this PR doesn't solve anything unless clients become backwards incompatible, while the NIP 22 only requires slower clients to be forward incompatible.