-
Notifications
You must be signed in to change notification settings - Fork 17
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
Reply content type proposal #22
base: main
Are you sure you want to change the base?
Conversation
Im-Kunal-13
commented
Mar 24, 2023
- Create xip-reply-content-type.md
XIPs/xip-reply-content-type.md
Outdated
replyContent: string | ||
replyMessageId: string | ||
replySenderAddress: string | ||
messageContent: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the content type of the message you're replying to isn't text (like a RemoteAttachment
), or your reply isn't text?
Also what if the messageContentTypeId
doesn't match what the original message's was?
I think if possible we should just work with IDs here. Something like:
inReplyToID: string
where inReplyToID
is the message ID you're replying to. The actual content
could be a specific set of allowed content types like Text
or RemoteAttachment
?
Just pushed some updates here to remove duplicate fields from the proposal as well as move the content of the reply out of the parameters. This allows flexibility to reply with non-text messages (note that text messages are the only type supported by default though, since we can't ensure clients are aware of anything besides those). I've also added a link to a reference implementation. |
In the changes you've made, I noticed that there's only |
You should be able to look up the original message in your local store of messages by the In the case where you don't have access to the original message, you'd need to load older messages until it's found and have a loading UI to indicate that the original message hasn't been loaded yet. I know that's sort of a pain but I think it's the only way we can guarantee message integrity. hopefully a rare case since it'd be best to have a cache of messages locally anyway. |
This case should be rare because most replies are to recent messages (vs 100s of messages ago) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have currently a few XIPs in the pipeline that look very much like this one and suffer from the same issues IMO. I'll elaborate in detail on this particular one, but I'd say most of these comments would apply to all of them.
I've included the specific objections inline. On the more general note I wonder whether content type is the right approach for what I think you want to achieve with this reply type. Is the notion of reply something that applies to any message in any conversation? If so wouldn't it be more suitable to model replies at the protocol level? I think a Rationale section would be advisable here https://github.com/xmtp/XIPs/blob/main/XIPs/xip-0-purpose-process.md#what-belongs-in-a-successful-xip
XIPs/xip-reply-content-type.md
Outdated
|
||
## Abstract | ||
|
||
This XRC proposes a new content type for messages that enriches the messaging experience. It attempts to include only the bare minimum for clients to determine how to display such messages in order to provide flexibility for more rich types in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Abstract should summarize what is being proposed (https://github.com/xmtp/XIPs/blob/main/XIPs/xip-0-purpose-process.md#what-belongs-in-a-successful-xip). I don't think this paragraph does that. I'd expect to see something like This XRC proposes a reply content type that can be used to ...
. Most of what's in this paragraph can be deleted without noticeable loss of information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we have changed it.
951c0fe
|
||
## Motivation | ||
|
||
When it comes to having a comfortable conversation, replying to messages is an absolute no brainer as it gives users the freedom to converse without any miscommunications. In order to provide users a real messaging platform, XMTP needs to provide this capability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I buy this argument. XMTP conversations provide a way to order messages in natural response patterns. A message in a conversation can be presumed to be a response to messages preceding it in a conversation. I'd grant that this is somewhat lose structure and that there may be cases where a more refined substructure would be useful, is that what you're after with this proposal? (threads within conversations?) Could you elaborate more on what you're trying to achieve with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although XMTP conversations provide a way to order messages in a natural response pattern and the response to
preceding message is possible, the problem comes when a users send multiple messages and it is inconvient
for the peer to just simply respond to each one for them one by one in sequence. It definitely doesn't seem
like a good UX when it comes to having seemless 1 on 1 conversations.
How are we suposed to respond to this ? It is a natural instinct to reply to the newest message first so here
comes the problem where the "natural response pattern" doesn't work and so the other user's responses will
seem like jumbled messages and it causes severe miscommunications.
Introducing the functionality to reply to particular messages solves this and lets users freely respond in any
sequence they want and also prohibit any possible miscommunication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I buy this argument. XMTP conversations provide a way to order messages in natural response patterns. A message in a conversation can be presumed to be a response to messages preceding it in a conversation. I'd grant that this is somewhat lose structure and that there may be cases where a more refined substructure would be useful, is that what you're after with this proposal? (threads within conversations?) Could you elaborate more on what you're trying to achieve with this?
Threads within conversations can be a good option but it doesn't seem to have much use case when it comes to 1 on 1 conversations. There are just 2 people in a chat conversing and why would they want to make a completely new thread to separate the conversation from the original one ? Although threads' refined substructure could be pretty great for a group chat as there's substantial use case. In the future, when group chats are introduced to XMTP, thread conversations is definitely a go to feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are great motivational examples. I think this is the right content for the Motivation section.
|
||
## Specification | ||
|
||
Proposed content type: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposed content type: | |
Proposed content type ID: |
} | ||
``` | ||
|
||
The reply message MUST include the following parameters: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is sufficient. How does a codec decode this message if its full structure is not known? How do you decode something if all you know about it is that it should have a string field in it, but the rest is unknown?
The reference implementation suggests that you intend a Reply to be a wrapper around a nested EncodedContent structure. If so, it needs to be explicitly shown here. Also if the intended encoding format is protobuf, the spec should include the protobuf spec of the structures. The spec must spell out in complete detail how things are expected to be encoded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently I misunderstood that parameters
above refer to the EncodedContent parameters. It would probably help to be more explicit. I think showing it here as a field of an object like this is probably not helping with the confusion. Maybe show it in the context of the EncodedContent object?
|
||
The content of the encoded message is an EncodedContent object, serialized in the protobuf format (since we're guaranteed to always have the ability to deserialize that.) | ||
|
||
The content type of the reply's `EncodedContent` MUST be allowed. By default, the only allowed content type is `ContentTypeText`, but additional types can be optionally allowed as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of this allowed type notion. What does make a content type allowed? What is the process of making a type allowed?
|
||
## Backward compatibility | ||
|
||
Clients encountering messages of this type must already be able to deal with messages of an unknown content type, so whatever considerations they're making there should work here too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like there are no backward compatibility concerns with this proposal, then let's just say that with the fewest words possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should strongly encourage users of the Reply content type to use fallbackText
whenever possible, given this is rolling out into a world where most clients do not support replies.
The codecs can help a bit here. If the child content has a fallback, we could bubble that up to make it the fallback of the parent. That way even if your client doesn't support Replies, you can still read the message. If the child content is of type text, we could also make that text the fallback of the parent.
|
||
## Security considerations | ||
|
||
Having different message content structure in content types breaks the uniformity which might be risky, but this is also the case for other content types, since there's no server side validation of message contents (besides size). The same protections we have now would be in place while the same pitfalls we have would still be there as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what you're trying to say here. Content types is a mechanism that allows different content structures in messages. What risks are you referring to?
|
||
```ts | ||
{ | ||
// The ID of the message that is being replied to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the ID of the message? Where does it come from. Are implementors of this XIP free to chose what they want to use as an ID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the ID of the message? Where does it come from. Are implementors of this XIP free to chose what they want to use as an ID?
Here the ID refers's to the id
from the XMTP message wrapper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming you're referring to https://github.com/xmtp/proto/blob/main/proto/message_contents/message.proto#L63. Unfortunately the protocol spec doesn't define the value. I think we'll need to rectify that for this reference to work. If different SDKs compute the ID differently (which likely isn't the case today, but it could be), then the reference will be broken in different contexts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And again, I'm asking the questions because the XIP should answer them.
But if the user loads older messages, how replies will be shown? |
As @nakajima mentioned, we have to show some sort of loading UI till the message we're pointing to is fetched. |
|
||
## Abstract | ||
|
||
This XRC proposes a reply content type that can be used to give clients the functionality of replying to a message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This XRC proposes a reply content type that can be used to give clients the functionality of replying to a message. | |
This XRC proposes a reply content type that allows linking a message with a prior message that it responds to. |
```ts | ||
{ | ||
// The ID of the message that is being replied to | ||
inReplyToID: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the message also contain the encodedContent
field here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently what I missed earlier is that parameters
above refer to the EncodedContent parameters. It would probably help to be more explicit there. And I'd agree that showing it here as a field of an object like this is probably not helping with the confusion. Maybe show it in the context of the EncodedContent object?
I just wanted to note that we added reply content types into the JS SDK here: xmtp/xmtp-js-content-types#11 and we gave a reference implementation in our React playground here: xmtp/xmtp-js-content-types#11 If you have questions, comments, feedback, or concerns please raise them here: https://github.com/orgs/xmtp/discussions/35 |