Reply content type proposal #22

Im-Kunal-13 · 2023-03-24T14:25:09Z

Create xip-reply-content-type.md

nakajima · 2023-03-27T18:00:55Z

XIPs/xip-reply-content-type.md

+  replyContent: string
+  replyMessageId: string
+  replySenderAddress: string
+  messageContent: string


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?

nakajima · 2023-03-27T22:08:47Z

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.

Im-Kunal-13 · 2023-03-27T22:32:25Z

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 inReplyToID and the content of the message.
However in order to show the review of the message we've replied to, we need it's content and typeId

nakajima · 2023-03-27T23:41:41Z

However in order to show the review of the message we've replied to, we need it's content and typeId

You should be able to look up the original message in your local store of messages by the inReplyToID and use the content from that. The trouble with including the content with the reply itself is that there are no guarantees that the contents of that field match the contents of the original message.

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.

yash-luna · 2023-03-28T05:16:25Z

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

This case should be rare because most replies are to recent messages (vs 100s of messages ago)

mkobetic

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

mkobetic · 2023-03-28T14:08:03Z

XIPs/xip-reply-content-type.md

+
+## 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.


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.

Yeah, we have changed it.
951c0fe

mkobetic · 2023-03-28T14:13:08Z

XIPs/xip-reply-content-type.md

+
+## 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.


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?

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.

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.

These are great motivational examples. I think this is the right content for the Motivation section.

mkobetic · 2023-03-28T14:13:21Z

XIPs/xip-reply-content-type.md

+
+## Specification
+
+Proposed content type:


Suggested change

Proposed content type:

Proposed content type ID:

mkobetic · 2023-03-28T14:15:04Z

XIPs/xip-reply-content-type.md

+}
+```
+
+The reply message MUST include the following parameters:


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.

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?

mkobetic · 2023-03-28T14:16:31Z

XIPs/xip-reply-content-type.md

+
+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.


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?

mkobetic · 2023-03-28T14:19:48Z

XIPs/xip-reply-content-type.md

+
+## 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.


It sounds like there are no backward compatibility concerns with this proposal, then let's just say that with the fewest words possible.

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.

mkobetic · 2023-03-28T14:21:19Z

XIPs/xip-reply-content-type.md

+
+## 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.


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?

mkobetic · 2023-03-28T14:25:50Z

XIPs/xip-reply-content-type.md

+
+```ts
+{
+  // The ID of the message that is being replied to


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?

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.

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.

And again, I'm asking the questions because the XIP should answer them.

jsonpreet · 2023-03-28T18:38:49Z

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

This case should be rare because most replies are to recent messages (vs 100s of messages ago)

But if the user loads older messages, how replies will be shown?

Im-Kunal-13 · 2023-03-28T20:57:16Z

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.

mkobetic · 2023-03-29T18:18:19Z

XIPs/xip-reply-content-type.md

+
+## Abstract
+
+This XRC proposes a reply content type that can be used to give clients the functionality of replying to a message.


Suggested change

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.

nmalzieu · 2023-03-30T10:23:52Z

XIPs/xip-reply-content-type.md

+```ts
+{
+  // The ID of the message that is being replied to
+  inReplyToID: string


Shouldn't the message also contain the encodedContent field here?

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?

nplasterer · 2023-07-14T20:34:55Z

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
This should unblock any jsSDK or reactnativeSDK integrators.
We have tasks to add support to kotlin, swift, and flutter soon.

If you have questions, comments, feedback, or concerns please raise them here: https://github.com/orgs/xmtp/discussions/35

Reply content type proposal

2d266a0

Im-Kunal-13 requested a review from jhaaaa as a code owner March 24, 2023 14:25

nakajima reviewed Mar 27, 2023

View reviewed changes

Remove duplicate fields, add reference implementation

6684763

mkobetic suggested changes Mar 28, 2023

View reviewed changes

nakajima mentioned this pull request Mar 28, 2023

Add referencing_message_id to EncodedContent xmtp/proto#65

Closed

Update abstract

951c0fe

mkobetic reviewed Mar 29, 2023

View reviewed changes

nmalzieu reviewed Mar 30, 2023

View reviewed changes

Merge branch 'main' into reply-content-type

63baee5

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reply content type proposal #22

Reply content type proposal #22

Im-Kunal-13 commented Mar 24, 2023

nakajima Mar 27, 2023

nakajima commented Mar 27, 2023

Im-Kunal-13 commented Mar 27, 2023 •

edited

Loading

nakajima commented Mar 27, 2023

yash-luna commented Mar 28, 2023

mkobetic left a comment

mkobetic Mar 28, 2023

ImShivraj Mar 28, 2023

mkobetic Mar 28, 2023

ImShivraj Mar 28, 2023 •

edited

Loading

ImShivraj Mar 28, 2023

mkobetic Mar 29, 2023

mkobetic Mar 28, 2023

mkobetic Mar 28, 2023 •

edited

Loading

mkobetic Mar 30, 2023

mkobetic Mar 28, 2023

mkobetic Mar 28, 2023

neekolas Mar 28, 2023

mkobetic Mar 28, 2023

mkobetic Mar 28, 2023

Im-Kunal-13 Mar 28, 2023

mkobetic Mar 30, 2023 •

edited

Loading

mkobetic Mar 30, 2023

jsonpreet commented Mar 28, 2023

Im-Kunal-13 commented Mar 28, 2023 •

edited

Loading

mkobetic Mar 29, 2023

nmalzieu Mar 30, 2023

mkobetic Mar 30, 2023

nplasterer commented Jul 14, 2023 •

edited

Loading


		## 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.


		## 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.


		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.


		## 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.


		## 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.


		## Abstract

		This XRC proposes a reply content type that can be used to give clients the functionality of replying to a message.

Reply content type proposal #22

Are you sure you want to change the base?

Reply content type proposal #22

Conversation

Im-Kunal-13 commented Mar 24, 2023

Choose a reason for hiding this comment

nakajima commented Mar 27, 2023

Im-Kunal-13 commented Mar 27, 2023 • edited Loading

nakajima commented Mar 27, 2023

yash-luna commented Mar 28, 2023

mkobetic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ImShivraj Mar 28, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkobetic Mar 28, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkobetic Mar 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsonpreet commented Mar 28, 2023

Im-Kunal-13 commented Mar 28, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nplasterer commented Jul 14, 2023 • edited Loading

Im-Kunal-13 commented Mar 27, 2023 •

edited

Loading

ImShivraj Mar 28, 2023 •

edited

Loading

mkobetic Mar 28, 2023 •

edited

Loading

mkobetic Mar 30, 2023 •

edited

Loading

Im-Kunal-13 commented Mar 28, 2023 •

edited

Loading

nplasterer commented Jul 14, 2023 •

edited

Loading