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 - thread there

Examples

Creates

{
    "message_reference": {
        "type": 1,  // FORWARD
        "message_id": 123456789012345678,
        "channel_id": 123456789012345678,
        "guild_id": 123456789012345678
    },
}

Responses

{
    "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
        ],
    }
}

Thanks for feedback peeps. Just FYI this is a DRAFT, but comments obviously welcome.

Why do we suddenly change the way of how notes are done?

can you elaborate what notes are? Do you mean the *? after 4 * I thought it was very hard to distinguish/count at a glance.

Yeah I mean that. Every else on the docs we use the * symbols to create notes, it's weird if one place suddenly uses numbers.

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 CC @colinloretz

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?

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. There will be an announcement soon about this feature which should answer some questions.

High level though:

• if you can view it you can forward it (we limit some content based on UX/technical viability)
  • how I think of it is. If you can see it, you can copy/snapshot it.
• ability to prevent forwards in a channel are in discussion
• author is explicitly removed from snapshot for privacy reasons

author is explicitly removed from snapshot for privacy reasons

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.

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)

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 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.

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. Again not the right forum.

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. I.e. someone sends scam or other stuff in dms to a member, and the member could forward it 1:1 to the moderation team in a ticket.

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.

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.

therwise, 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).

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. e.g. the snapshot payload would look like this:

{
  "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 message_snapshot to the top level? On a data level, that would make it seem as if the forwarding user was sending the message themselves. That matches my mental model of forwarding, but maybe the design team are going to convey a different mental model when they do UI?

Looks like you missed putting snowflakes as strings in the example

{
    "message_reference": {
        "type": 1,  // FORWARD
        "message_id": "123456789012345678",
        "channel_id": "123456789012345678",
        "guild_id": "123456789012345678"
    },
}

Would it make more sense to move the fields in message_snapshot to the top level? On a data level, that would make it seem as if the forwarding user was sending the message themselves. That matches my mental model of forwarding, but maybe the design team are going to convey a different mental model when they do UI?

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; channel, author, mentions, attachments, flags, etc. If we lifted the message these fields would clobber and it would be impossible to predict which one should win in a consistent fashion. That aside if we decide to introduce author this approach would not work.