FEP-f228: Backfilling conversations has been updated:https://codeberg.org/fediverse/fep/pulls/853
-
Yes, whenever the context element is referenced from a naked object per the current FEP-f228. The definition of "posts" was very useful, as this is about the 4th time I've done this - but trying to still provide reactions since our software considers them to be an integral part of the conversation.
No reactions.
Got it.
Don't worry that's it's completely flawed as a conversation filling mechanism and won't work well for anybody in the current fediverse until they implement this FEP fully --- a situation which I tried so hard to avoid.
Got it.
So it'll work like shit for the next five years, or maybe forever in the case of Mastodon, but it should be fully compliant with FEP-f228 -
Yes, whenever the context element is referenced from a naked object per the current FEP-f228. The definition of "posts" was very useful, as this is about the 4th time I've done this - but trying to still provide reactions since our software considers them to be an integral part of the conversation.
No reactions.
Got it.
Don't worry that's it's completely flawed as a conversation filling mechanism and won't work well for anybody in the current fediverse until they implement this FEP fully --- a situation which I tried so hard to avoid.
Got it.
So it'll work like shit for the next five years, or maybe forever in the case of Mastodon, but it should be fully compliant with FEP-f228Yes, whenever the context element is referenced from a naked object per the current FEP-f228.
I tried to fetch
contextfrom 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=truebut 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
likesandemojiReactionscollections, but I doubt that any implementation would actually resolve them. -
Yes, whenever the context element is referenced from a naked object per the current FEP-f228.
I tried to fetch
contextfrom 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=truebut 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
likesandemojiReactionscollections, but I doubt that any implementation would actually resolve them.I get exactly one "post", but the collection metadata was incorrect and said it was a collection of 3, and a collectionOf 'activity'. Are you seeing actual activities, or just incorrect metadata? Might need to DM a snippet if the former. If the latter, that should be resolved now. -
I get exactly one "post", but the collection metadata was incorrect and said it was a collection of 3, and a collectionOf 'activity'. Are you seeing actual activities, or just incorrect metadata? Might need to DM a snippet if the former. If the latter, that should be resolved now.
@mike I see activities, but I figured out why. The URL is normalized before fetching and
?posts=trueparameter is removed during the normalization.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).
-
@mike I see activities, but I figured out why. The URL is normalized before fetching and
?posts=trueparameter is removed during the normalization.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).
I might argue that what this represents is quite literally a "filtered view"...
But I could use a path instead.
My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right. -
I might argue that what this represents is quite literally a "filtered view"...
But I could use a path instead.
My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right.But I could use a path instead.
Actually it appears that no, I cannot. Then it is a different object in the eyes of conversation containers. (Because it is a filtered view). I don't see a lot of ways out of this dilemma that doesn't involve breaking something..
[Edit: maybe being silly, but I could send back an array of collections, with the preferred presentation first. What we called multipart/alternative back in the old days. Most software will probably not handle this well, and I'm not even certain my own would. But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.] -
But I could use a path instead.
Actually it appears that no, I cannot. Then it is a different object in the eyes of conversation containers. (Because it is a filtered view). I don't see a lot of ways out of this dilemma that doesn't involve breaking something..
[Edit: maybe being silly, but I could send back an array of collections, with the preferred presentation first. What we called multipart/alternative back in the old days. Most software will probably not handle this well, and I'm not even certain my own would. But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.]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=trueis 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.exampleI 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
contextHistoryproperty. -
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
contextHistoryproperty, it will resolve to a collection of activities. When it has acontextproperty, 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
Noteor anArticle, but it could be anEventtoo, 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.
> 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=trueis 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.exampleI 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
contextHistoryproperty.Conversation owner can add any activity to the conversation. However, if a
contextproperty is present on the activity, its value SHOULD be identical to the ID of a conversation container.
Let's just remove this line from FEP-171b. Then I think I can make most everything else work.
Tying the conversation target to the context in any way, shape, or form appears to be un-workable. That includes tying it to contextHistory instead. Thy are separate concepts, although implementations MAY choose to use the same identifiers for both.
About the 403 - was it fetched by your site actor perchance? They aren't one of my followers. I'm not seeing any permission issues currently, though I'll keep investigating. -
FEP-f228: Backfilling conversations has been updated:
https://codeberg.org/fediverse/fep/pulls/853I added tootik and Lemmy to the implementation list and did a little cleanup. This FEP feels complete, so I am requesting final comments.
Full text:
@silverpill@mitra.social @julian I've posted a proposal for following threads as an alternative to backfilling (and as an extension to how audience is defined in FEP-171b): https://codeberg.org/fediverse/fep/issues/449#issuecomment-17397479
It is inspired by what @holossocial@mastodon.social is proposing: https://tom79.dev/posts/follow-a-note/
-
@mayel backfilling is complementary to following threads, much like it is for 1b12 sync.
One keeps you up to date, the other lets you backfill objects made prior to your subscription.
So they work well together, actually!
-
@julian sure, but is there any FEP for following?
-
@mayel no, beyond what Holos suggested, I'm not aware of any.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login