@trwnh @julian @silverpill

Jargon term, should define:

https://en.wikipedia.org/wiki/Listicle

@evan @julian @silverpill This goes back to a convo from yesterday about how to handle Activity types with content, which conceivably makes them "posts" in the sense of an "activity stream". ("John Created a Note" is a first-class item in much the same way "Sally Liked a Note" is also a first-class item in Facebook's activity feed, or "Alice Added 9 Images to a MediaAlbum" would be.)

If you put content on an Announce, then that Announce is ostensibly its own "post" in addition to being a share.

@julian @erincandescent @evan @silverpill Let me put it this way: the latter half of FEP-7888 can be summarized as "reifying context as an object, and specifically a Collection". If you *just* want the grouping, then it could be an arbitrary opaque IRI. But what you gain by reifying the context as an object is specifically the ability to give it metadata properties. Particularly things like `attributedTo` or `audience`. Maybe even `followers` or `outbox`. An opaque IRI cannot do this.

@julian I reported this to you because one user asked me "why I can't discover this NodeBB thread from my instance?". I think this is going to happen quite often across the Fediverse.
Maybe in the future we will figure out how to deal with these collections, but right now this leads to a bad user experience

@trwnh @evan @erincandescent @evan

@erincandescent @julian @trwnh @silverpill a thread is a tree with a root. Every non-root node in the tree has an `inReplyTo` that points to one of the other nodes.

It's represented by a `Collection` in the `context` property of each object. (I don't like this, but it's common so we should just use it).

It's in reverse-chronological order.

If you started at the root node and walked the tree using the `replies` collection, you should visit exactly the same nodes as in the `context` collection.