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

Reactions and replies PoC #405

Open
killthebuddh4 opened this issue Feb 3, 2023 · 0 comments
Open

Reactions and replies PoC #405

killthebuddh4 opened this issue Feb 3, 2023 · 0 comments
Labels

Comments

@killthebuddh4
Copy link
Member

killthebuddh4 commented Feb 3, 2023

Two of the more important features for Receiver v1 are reactions and replies. A "reaction" and a "reply" are technically the same thing, but a "reaction" is a very specific kind of "reply". How do we want to implement this feature? There's four important cases to implement:

A user is creating a reply

This is the most straightforward case and is mostly a UI/UX issue. If a user is replying to a message, we definitely have access to all the relevant data and so can implement this however we'd like.

  • A user sends a reply.

When a user sends a reply, what data needs to be included in the message? Do we duplicate the entire target message within the reply? Do we create some sort of pointer that points to the target message? (The "target" message is the one being replied to.) My thinking about this is that we store the timestamp and id of the target message. The XMTP sdk allows us to query for messages by timestamp, so to query for a reply we could query for a very narrow window around the target message's timestamp.

  • A user receives a message that is a reply.

This case and the previous case are basically the same. In both cases we need to think about what data gets sent with the reply and how we query for the target message.

  • A user clicks on a message that is a reply.

This is mostly a UI/UX consideration but also a bit technical. If someone replies to a message that is very old, do we just query page after page of messages until we come to the target message?

What I would like to see for this issue is some combination of an implementation and/or plan for an implementation. It probably makes sense to attempt to implement the most obvious solution and then see what doesn't work.

@seanonchain seanonchain added P0 Something is on fire or some opportunity is fire. and removed P0 Something is on fire or some opportunity is fire. labels Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants