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.

Sign up for GitHub

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

Jump to bottom

Reply content type proposal #22

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Reply content type proposal #22

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2d266a0
Reply content type proposal
Im-Kunal-13 Mar 24, 2023
6684763
Remove duplicate fields, add reference implementation
nakajima Mar 27, 2023
951c0fe
Update abstract
Im-Kunal-13 Mar 28, 2023
63baee5
Merge branch 'main' into reply-content-type
jhaaaa May 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions XIPs/xip-reply-content-type.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
Copy link
Contributor

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.

Copy link

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.
Copy link
Contributor

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?

Copy link

@ImShivraj ImShivraj Mar 28, 2023 •
edited
Loading

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.

image

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.

image

Copy link

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.

Copy link
Contributor

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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Proposed content type:
Proposed content type ID:


```js
{
authorityId: "xmtp.org"
typeId: "reply"
versionMajor: 0
versionMinor: 1
}
```

The reply message MUST include the following parameters:
Copy link
Contributor

@mkobetic mkobetic Mar 28, 2023 •
edited
Loading

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.

Copy link
Contributor

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?


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
Copy link
Contributor

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?

}
```

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.
Copy link
Contributor

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.

Copy link
Contributor

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.
Copy link
Contributor

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?


## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).