@takeshitakenji That conversation you linked, looks perfect on my mastodon instance ;) just fyi. Meaning the issue is ALSO GS related.

@stitch @takeshitakenji It's simple: Mastodon breaks shit, but also contains code to work around breakage, so it's not visible there. The final result on the Masto side is an improvement (no ghost convos), but it wreaks havoc on the GS side, which lacks fill-fetching.
@clacke @takeshitakenji @stitch Ah, the ol' embrace, extend, extinguish way of making standards useless.
@pettter @takeshitakenji @stitch I don't see any intended malice, it's just that the specification is incomplete and/or ambiguous, and everyone else have reasoned that this means the installed base is the specification. @gargron doesn't.
@clacke @takeshitakenji @stitch Judging from discussions between @mmn and @gargron it sure sounds like theres the (well-specified) standard, and then the way Mastodon does it. Not implying malice though, but the effect is more or less the same.

@pettter @mmn @takeshitakenji @clacke @stitch "well-specified" is not what I would call it. The standard is very vague with no implementation examples. So yes there is room for interpretation and I'm trying to make my implementation more semantic without breaking compatibility. Regarding conversations, there are two standards governing them. Mastodon implements one. The other is less well defined.

@gargron @takeshitakenji @clacke @stitch Which standards are you talking about here? First there's one that is ill-defined, then two others? Or just one separate one?

I know OStatus is sort of a meta-standard, using various previous ones such as Atom, WebFinger, Salmon, ActivityStreams etc. but my understanding is that they are relatively well-defined, both in themselves and taken together. I might definitely be wrong about that, though, as I haven't done too much implementation work (just watched @mmn do a bunch and made a nuisance of myself requesting features ;) )

@pettter @mmn @takeshitakenji Salmon, Webfinger, etc are pretty well defined, but the format of messages is pretty much up to the implementation. There is no spec-defined example for what a "favourite" event should look like, for example. As far as ActivityStreams are concerned, there's an actor, a verb, and an object. And a big list of verbs and object-types, most of which GS does not use.

· · Web · 0 · 0 · 0
@gargron @mmn @takeshitakenji So what standards were you referring to as "very vague"? What two standards are governing conversations?

@pettter @mmn @takeshitakenji This is the standard Mastodon implements: tools.ietf.org/html/rfc4685 What it does is refers to the replied-to status directly. The other is "ostatus:conversation" which is barely mentioned in the OStatus spec itself.

@pettter @mmn @takeshitakenji ostatus:conversation carries a random unique token or ID between statuses that reply to each other. I'm not saying it's not useful, but it's denormalization, which is a lower priority because it's technically redundant information.

@gargron @mmn @takeshitakenji There seems to be a difference in paradigm here - in-reply-to is a direct one-to-one relation between posts, whereas the ostatus:conversation makes the conversation an object in its own right.

In short, they seem to be filling different purposes, as far as I can tell. With ostatus:conversation you can indicate that you're responding not to a specific post, but rather participating in a conversation?
@mmn @takeshitakenji @gargron In particular, I don't find the conversation ID to necessarily be redundant information, and specifically not in any technical sense.

@pettter @mmn @takeshitakenji Correct, but this does not contradict my point - it's denormalization, as the sum of one-to-one relations is the entire conversation. Since Mastodon is able to stitch together conversations using one-to-one relations, it's not an issue we experience a lot, so it's not high on the priority list to solve it.

@gargron @mmn @takeshitakenji I don't agree. You could have a conversation without a specific starting point, and participant notices that do not cite a specific parent.

@pettter @mmn @takeshitakenji No, that is not actually possible. I mean, it's possible to express that in Atom, but there is no use case for that in GS or Mastodon. Replies only get created when you click reply on some post.

@mmn @takeshitakenji @gargron Moreover, going technical, by having a distributed conversation rather than one-to-one relations, you could also avoid big conversation network-splits coming from specific nodes being down exactly when trying to fetch the conversation.
@mmn @pettter @takeshitakenji i think i agree with @gargron here. last time i checked, i remember thinking gs needed work on conversations
@mmn @pettter @takeshitakenji @gargron e.g. i think gs doesn't store the reply-to uri if the notice replied to doesn't exist locally (yet)
@mmn @pettter @takeshitakenji @gargron imo conversation_id in gnusocial is only a good idea if it speeds up db-stuff locally
@hannes2peer @mmn @gargron Not the notion of a conversation as an object in its own right?

There seems to me to be lots of opportunities for split conversations and trouble to stitch conversations together, e.g. with nodes going offline, connectivity issues, deleted notices etc. that can be _helped_ if not completely fixed with having a conversation-ID.
@pettter ah, you are right. one-to-one relations is a problem when deleting notices. @mmn @gargron

@hannes2peer @mmn @pettter To be fair, if you remove a post on Twitter it also splits the conversation before and after

@pettter @mmn @hannes2peer Oh for sure. As I said I think that ostatus:conversation is useful.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!