|
Top-level
 Even right fucking now... @BigFoxBoss and @mittorn are asking the same things from me, and I have to answer separately, and they don't see each other's messages while posting them, and I make mistakes, and I am getting angry and GAAAHHH This sucks!!! 105 comments
  @mo You're not listening. The idea is not to mention people. We already got mentions for that. The idea is to link messages as parents and a child. @drq @mo @BigFoxBoss And this idea is completely wrong by design. You cannot just break loop in graph keeping structure. @drq ...and not everyone are happy with complicating DB schema and client API for this @mo @drq @BigFoxBoss So this should not be replyTo usage, just some separate field. Like "Linked posts" @mo Ermmm. Yes... The idea is to upgrade things to expect that. Or upgrade = break in your vocab? @drq I suggest you to look at this list https://fedidb.org/software and estimate, how easy it would be to patch everything @drq ...and patching everything is REQUIRED, because you can't just change types in JSON and don't handle it in the code @drq alternative solution: just link your first reply in second, if you're too scared to mention additional user Like "Already replied here: <link>" Easy? yes @drq yeah, looks like you got the trick. Keep doing like that :ageblobcat: @mo I don't want to. It makes me angry that there's no proper tooling around this. 1. Polytrees (which is basically what I propose here) are still directed and acyclic, so looping is completely irrelevant here. https://en.wikipedia.org/wiki/Polytree 2. I don't care about technicalities at this point. 3. Some don't but may be some do. I do. But yes, the UI will need to accomodate, somewhat, but I'm sure we can figure something out 4. This is actually a way to *avoid* hellthreads, and avoid parroting the same points all the time. @drq @drq also: your suggestion is not a polytree. Like, on the image from wiki, nothing stops G to be reply to both D and E @mo Nothing stops, but they aren't. Some messages are not replies to some other messages, you know. @drq on the pic — arent. But there could be such thread if multireply is implemented @drq how would you render such a mess if they will? @mittorn Basically, joining two adjacent threads into one down the line. Yes, that's what I want. @BigFoxBoss We already have abilities and opportunities to mention a shitton of people at once, so it's a wash. Also, I already answered to how 3 will work under the hood. @BigFoxBoss By linking to a collective memory of people who already had this conversation. @drq @mo @BigFoxBoss Yes, we need "secondary link" semantics, not this shit. For me this opens MML in separate tab, very useful. And thankful, that is not some misskey @mittorn What is a "secondary link"? What does it describe? What is its semantics? Is it a reply? Is it an in-reply-to? If it's either, then either field becomes a duplicate and oh shit, here we go again. @drq @mo @BigFoxBoss just "link" entity or attribute, that will scroll thread to specific point or open other thread, not open fucking new browser tab. No, this should not appear in reply. Maybe we need this appear in some separate fields like mentioned: [array] @drq @mo @BigFoxBoss The MAIN issue is AP/AS spec because it was developed for XML originally, but was migrated to json-ld in fast and incorrect way.. Now we have what we have... @drq @BigFoxBoss but in case you "multi-reply" and we filter loops, only one of messages will get reply. Otherwise we have 2 identical branches in thread (loop). This breaks structure at all |
Gregory's Server
@drq you can...just mention both in one reply...
@BigFoxBoss @mittorn