[WIP] Sending & Un-sending Likes #35
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mike182uk
reviewed
Sep 6, 2024
| const likeJson = await like.toJsonLd(); | ||
| await ctx.get('globaldb').set([like.id!.href], likeJson); | ||
|
|
||
| await addToList(ctx.get('db'), ['liked'], like.id!.href); |
There was a problem hiding this comment.
🤔 Should this be the ID of the liked object rather than the like activity itself? Then the liked dispatcher returns the objects liked and not the like activities themselves?
Spec says:
This is a list of every object from all of the actor's Like activities, added as a [side effect]
There was a problem hiding this comment.
I did initially think that, but then in the liked dispatcher, fedify would error because it expects a return type of Like[] 😕
I think we need to get fedify updated (and fixed) to handle returning objects from the liked dispatcher - I'll sort that next week
refs https://linear.app/tryghost/issue/AP-292 This follows the same pattern as our other collections and calls reverse to ensure reverse chronological order. At the moment this collection contains Like activities rather than their objects, this is due to types in fedify, eventually we want to have this collection contain the liked objects rather than the Like activities
refs https://linear.app/tryghost/issue/AP-286 These are required for us to generate URL's for Like and Undo objects, which we need for the "like" and "unlike" actions.
refs https://linear.app/tryghost/issue/AP-286 We use the hash of the underlying object to generate the id of the Like activity, this allows us to easily lookup the Like activity when attempting to unlike, rather than searching for it.
refs https://linear.app/tryghost/issue/AP-293 In order to render the feed and inbox we need to know which objects have been liked, this is a naive implementation which doesn't scale to multiple users and should be replaced as party of the database restructure work.
We want to use this in multiple places!
refs https://linear.app/tryghost/issue/AP-286 We want to make sure that the original author is notified of the activity as well as our followers. This is wrapped in guards because it's possible the property doesn't exist.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🍦
We got a few things happening here!
We're adding a liked collection to actors, this is so that we can render a list of the liked content in the Admin. The liked collection functions similar to how we're doing the inbox and outbox, we're storing an array of the ids belonging to the collection.
We've got some basic object dispatchers wired up for
LikeandUndowhich is necessary so that we can generate id's for those objects.The inbox handler has been updating to attached a
likedproperty to theobjectof the activity, this allows us to render the item correctly in the frontend with a filled in heart. I didn't store thelikedproperty on the object, because of concerns of losing the data - e.g. if we start handlingUpdateactivities and we overwrite the object in the DB - we might lose thelikedstatus. There's also the issue of what happens when we support multiple users, we can't store it on the object itself.Adding the
likedproperty is not efficient though - and we really need to rethink storage solutions around this.And of course we have two actions "like" and "unlike" - they are fairly simple - we first check if the object we're trying to like/unlike exists, and 404 if it doesn't. Then we check if we've already performed that action, and 409 if we have. After that we construct the relevant activity, store it, and send it to our followers - we also need to send it to the original author of the object using
attributedTo