24 comments
@skobkin @drq Yes, but it's more useful. Also you can mention authors in forwards, allowing continue this topic in new thread or subthread. @mittorn It's still a directed graph. So, time helps. The latest one is where you break the loop off. @drq @BigFoxBoss @skobkin how to handle answers to post in this case? You already fetched replies and returned to source post again, then drop it. You may miss some answers @drq @BigFoxBoss @skobkin ok, we opening hell thread. Not usuall hellthread with 100500 messages, but with 1000050000. We getting all servers down because they sorting their graphs. Also anyway may turn any thread to helltread by milti-replying to helltread in it... @drq @skobkin really, if you want to answer to multiple posts, you need break graph connection and build new. This helps keep implementation and UX simple, but with same abilities. Maybe we ability to embed "link" not to post, but to thread. Not usually url, but some reference. So starting new thread and posting reference to old thread will make it as separate "subthread" which does not embed to original thread, but opens separately. In this case we will not have loops or stranges in UX. @mittorn It becomes too cumbersome then, and breaks semantics. I got 3 near-identical or adjacent replies, goddamnit. I need to *reply to* all of them. Not "post a link to some message". Not "link to thread of subthreads of subthreads". Reply. Much like I would reply to three humans standing right next to me @BigFoxBoss Mention mentions people. It's all it does. In-reply-to marks a message as a thing-that-this-message-is-a-reply-to-in-this-particular-conversation. Which is what I want. @drq @mittorn @skobkin Matrix has a thing called "discuss" when message is right clicked. It is as if some people went private with their discussion thread away from the main thread, except it's not public. If it becomes public, then it just becomes yet another thread where everyone is free to join and the whole point of "reply-to-convo" thing collapses again :blobfoxthink: @BigFoxBoss Errrmm... no? What you're describing is making an offshoot thread. Which is what I'm trying to avoid. @BigFoxBoss I don't want "hopefully", I want proper, parsable semantics. |
@drq
Because it's not what generic user is concerned about. It's quite advanced use-case scenario.
Not to mention that it'll require re-implementing thread UI/UX in a lot of projects.