@erincandescent @julian @evan @mikedev @silverpill i don’t think “conversational thread” is a special semantic relationship, and i certainly don’t think it is equal or equivalent to a reply tree! the basis of 7888 is that context should be used for purposeful logical grouping, as it was intended and as it ended up being used in pleroma for years. an unresolvable opaque uri is 7888-compliant. so is a collection with an owner. so is anything else. but IF it is a collection,
@erincandescent @julian @evan @mikedev @silverpill i don’t think “conversational thread” is a special semantic relationship, and i certainly don’t think it is equal or equivalent to a reply tree! the basis of 7888 is that context should be used for purposeful logical grouping, as it was intended and as it ended up being used in pleroma for years. an unresolvable opaque uri is 7888-compliant. so is a collection with an owner. so is anything else. but IF it is a collection,
@erincandescent @julian @evan @mikedev @silverpill …then it makes sense that the collection ought to contain items sharing the same contextual grouping. it’s similar to how hashtags are content-addressed grouping, but less purposeful, and no one owns them. the key is that even if you can’t resolve anything out of whatever is in context, you can still use it for grouping by opaque string matching. so there’s clearly defined graceful fallback.
@erincandescent @julian @evan @mikedev @silverpill …then it makes sense that the collection ought to contain items sharing the same contextual grouping. it’s similar to how hashtags are content-addressed grouping, but less purposeful, and no one owns them. the key is that even if you can’t resolve anything out of whatever is in context, you can still use it for grouping by opaque string matching. so there’s clearly defined graceful fallback.
@julian @silverpill @trwnh @erincandescent @mikedev I think `context` can be used as a fallback, which provides continuity for most of the legacy implementations.
@erincandescent @julian @evan @mikedev @silverpill as far as reply trees go, it should be clear that they are not the same as a conversation or context, and inReplyTo exists completely separate and parallel to contextual grouping. the “reply tree” model falls apart the second you reply to multiple things, or reply to something in a different context, or reply and change the context, or set a context but no inReplyTo. i’m not sure why you say Announce has anything to do with it with
@erincandescent @julian @evan @mikedev @silverpill as far as reply trees go, it should be clear that they are not the same as a conversation or context, and inReplyTo exists completely separate and parallel to contextual grouping. the “reply tree” model falls apart the second you reply to multiple things, or reply to something in a different context, or reply and change the context, or set a context but no inReplyTo. i’m not sure why you say Announce has anything to do with it with
@erincandescent @julian @mikedev @silverpill @trwnh there are other uses called out in the AV spec. Someone using those would clash with the use for threads.
I recognize your aversion to change, but "don't change anything" isn't on the menu. We need a way to identify the thread relationship, and a dedicated property is much better than duck-typing objects or making a new collection type.
@erincandescent @julian @mikedev @silverpill @trwnh we have many orders of magnitude more AS2 objects in our future than in our past. I don't think informal practices of existing software should keep us from implementing better formal systems in the future.
@erincandescent @julian @mikedev @silverpill @trwnh we have many orders of magnitude more AS2 objects in our future than in our past. I don't think informal practices of existing software should keep us from implementing better formal systems in the future.
@evan @erincandescent @julian @mikedev @silverpill what is the “thread relationship” and how does it differ from “contextual grouping”?
@evan @erincandescent @julian @mikedev @silverpill what is the “thread relationship” and how does it differ from “contextual grouping”?
@trwnh @erincandescent @julian @mikedev @silverpill reply tree
@trwnh @erincandescent @julian @mikedev @silverpill reply tree
@infinite love ⴳ
Three use cases some to mind concerning collections and context:
1. Threaded conversations.
2. Collections of posts.
3. Categorizing posts.
I am not sure if this feature still exists, but I remember when Twitter allowed you to place other people’s posts into a publicly sharable list. It was a collection of posts curated by someone, but was not a thread.
I don’t know of any fediverse app that currently implements such a thing, but I just wanted to point out that collection and context can be used for things other than threads.
Another use case is placing posts in categories, or place entire threads in categories.
So we probably should explicitly state that something is a thread or conversation… as opposed to a list of random posts on a particular topic.
Is anybody in this thread saying not to implement a better formal system? To me it seems that others are just suggesting doing so without disregarding the informal practices of existing software (that comply with the existing standard).
@trwnh @erincandescent @julian @mikedev @silverpill I have an example of a reply to multiple things in the FEP.
"Comment but don't participate in thread" is a quote boost. It also works for forking to a new thread.
So, that's what `Announce` has to do with it.
Conversation threads are *usually* reply trees, and we should optimize for that easy base case. The advanced tree-pruning and -grafting you describe are possible with a reply tree.
@trwnh @erincandescent @julian @mikedev @silverpill I have an example of a reply to multiple things in the FEP.
"Comment but don't participate in thread" is a quote boost. It also works for forking to a new thread.
So, that's what `Announce` has to do with it.
Conversation threads are *usually* reply trees, and we should optimize for that easy base case. The advanced tree-pruning and -grafting you describe are possible with a reply tree.
@evan @erincandescent @julian @mikedev @silverpill
> Conversation threads are *usually* reply trees
this is an anti-pattern. conversations are only represented by reply trees when there isn't an actual conversation. reply trees are a poor substitute for that.
> "Comment but don't participate in thread" is a quote boost.
i'm talking about participating in a thread without responding explicitly to anything. or responding to something, but in a different thread. no one is boosting anything.
@evan @erincandescent @julian @mikedev @silverpill
> Conversation threads are *usually* reply trees
this is an anti-pattern. conversations are only represented by reply trees when there isn't an actual conversation. reply trees are a poor substitute for that.
> "Comment but don't participate in thread" is a quote boost.
i'm talking about participating in a thread without responding explicitly to anything. or responding to something, but in a different thread. no one is boosting anything.