FEP-7888 attempts to lay out clarifications for the use of the context property based on rationale and history, in which context is used primarily to logically group objects related by their “context”, or in other words, stating that some object “was created in relation to” another object, where the latter object denotes some purpose for the first object.
In response to FEP-7888, and motivated by the desire to backfill entire conversations, various softwares wishing to federate have chosen to directly represent context as a Collection of objects acknowledged to be “within” some canonical context collection. This FEP describes this approach, its usages, and some drawbacks.
Considering that the implementors of 2931 are closely aligned at this point, I am wondering whether there is enough of a reason for us to move towards a separate and distinct type for future proofing, instead of using OrderedCollection.
Otherwise we'll always have a situation where we need to support the case where a resolved conversational context is a collection.
Secondly, it would allow you to remove the drawbacks section significantly... right now it's over 50% of the FEP, which makes it rather hard for me to convince someone to implement 😁
Are you considering an additional FEP for backfill, or is this intended to be it?
It is still not clear why this proposal was submitted and accepted. The author didn't attempt to contribute to an existing FEP, and the only substantial difference between 2931 and f228 is that information about several implementations was removed.
@silverpill@mitra.social considering that these two FEPs have a decent amount of overlap I think there is enough justification for a merging.
I know I did argue for granularity, but the idea of backfill and that of representing a context's objects in a collection are pretty much identical from an implementor POV.
One describes behaviour the requestor, one describes behaviour of the recipient.
@julian If anything is missing or unclear in FEP-f228, I can change it. Specifically, I will mention a new type value if supported by implementers. That applies to other new developments as well -- FEP-f228 is intended to be descriptive rather than prescriptive.
Unfortunately the drawbacks don’t stop existing as more people implement this. It just means that more people are subject to the drawbacks. If people decide that the drawbacks of using a Collection type directly are worth less than the benefits of interop with the existing implementations, that’s their choice to make.
This FEP is not strictly for backfill, so if you’re looking for backfill then that would be a different FEP. @silverpill above mentioned FEP-f228 which probably covers more on that specific use-case, but it goes too far for what FEP-2931 describes. Notably, FEP-2931 has nothing to do with replies or contextHistory, and it isn’t even restricted to “posts” or “conversations”. It primarily exists to make use of FEP-7888’s extension point for the concept of a “canonical context collection” by mapping Collection to id, in the same way that a hypothetical Conversation type might map to a posts collection, or a hypothetical Project type might map to a tasks collection, or a hypothetical Forum type might map to a topics collection and a subforums collection, or so on.
Lastly, I want to address something tangential from @silverpill:
This proposal was submitted for several reasons listed above, and I want to push back against the idea that FEP-2931 and FEP-f228 are addressing the same subject matter. They are fundamentally different aspects and their only commonality is that FEP-f228 makes reference to the context property. Also, as you point out:
so it seems like you at least somewhat recognize that these two FEPs are different in at least approach. I don’t see how this constitutes “abuse” in any way, and I strongly do not appreciate this claim being made. If you want to claim that this FEP shouldn’t exist, or that you don’t like this FEP, or that you have concerns about this FEP, then that is a different matter.
>They are fundamentally different aspects and their only commonality is that FEP-f228 makes reference to the context property.
Different in what way? It is not only the same context property, it's the same use case (backfilling, as you state in the summary), and the same solution (producing and consuming the collection). Obviously, the wording is different. And there are additional comments that repeat points from your other FEPs, and also you didn't include several implementations that are compliant with FEP-7888, but I think these differences are not substantial.
If a FEP doesn't provide any new information, it shouldn't exist. Otherwise the repository would be filled with nearly identical proposals, and that doesn't help the Fediverse community at all.
Some existing FEPs have similarities, but in all those cases there are substantial differences, and authors of newer FEPs often describe what the disagreements are. FEP-d556 is a good example. You can add a similar section to FEP-2931. However, there was no prior discussion, and no disagreements, so I don't know what could possibly go there.
No, the summary states that backfilling was a motivation by implementations to start publishing Collections, not that backfilling is the purpose of this FEP. This FEP describes the representation and leaves backfilling/etc out of scope.
The information it provides is regarding the “canonical collection” extension point from 7888, as well as the drawbacks of using a Collection directly (“is a” Collection, rather than “has a” Collection).
FEP-2931 deals with something separate from FEP-f228. This should be obvious by FEP-2931 not saying anything about using the replies collection, nor does it say anything about what a context’s canonical collection should contain, nor does it use concepts like “posts” or “top-level post”. This isn’t simply “removal of information”, this is a matter of different scope entirely. Such information is irrelevant to FEP-2931. If I were to add a section to FEP-2931 regarding any of this, it would defocus the scope away from defining/describing this “context is a Collection” approach. Put another way, FEP-2931 doesn’t care what you do with the collection so long as you are aware of its existence and how to get there (via following the property path context.id rather than context.posts or context.tasks or context.topics or context.subforums or whatever).
Backfilling is described in section Consuming a context Collection of your FEP, and I don't see any mention of other uses of that collection. The rest is distinction without difference (collection contains objects instead of posts, etc etc), and removal of information.
I would sooner remove those 5 words (“for example, for backfill purposes”) if it would address your concerns. It is an example and not the primary purpose. The information I want to convey is that:
context.id is the property path to the “canonical collection” described in 7888,
Focusing on drawbacks is a good idea, because this information is currently not present in FEP-7888 and FEP-f228. But then, shouldn't this proposal have informational type? As far as I can tell, the normative part is just one statement about context.id, which makes sense only if other types of canonical collections exist. Do listed implementations actually support other types of canonical collections that are not identified by id?
The plan is for other types to use the same mechanism in the near future, but those FEPs haven’t been written yet because they would be premature. The most mature proposal would be mapping Conversation to Conversation.posts or something similar, as NodeBB briefly published this representation before reverting it as too early (no namespace, caused issues with Discourse)
At the moment I don’t think they do, but they can do so using something like case matching:
def process_canonical_collections(context: dict):
"""
assuming you've expanded the payload
then compacted against your own context
then normalized to a json object as dictionary
where `@type: @id` terms are normalized to objects
"""
for t in context.get("type", []):
match t:
case "Forum" | "MessageBoard": # whatever you call it or compacted it to
try_do_something_with_conversations(context.get("topics", {}).get("id")) # in SIOC you would iterate directly over `container_of`
try_do_something_with_forums(context.get("subforums", {}).get("id")) # in SIOC you would iterate directly over `parent_of`
case "Conversation" | "Thread": # whatever you call it or compacted it to
try_do_something_with_posts(context.get("posts", {}).get("id")) # in SIOC you would iterate directly over `container_of`
case "Collection" | "OrderedCollection": # if encountering orderedcollection, you can infer that it is also a collection, but here we just check for both types.
try_do_something_with_objects(context.get("id")) # this is left open-ended, whether f228 or whatever, you don't know what is inside the collection.
case _: # for any types we don't recognize (e.g. `https://w3id.org/fep/xxxx/Project`),
pass # we can just ignore them and do nothing.
The reason FEP-2931 is declared as an implementation FEP and not an informational FEP is because it can be implemented by fulfilling the one criterium: handling the singular case where the context’s canonical collection is the context itself. I don’t want to add any other criteria because for the purposes of FEP-2931 it doesn’t matter what you do with the collection nor does it matter what it contains. It only matters how you discover it.
At the end of the day, it’s important to recognize that context is not required to be any particular thing (“intentionally vague”), and other implementers might use something else that isn’t a Collection, or they might put things that aren’t “posts”, or so on. So statements about the replies collection or discussing whether you expect objects or activities are wholly irrelevant here. Normative requirements like “MUST be an OrderedCollection” or “MUST contain the top-level post” are also completely out of place.