@frequency now fully supports FEP-7888 as of yesterday!
Uncategorized
6
Beiträge
2
Kommentatoren
0
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.
