-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[docs] Message Forwards feature #6818
Conversation
Thanks for feedback peeps. Just FYI this is a DRAFT, but comments obviously welcome. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we suddenly change the way of how notes are done?
can you elaborate what notes are? Do you mean the |
Yeah I mean that. Every else on the docs we use the |
Please keep the numbers, even as someone with very minor sight issues repetitive symbols is not an accessible way to show table footnotes. I don't think anyone is going to care about continuity on this one table when it increases readability. |
The goal is to keep the docs consistent tho, so we'd have to go and change all tables then at some point |
There are already numerous inconsistencies in the docs, I know that is being worked on which is great, but issues like this that affect the legibility and accessibility of the docs are not the hill to die on. |
How does this work privacy wise? Can I prevent users from forwarding messages, especially in DMs? |
We have had large internal debates about this, and privacy is a top concern, but I don't think this is the best forum bring up the concerns. High level though:
|
does this mean that all forwarded messages from private channels (dms, non public guilds, ...) are anonymous without any author attribution? (if i understood correctly, it would contain the original channel & message id, so you would be able to easily access author info for messages forwarded from public servers) i feel like that would kinda cripple the usefulness of forwards. maybe it could contain only the author's display name? since these don't have to be unique, they have full deniability and thus this wouldn't be much different from just sending a screenshot |
yeah, imo forwards are not useful if they don't have any author information, since then they are worse than screenshots. |
Yes. Bit deep into the weeds here, but having view access to the message means being able to see the author. However in the case where you don't have those perms it would be considered a id leak if we included it.
I personally made the same argument (even with comparison to the SS case lol). We were also considering including the display name as meta-data, but decided that v0 would scale back on that for a variety of reasons. The main issue for PII is attribution. I hopefully the announcement will answer more of our privacy concerns. |
If the main issue is PII, why should this feature exist in the first place to be honest. And if we would take PII aside, it'd be a cool feature with author info for moderation cases. But i guess that's out of question. |
I applaud Discord for putting privacy first here, and very much hope there will remain a way to at least opt out of people being able to forward our messages to anyone with undeniable proof of authorship attached to the message. Other things, such as the usefulness of the feature, can be considered, but should not come at the expense of privacy. Otherwise, this feature would be a massive privacy disaster. I would be fine with a display name (and perhaps profile picture, while making sure it doesn't accidentally serve as undeniable proof of authorship by using the exact same URL as the user's profile picture). As for "not the right forum", is there a "right" forum aside from Discord Admins, which only a select few have access to? I am not too concerned right now given the current proposal, but I do believe users have the right to express any potential concerns about such a feature before it's released. |
There's a thread attached to the announcement in DDevs too |
Thanks, I missed that. I only saw an announcement from Discord Admins relayed through a feed in another server. |
Exactly. We don't view member/display name in a DM/guild as PII since it can be changed to whatever you want as your display. We discussed snapshotting these display names and filling them in via UX to expand the forward feature. {
"author": {"name": "snapshotted name here"}
"channel": {"name": "snapshotted channel name"}
} But held back on this approach for the initial experiment launch since there's still some privacy concerns there. |
I cannot figure out this table lint... |
Would it make more sense to move the fields in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To stay consistent in the docs
Looks like you missed putting snowflakes as strings in the example
|
We discussed this approach as well, especially for backwards compat rendering, however abandoned it because of the misunderstandings that could occur. Couple of fields on message are tightly bound to the message; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some wording suggestions but looks good
Add documentation for message forwards. A message forward gives users the ability to send a snapshot of a message in one channel to another channel. - snapshots are immutable, and do not receive updates from the original message (unlike replies) - similar to a REPLY message, a forward is created using a `message_reference` # Examples ## Responses ```json { "author": { "id": 123456789012345678, }, "message_reference": { "type": 1, // FORWARD "message_id": 123456789012345678, "channel_id": 123456789012345678, "guild_id": 123456789012345678 }, "message_snapshot": { "content": "hello world", "embeds": [ // Embed objects ], "attachments": [ // Attachment objects ], } } ```
Determines how associated data is populated. | ||
|
||
| Type | Value | Coupled Message Field | Description | | ||
|---------|-------|-----------------------|----------------------------------------------------------| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only replies have referenced_message - do non-reply messages that use message_reference also use DEFAULT or do they not have a type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if the cases where message_reference
are used outside of REPLY message types, but yes they would use MessageReference.Type.DEFAULT
. At least for now since that's the backwards compatible value for the field. Using FORWARD
in those references would not be respected at this stage.
This reverts commit 57a5077.
Add documentation for message forwards. A message forward gives users the ability to send a snapshot of a message in one channel to another channel. - snapshots are immutable, and do not receive updates from the original message (unlike replies) - similar to a REPLY message, a forward is created using a `message_reference` [DDevs #api-announcement](https://canary.discord.com/channels/613425648685547541/697138785317814292/1233463756160503859) - thread there # Examples ## Creates ```json { message_reference": { "type": 1, // FORWARD "message_id": "123456789012345678", "channel_id": "123456789012345678", "guild_id": "123456789012345678" }, } ``` ## Responses ```json { "author": { "id": 123456789012345678, }, "message_reference": { "type": 1, // FORWARD "message_id": "123456789012345678", "channel_id": "123456789012345678", "guild_id": "123456789012345678" }, "message_snapshots": [ { "content": "hello world", "embeds": [ // Embed objects ], "attachments": [ // Attachment objects ] } ] } ```
This reverts commit 57a5077.
Add documentation for message forwards.
A message forward gives users the ability to send a snapshot of a message in one channel to another channel.
message_reference
DDevs #api-announcement - thread there
Examples
Creates
Responses