One keeps you up to date, the other lets you backfill objects made prior to your subscription.

So they work well together, actually!

It is inspired by what @holossocial@mastodon.social is proposing: https://tom79.dev/posts/follow-a-note/

> What's important is that "post" is not an activity.

I don't see why this is important. In my view activities are posts. If Mastodon et al disagree, that's not my problem.

Also, the context can be anything. I don't see why a 2nd "contextHistory" property is necessary, nor am I entirely clear what it's supposed to mean semantically...

I might argue that what this represents is quite literally a "filtered view"...

That's fine, I fixed it on my side.

However, now I'm getting 403 responses when ?posts=true is present. At the same time, unfiltered collection can be retrieved without issues.

My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right.

The normalization algorithm recommended in FEP-ef61 removes query parameters because there is a magic query parameter gateways, which is used for location hints:

ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor?gateways=https%3A%2F%2Fserver1.example,https%3A%2F%2Fserver2.example

I thought that there will be more magic parameters and decided to "reserve" the entire query component (quoting section 'ap' URIs

The query is OPTIONAL. To avoid future conflicts, implementers SHOULD NOT use parameter names that are not defined in this proposal.

But of course, we need them to filter collections, so this is not a hard requirement (SHOULD, not MUST)...

But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.

I think a filtered view is fine, but you could also choose to not publish this collection - it is not required by FEP-f228. Other implementations should be able to backfill conversation using the contextHistory property.

This is because query parameters are not significant in 'ap' URIs:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#comparing-ap-uris

Not sure how to deal with this. I think collections shouldn't have query parameters in their IDs, but query parameters should be allowed in collection views (when filtering is applied).

Yes, whenever the context element is referenced from a naked object per the current FEP-f228.

I tried to fetch context from one of your (private) posts, but the collection contains activities:

https://macgirvin.com/.well-known/apgateway/did:key:z6MkhPXNfiHDh2qSNjFzZ9yY27C1iHnHVbb1eaxuoiEe4tjk/conversation/bf59f105-711d-4c71-96a3-923e90f76e18?posts=true

but trying to still provide reactions since our software considers them to be an integral part of the conversation

One way to provide reactions when only "collection of posts" is available is to use likes and emojiReactions collections, but I doubt that any implementation would actually resolve them.

@julian

In that case, not supporting the collection of objects is probably also okay.

Which is it? If it's both, how does that work?

Yes, it's both. The backfilling algorithm described in the FEP should be used on a top-level post. When this post has a contextHistory property, it will resolve to a collection of activities. When it has a context property, it will resolve to a collection of posts.

wtf is a "collection of posts"

Alright, I will add a definition to the FEP.

"post" is any kind of attributed object. Usually it's a Note or an Article, but it could be an Event too, or something else entirely. What's important is that "post" is not an activity.

And if "contextHistory" is an equal player with "context", every.single.fediverse.project now has to examine every context they copy to their own objects and activities, just to ensure they get the right one in each case. And if both are present, copy both - after checking that "context" is or isn't the one they really want.

It shouldn't be a problem because with the proposed backfilling algorithm the collection item type is always known beforehand.

If it's a problem, you can use duck typing on collection items. That's what I do when I fetch an object whose class is not known.

The wonderful thing about FEPs is you don't have to implement them, but you also don't get to decide who does.

Just a collection of Notes, Articles, Pages, whatnot

When context property is present on an activity, it MUST resolve to a collection of activities.