Related to the ForumWG topic of resolvable context collections, there are four FEPs that are currently in consideration:
- FEP-7888: Demystifying the context property
- FEP-400e: Publicly-appendable ActivityPub collections
- Draft FEP-171b: Conversation Containers, an evolution of Conversation Containers
- FEP-76ea: Conversation Threads
@[email protected] made a suggestion last month to hopefully reduce the number of moving parts:
- Both FEP-400e and FEP-1b12 implementations: support FEP-7888 (context collection)
- FEP-400e implementations: upgrade to Conversation Containers
- FEP-1b12 implementations: add target property to Announce activity that points to context collection.
This takes FEP 400e out of the running (potentially). But the day after that last meeting, @[email protected] put together FEP 76ea, and now we're back to three.
My concern is that all three FEPs (7888, 171b, and 76ea) all share these distinct qualities:
- They establish a conversational context for a given object
- They federate out an
Add on collection addition. (76ea also sends Remove)
- They contain some concept of a context owner (
attributedTo)
They differ on the following qualities:
- 7888/171b use
context whereas 76ea uses a new property thr:thread
- 171b specifies a new object type
Context
- Collection items:
- 7888 sends objects in chronological order
- 171b sends activities in chronological order
- 76ea sends objects in reverse chronological order
In the lead up to the November WG meeting I'd like to address those differences. All three FEPs are in pre-draft or draft stages, and so I am hoping we can find some common ground and compromise.
Pinging interested parties (who were not already mentioned above) for comment:
@[email protected] @[email protected] @[email protected] @[email protected]
@[email protected] Yes. Per 1b12,
audienceis the appropriate property to use to denote a collection of loosely-related objects.contextis ideal for closely-related objects (like ones that share a reply tree, but that doesn't rise to the level of a requirement), like posts in a context (topic/thread).In your examples, the "thread" is a
Collectionwhen resolved and is referred to in objects viacontext. The "category" is an Actor when resolved, and is referred to in objects viaaudience.As for the other conversation, it honestly seems like you and @[email protected] are splitting hairs and really want the same things.
@julian The sticking point is basically whether I should guess what the thread is, or be told what the thread is.
He wants me to perform a bunch of tests and guess; I want it to be declared.
I am not sure what you are going to do when there are multiple collections associated with a post. Because unless the thread is declared, you won't know which is which.
@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
My plan is to take the first item in
contextand treat that as the most narrowly scoped collection containing that object. The assumption is that the contexts are ordered from narrow-to-wide. Whether or not additional contexts would be helpful is irrelevant to me, as I am converting this object into a NodeBB topic only.You can make arguments that this is not correct. I will not disagree. I will simply say that, like it or not, this is the simplest form of compliance most implementors will opt for.
@julian The sad thing about this is that we have an opportunity to set the standard here, and we are not taking that opportunity.
Yes, we have to assume that not all platforms will add the additional fields, and we have to have a fallback way of processing incoming posts.
I am just flabbergasted that
"thread": "https://remote.example/thread/117",is too hard to include with posts distributed by the forum. Even if you don't use it, some of us might find that to be useful information.But it appears that I am alone in this, so I will just let it be.
Hi @[email protected], thanks for your thoughts. I took the evening to think it over.
I agree that using
thr:threadwould be the most explicit way of signalling that NodeBB topics are threads, and if 76ea were to be adopted by a majority of implementors, then I would reconsider. Currently I am on the fence about whether or not I should implement it.I do want to point out that @[email protected]'s FEP 7888 doesn't expressly forbid multiple contexts, and I think upthread they even said that such a use case would not be contrary to the FEP:
My opinion today is that when NodeBB uses
context, it is doing so to signal that "hey, these posts are part of this collection", and exactly nothing more. It is up to the receiving end to decide how to implement it, and I think that this sort of variety is absolutely wonderful.If, for example, someone were to see my context and say "I'd like to map this context's objects out into a word cloud and do sentiment analysis on it", I think that's a perfectly cromulent use of the data. For me to say "this here is a thread, and you better treat it as a thread" is contrary to the spirit of ActivityPub and fedidevs in general.
It would be like the ForumWG saying to Eugen, @[email protected], et al. that "we've decided that YOU, Mastodon, need to support
as:Listenand render inline players, and playlist support, etc.". That's ridiculous, wouldn't you agree?@julian
Simply declaring a collection to be a thread does not force people to display it as a thread. But it does provide valuable information to people who do want to display it as a thread.
So you are not removing people's choice by simply stating that on your platform, this is considered a thread.
@julian If that is how you want to do it, I respect that. But I do find it odd that the FEP actually has a field for thread and nobody plans on using it. But, most platforms either have 1 context or 0 contexts, so it makes sense.
I still haven't decided how I will do things with my fediverse-enabled project management system. At some point, there will probably be multiple contexts. If that is the case, I probably will put the thread as the first context and then also declare what the thread is using FEP 76ea or something similar.
That way, at least with my project, you won't have to guess which one is the thread. And since your platform only has one context, then I won't have to guess either.