We normally do full activities, but after some prodding, I've begun implemented the forth-coming FEP about context vs contextHistory. So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else, and contextHistory is full activities for everything associated with the opening post-of the conversation; but what a nightmare...  

We do not typically provide URLs as collection members, because you may need a signed activity to access and validate third-party objects which have source access control enabled.

julian:

individual objects serve a context property that context property is a URL that resolves

One of the concerns raised was related to the OrderedCollection of items served by the context. Specifically, if the items presented in the collection were not in chronological order, NodeBB failed at importing some of the items as the inReplyTo referenced an object that did not exist.

The solution to this was to ensure that the collection items were in chronological order from oldest to newest. Once fixed:

the context resolved to an OrderedCollection containing objects NodeBB was able to pull in the entire conversation

Just a note that I endorse @julian's suggested approach here, and this is how the Discourse plugin has implemented its backfill feature.

@mikedev

>So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else

Shouldn't Create|Update|Delete also have activities in context?
My understanding is that context collection is supposed to contain things that have collection ID as their context property.

If entity is an activity, its context is a collection of activities.
If entity is a post, its context is a collection of posts.

@julian @pfefferle @jesseplusplus @trwnh @mario @harmonicarichard @reiver @aslakr @Fitik

@mikedev I wonder, what do you think about having conversations represented by a specific Conversation object? Basically, saying a conversation *has* a collection of posts, rather than saying that a conversation *is* a collection of posts.

- Conversation.posts = Collection of Objects
- Conversation.outbox = Collection of Activities
- Post.context = Conversation

where "Post" is loosely an Object that has content

I think it's all insane. A collection of everything related to a thread is a collection is a collection. Distinguishing between those that can contain an implied Create and/or full activities and/or a URL and those who can't/shouldn't seems like a nightmare of unnecessary complexity.

An item in a collection can be a number of things (URLs, objects, activities), any of which you need to be able to accept and process to be considered ActivityPub/ActivityStreams compliant at a basic level.

I don't believe we really need one collection for the posts people and another for the conversation people containing different representations of the same content - but here we are. Perhaps we need yet another representation for the URL-only folks? If you think that's madness, then why isn't this madness?

@mikedev i think this is all protocol stuff, and the real madness is claiming we have a single protocol called "activitypub" that everyone can implement the same way

rather, a protocol is the sum total of everything needed to communicate, negotiated between parties. fundamentally this question is about whether you store activities as resources, or just consume them as RPC. but ideally the conversation/thread should be agnostic to this, and it shouldn't be bound to any particular representation.

@mikedev more generally, there are a lot of conceptual issues with AS2 Collection in both data model and protocol. it seems especially problematic to say that a conversation/thread *is* a Collection, because a Collection can be anything -- someone's followers, a conversation, a photo album, an audience, a feed, a task list, and so on. imo this is a fundamental error in information modeling. a Collection ought to represent a set, not myriad other entities that might *have* a Collection.

@julian the taxonomist in me screams, for i do not know what i am looking at (and people refuse to describe it properly)

@trwnh@mastodon.social given that one way a context collection is discovered is via reference via a collection member itself, that's one way to define it.

Admittedly, direct access to a context collection is also a legitimate use case (e.g. a NodeBB topic URL itself is the context collection), so something more explicit might be required.