*target* content type exploration

[killthebuddh4]

Given this prior discussion, the target content type seems to be a good opportunity for the community to work out its first potential XRC. The target content type is essentially a message with a bipartite payload: a reference to another message + a nested payload. So in TypeScript, for example, we'd have a message payload whose type is something like this:

interface Target {
  targetMessageId: string;
  payload: Payload;
}

A few notes/questions to get things started:

• Is "target" an ideal name for the content type? I was a little bit confused at first because I think of the message referenced via targetMessageId as the "Target" or "Parent" rather than the message that includes the reference. Along these lines a name like "Child" might work?
• Should we allow multiple targets or maybe even patterns? I.e. should we allow a single message to reference an array of messages? This would be useful for something like "mass delete" (I'm imagining wanting to "delete" an entire message history).
• Does the existing Composite codec support a "Target" content type implementation out of the box? The particular case I'm wondering about is:
  • A client is initialized with the codecs [Text, Composite, Target]
  • A client receives a Target message. The Target message's payload is encoded with some other content type, say OtherType.
  • Does the client reject this message? Partially reject it?

I'm sure there's plenty of details I've missed or haven't included, thoughts anyone?

[galligan]

@killthebuddh4 This is awesome, and thanks for proposing this! This kind of thing is a solid foundation on which to build other types like Reply, Reactions, deletions, etc.

Is "target" an ideal name for the content type? I was a little bit confused at first because I think of the message referenced via targetMessageId as the "Target" or "Parent" rather than the message that includes the reference. Along these lines a name like "Child" might work?

"Target" would be a more universal way of stating a relationship or intent with another message object. Using "Parent" and "Child" would imply a hierarchical relationship, which may be limiting.

For instance, what if there was an "update" type of message…which would target an older message, and "update" it with new information. In that case—which is the parent, and which is the child?

Does the existing Composite codec support a "Target" content type implementation out of the box?

This would be a great question for @mkobetic

Should we allow multiple targets or maybe even patterns? I.e. should we allow a single message to reference an array of messages? This would be useful for something like "mass delete" (I'm imagining wanting to "delete" an entire message history).

If composite works with target, then perhaps multiple targets wouldn't be necessary to include in the type primitive, and one could just use a composite.

[saulmc]

Agreed, but developers can be instructed to use inline emojis (which are supported via text) or a hypothetical emoji reaction type.

Fwiw iMessage only allows one rich content type/attachment per message. The message applet tray goes away when I add a photo and vice versa when I add something like an audio clip.

[mkobetic]

Fair enough, my examples may not be great illustrations of the point I'm trying to make. I don't have a clear cut argument, but I feel that more specific, well targeted content types will be easier to use and more popular than very generic ones used in different contexts.

[neekolas]

I'm with @mkobetic. Overloading the composite type to include the target would have a bunch of very different use-cases using the same structure, and would risk having different clients handling the same messages very differently.

[galligan]

I'm with @mkobetic. Overloading the composite type to include the target would have a bunch of very different use-cases using the same structure, and would risk having different clients handling the same messages very differently.

I can see this argument. And in the context of a reaction or reply type, it would seem that target or messagePointer would just be a part of that.

So would this mean that target or messagePointer should just become a part of the base spec?

[mkobetic]

So would this mean that target or messagePointer should just become a part of the base spec?

Do you mean part of the Composite spec? I wouldn't do that, I'd be inclined to create dedicated content types for particular use cases with the target/messagePointer field included in that. If it turns out that bunch of them look and work very much the same way, then maybe consider reusing the type for different things. But I'd be careful there because I think content type is not just about structure but also about the semantics.

[killthebuddh4]

@galligan, I think that's a good point about avoiding a necessarily hierarchical relationship between messages. @saulmc, Nick, and I had a brief conversation earlier and may have come up with a name that satisfies each of the constraints: MessagePointer. We considered the name "Pointer" as well, but Nick brought up the concern that there could be a use-case for pointers to non-message objects, and we might want to make the use-case for this particular content type more specific. What do you think?

[galligan]

@killthebuddh4 makes sense. Seems like MessagePointer would do the job and be just a bit broader in potential use cases.

[mkobetic]

I'm probably missing some parts of the picture, but I feel that the target type as proposed is a bit too abstract. What are the various examples that we'd want to use it for? Do all those examples want the same content structure or would they be better off with different, more specific content types?

[neekolas]

One case against putting the field into all the different content types is that it is much harder to update the wrapper (if we want to support new types of pointers for example). All the content types that include the field would have to be updated, and they will be maintained by a range of different developers.

That would be a positive if we think that this kind of change without any opt-in from the child content type developers might lead to incompatibilities, but at least in the case of "threaded replies" it feels quite safe.

[killthebuddh4]

I think this discussion is related to a general question that recurs over and over in software: "When do I abstract a solution to a recurring problem?". I think I might agree with @mkobetic that it is unclear that the abstraction (a MessagePointer content type) actually adds value over just implementing the specific content types that we need.

On the other hand, I think more generic content types like MessagePointer would allow for higher resolution configuration on the client end. Clients could support different combinations of the wrapper content types and wrapped content types, or something like that. My intuition says this is something we worry about in the future though.

As a rule of thumb I think implementing specific cases and generalizing when necessary is a good idea.

[killthebuddh4]

A couple more thoughts on this: I think the points that @mkobetic and @neekolas are both poignant and the underlying question is which tradeoff is going to actually come into play. This might be a case where we just can't know until it happens and we should just go build something? :)

[killthebuddh4]

Sorry, one last note: I think we're going to very soon implement reactions in Relay, I think I'm going to go with the less abstract route for that. We'll probably implement replies not too long after that.

[saulmc]

As a rule of thumb I think implementing specific cases and generalizing when necessary is a good idea.

I am not a software engineer, but the CTO of my previous startup taught me about the Rule of Three:

It’s simple: when reusing code, copy it once, and only abstract the third time. This is the “rule of three.” The principle behind the rule is that it’s easier to make a good abstraction from duplicated code than it is to refactor the wrong abstraction.

So I'll be interested to see how you feel about abstracting MessagePointer after implementing Reaction and then copying the pattern once for Reply!

[derekbrown]

my two cents on terminology: target implies that the implemented interface is performing an action on the targeted message. this may make sense for deletions and the like...but not necessarily for replies, reactions, etc. there's no mutation required.

if the desire is to both avoid hierarchy and have a more universal implementation, going with something simple like relatedMessageId is probably better imo, and the payload could define the relationship. 😏

interface Related {
  relatedMessageId: string;
  payload: Payload;
}

per @killthebuddh4 original post, i do think that allowing for multiple related/target messages will be desirable, but this might get tricky without a merkle or something similar to guarantee data integrity?