From 2d266a0d509888dd56c6760f4a7885953fa4dadc Mon Sep 17 00:00:00 2001
From: ImKunal13z <2002kunalmondal13@gmail.com>
Date: Fri, 24 Mar 2023 19:52:09 +0530
Subject: [PATCH 1/3] Reply content type proposal

---
 XIPs/xip-reply-content-type.md | 61 ++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 XIPs/xip-reply-content-type.md

diff --git a/XIPs/xip-reply-content-type.md b/XIPs/xip-reply-content-type.md
new file mode 100644
index 0000000..8696faa
--- /dev/null
+++ b/XIPs/xip-reply-content-type.md
@@ -0,0 +1,61 @@
+---
+xip: 
+title: Reply Content Type
+description: Content type for reply messages
+author: Kunal Mondal
+status: Draft 
+type: Standards Track
+category: XRC
+created: 2023-03-24
+---
+
+## 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.
+
+## Specification
+
+Proposed content type:
+
+```js
+{
+  authorityId: "xmtp.org"
+  typeId: "reply"
+  versionMajor: 0
+  versionMinor: 1
+}
+```
+
+The reply message MUST include the following parameters:
+
+Adding info about the message we’re replying to (it’s content type id, content, sender address and the message id). 
+
+```ts
+{
+  replyContentTypeId: string
+  messageContentTypeId: string
+  replyContent: string
+  replyMessageId: string
+  replySenderAddress: string
+  messageContent: string
+}
+```
+
+The content of the encoded message is arbitrary data. It's up to clients to use the replyContentTypeId , messageContentTypeId ,replyContent , replyMessageId , replySenderAddress , messageContent to determine how to render the message.
+
+## 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.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

From 66847639a042c8bbc71a5f056fbf5febcde82bfe Mon Sep 17 00:00:00 2001
From: Pat Nakajima <patnakajima@gmail.com>
Date: Mon, 27 Mar 2023 15:02:45 -0700
Subject: [PATCH 2/3] Remove duplicate fields, add reference implementation

---
 XIPs/xip-reply-content-type.md | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/XIPs/xip-reply-content-type.md b/XIPs/xip-reply-content-type.md
index 8696faa..d8d7b1e 100644
--- a/XIPs/xip-reply-content-type.md
+++ b/XIPs/xip-reply-content-type.md
@@ -32,25 +32,24 @@ Proposed content type:
 
 The reply message MUST include the following parameters:
 
-Adding info about the message we’re replying to (it’s content type id, content, sender address and the message id). 
-
 ```ts
 {
-  replyContentTypeId: string
-  messageContentTypeId: string
-  replyContent: string
-  replyMessageId: string
-  replySenderAddress: string
-  messageContent: string
+  // The ID of the message that is being replied to
+  inReplyToID: string
 }
 ```
 
-The content of the encoded message is arbitrary data. It's up to clients to use the replyContentTypeId , messageContentTypeId ,replyContent , replyMessageId , replySenderAddress , messageContent to determine how to render the message.
+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.
 
+## Reference implementation
+
+- [PR implementation for the JS SDK](https://github.com/xmtp/xmtp-js-content-types/blob/baed02476cd94c6ceef24c107a86a162efaec678/reply/src/Reply.ts)
 
 ## Security considerations
 

From 951c0fe63dc77faf09ee0d4e47acee3eb6345d7b Mon Sep 17 00:00:00 2001
From: Kunal <2002kunalmondal13@gmail.com>
Date: Wed, 29 Mar 2023 03:03:59 +0530
Subject: [PATCH 3/3] Update abstract

---
 XIPs/xip-reply-content-type.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/XIPs/xip-reply-content-type.md b/XIPs/xip-reply-content-type.md
index d8d7b1e..082bcf5 100644
--- a/XIPs/xip-reply-content-type.md
+++ b/XIPs/xip-reply-content-type.md
@@ -11,7 +11,7 @@ created: 2023-03-24
 
 ## 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.
+This XRC proposes a reply content type that can be used to give clients the functionality of replying to a message.
 
 ## Motivation