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.

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

XIP-14: Conversation context metadata schema #14

Merged
merged 15 commits into from
May 15, 2024
Merged
99 changes: 99 additions & 0 deletions XIPs/xip-10-brandinfo-schema.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
---
xip: 10
yash-luna marked this conversation as resolved.
Show resolved Hide resolved
title: Brand info schema in conversation metadata
description: Schema to enable standardized sharing of brand information as it relates to conversationId
author: Yash Lunagaria (@yash-luna)
status: Review
type: Standards Track
category: XRC
created: 2023-01-31
---

## Abstract

This XIP proposes a schema for sharing brand information as it relates to `conversationId`. A standard way to represent this information in conversation `metadata` will enable different front-ends to surface the context captured by `conversationId` in a consistent, user-friendly manner while still affording clients design and UI flexibility.
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

## Motivation

The SDK API currently accepts a unique `conversationId` per address pair and allows `metadata` to be set as well. Today, different apps use these parameters in different ways and therefore other apps may not know how to render the `conversationId` appropriately within the UI to reflect the corresponding brand. We propose a schema to standardize the use of conversation `metadata` for the purpose of client-side brand expression stemming from the `conversationId`. The `metadata` field may include other non-standard (or future standard) properties.
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

Note that the schema is only applicable when setting a non-null `conversationId`. If `conversationId` is null, the SDK does not allow setting `metadata`.
yash-luna marked this conversation as resolved.
Show resolved Hide resolved
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

## Specification

Proposed `brandInfo` schema in conversation `metadata`

```json
{
conversationId: 'mydomain.xyz/abc/qrs',
metadata: {
brandInfo: {
displayName: 'My Company',
profileImage: 'mydomain.xyz/assets/myimage.png,
primaryColor: '#ffffff',
}
}
}
```
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

Example `brandInfo` implementation for a chat app named Galaxy

```json
{
conversationId: 'galaxy.chat/dm/uniqueIdentifier',
metadata: {
brandInfo: {
displayName: 'Galaxy',
profileImage: 'galaxychat.com/assets/logo.png,
yash-luna marked this conversation as resolved.
Show resolved Hide resolved
primaryColor: '#6865B8',
}
}
}
```

The `profileImage` file is encouraged to meet the following criteria:
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

- Aspect ratio: 1:1
- Minimum resolution: 100x100
- Maximum resolution: 800x800
Copy link
Contributor

Choose a reason for hiding this comment

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

If these are externally hosted, why such a low maximum?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Based on Darick's suggestions. Thoughts on increasing min resolution @darickdang?

Choose a reason for hiding this comment

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

@neekolas Since the image would be used in avatar-like settings (or to complement an avatar), I looked at popular services/libraries such as Gravatar (minimum size 1px) and Libravatar (minimum size is 80x80) standards in addition to Apple's Human Interface Guidelines of having a minimum toucharea of 44x44 (and then I doubled that to add @2x support as the minimum) to create the number you see here.

Open to making it bigger though. Not that strong of an opinion from my end here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I just wonder if some apps are going to want a clickable/zoomed view of app icons. Or an extra large icon. Maybe that's not a real concern here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if it might help to include a mockup of a UI showing how the displayName, profileImage, and primaryColor might be used? While the profileImage might be more obvious, people might be curious about where the displayName and primaryColor might be used? An image might also really drive home the value!

And is the idea now that we don't need to use only the conversationId as conversation label text?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding a sample UI is such a good idea @jhaaaa!

Yes, with a conversationId like 'lens.dev/dm/...' there isn't a shared understanding of how to render it? Should the UI display 'Lens', 'lens.dev', or the complete conversationId? The displayName makes it explicit

Choose a reason for hiding this comment

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

Great call @jhaaaa. Will look at making an example.

- Format: .PNG, .WEBP

The `primaryColor` is a hex color code.

## Backwards Compatibility
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

Existing conversations will not be affected by the adoption of the new schema; only conversations created after the new schema is finalized will follow the updated schema.
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

To maintain backwards compatibility, clients may consider rendering popular but older schemas (such as Lens), present in conversations created before the finalization of this XRC, in a manner consistent with their updated schema that follows this XRC.
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

Old Lens schema:

```json
{
conversationId: lens.dev/dm/${memberA}-${memberB}
metadata: {}
}
```

New Lens schema

```json
{
conversationId: 'lens.dev/dm/${memberA}-${memberB}',
metadata: {
brandInfo: {
yash-luna marked this conversation as resolved.
Show resolved Hide resolved
displayName: 'Lens',
profileImage: 'lens.xyz/assets/myimage.png,
primaryColor: '#ffffff',
}
}
}
```

## Security Considerations
yash-luna marked this conversation as resolved.
Show resolved Hide resolved

The metadata field can be spoofed by malicious apps to display Names and Images that degrade the user experience and are harmful to the brand’s perception. A mechanism for apps to sign messages and related metadata can enable front-ends to verify if the signature is from a credible source in order to prevent such spoofing. An affordance for client verifiability is under consideration.
Copy link
Contributor

Choose a reason for hiding this comment

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

The invitation is encrypted and authenticated using the sender & recipient keys. So the metadata must have been created by one of the parties if the invitation is successfully unsealed (https://github.com/xmtp/proto/blob/main/proto/message_contents/invitation.proto).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

While invitations are authenticated by sender & recipient, setting metadata and conversationId is usually abstracted away from users so front-end clients end up making the decision for what these fields carry.

Spoofing example: A (malicious) client Yash uses to message Martin could set conversationId to a 'lens.dev/...' and set brandInfo that doesn't represent Lens.

Today convoID/metadata<>app/protocol/brand mapping is not verifiable, and therefore relies on good behavior.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see, I misread this section. This is however a more general concern that currently apps have complete access to a user's XMTP identity/keys, so a users must necessarily trust the app they are using in all regards not just this particular aspect. It may still be worth mentioning here, but I'm less sure about what the solution should be. Some amount of trust between the user and the app may always be necessary.

yash-luna marked this conversation as resolved.
Show resolved Hide resolved

## Copyright

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