@frequency now fully supports FEP-7888 as of yesterday!
Uncategorized
10
Beiträge
3
Kommentatoren
1
Aufrufe
-
@frequency now fully supports FEP-7888 as of yesterday! (It has been generating outbound context since the beginning of the year, but I just finished fetching all remote replies from the context as well.)
Implement FEP-7888 - conversation context by jesseplusplus · Pull Request #188 · jesseplusplus/decodon
This PR implements FEP-7888 by: generating a context property and including it in the ActivityPub json-ld for all Statuses consuming the context property on incoming objects and fetching all obje...
GitHub (github.com)
I'll hold off on trying to upstream this to Mastodon until after the 4.4.0 release to make sure I'm not conflicting with anything they changed.
-
@frequency now fully supports FEP-7888 as of yesterday! (It has been generating outbound context since the beginning of the year, but I just finished fetching all remote replies from the context as well.)
Implement FEP-7888 - conversation context by jesseplusplus · Pull Request #188 · jesseplusplus/decodon
This PR implements FEP-7888 by: generating a context property and including it in the ActivityPub json-ld for all Statuses consuming the context property on incoming objects and fetching all obje...
GitHub (github.com)
I'll hold off on trying to upstream this to Mastodon until after the 4.4.0 release to make sure I'm not conflicting with anything they changed.
jesseplusplus@mastodon.social this is awesome!!
I have to give this a spin against NodeBB tomorrow!!
-
J julian@community.nodebb.org shared this topic
-
@julian woohoo! Yes, please. Let me know if you see any issues with it. I was using one of your NodeBB threads as my test case for fetching context
-
@julian woohoo! Yes, please. Let me know if you see any issues with it. I was using one of your NodeBB threads as my test case for fetching context
jesseplusplus@mastodon.social one technical issue I came across was that a context could potentially provide object ids that temporarily or permanently do not resolve.
That caused issues because internal NodeBB logic required that every
inReplyToreferenced a valid id... So everything following that branch didn't end up making it in.Not sure if you experienced anything similar.
-
@julian I haven’t seen that issue so far, but I’ll look into it. I tried to reuse the existing mastodon code for reply fetching as much as possible.. not sure how much more they handle that besides trying the fetch again later in case it’s temporarily not resolving. I don’t think they have as strict of a requirement for valid inReplyTo ids though.
-
@julian I haven’t seen that issue so far, but I’ll look into it. I tried to reuse the existing mastodon code for reply fetching as much as possible.. not sure how much more they handle that besides trying the fetch again later in case it’s temporarily not resolving. I don’t think they have as strict of a requirement for valid inReplyTo ids though.
jesseplusplus@mastodon.social yeah that's the thing. I think the solution for me is to loosen the restriction and handle cases where the object isn't represented locally.
-
@julian I think that makes sense. As the spec progresses, I can see you running into other use cases where ids are referenced in various collections, but you can’t access the object, either because it’s unavailable or due to lack of permissions.
-
@julian @jesseplusplus Works fine for me. There is a difference in collection
typethough (others useOrderedCollection).I've added Decodon to the list of software that publish collections of posts: https://codeberg.org/fediverse/fep/pulls/644
-
@julian @jesseplusplus Works fine for me. There is a difference in collection
typethough (others useOrderedCollection).I've added Decodon to the list of software that publish collections of posts: https://codeberg.org/fediverse/fep/pulls/644
@silverpill awesome, thanks for testing and adding to the list!
I'd love to use `OrderedCollection` here but fell back to following Mastodon's convention for the replies collection. (Mastodon doesn't currently index notes on creation time, so that kind of ordering isn't performant.)
I do return them ordered by id to make it as nice as possible, but this isn't guaranteed to be the creation order depending on when my server saw different replies, so I'm still marking it as unordered.
-
@silverpill awesome, thanks for testing and adding to the list!
I'd love to use `OrderedCollection` here but fell back to following Mastodon's convention for the replies collection. (Mastodon doesn't currently index notes on creation time, so that kind of ordering isn't performant.)
I do return them ordered by id to make it as nice as possible, but this isn't guaranteed to be the creation order depending on when my server saw different replies, so I'm still marking it as unordered.
jesseplusplus@mastodon.social silverpill@mitra.social I think the ordering would be nice but even if an OrderedCollection was sent back I don't know if you can trust the order of items as received.
I wouldn't want to introduce a hard requirement on it being an OrderedCollection, personally.
