Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Consider replies as accepted if they're in a post's "replies" collection #3435

Open
tsmethurst opened this issue Oct 14, 2024 · 0 comments
Labels
enhancement New feature or request federation Issue relates to S2S/federation

Comments

@tsmethurst
Copy link
Contributor

Remote Accept processing was added in #3404 which helped with better distribution of approved replies across interaction-policy-aware and interaction-policy-unaware instances, but there's a piece of the puzzle still missing: fetching down a thread based on the "replies" collection.

Currently when a post with an interaction policy set on replies serves its "replies" collection, it will only include replies in the collection that have been accepted by the poster. GtS will dutifully go fetch those replies at the source, but then if the reply is from a non-interaction-policy-enabled instance, it won't have the "approvedBy" URI set, leading it to be dropped by the GtS instance doing the fetching.

To further ease compatibility between GtS and other types of instances that aren't yet interaction policy aware, it would be a good idea to mark replies in a collection as approved, as they wouldn't be there in the collection if they weren't.

Still gotta scratch my head about the best way of doing this, so this is something to play around with for after 0.17.0 is out.

@tsmethurst tsmethurst added enhancement New feature or request federation Issue relates to S2S/federation labels Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request federation Issue relates to S2S/federation
Projects
None yet
Development

No branches or pull requests

1 participant