Missing information in slack's payload

gistfile1.md

Issue

Given an 3rd party integrated with outbound webhooks, when a client writes a message mentioning another user (@user) or channel (#channel). The 3rd party receives a message containing the usrer/channel ID but the payload doesn't specify what user/channel that message corresponds to.

E.g. from https://github.com/ernesto-jimenez/slackline/issues/2

The following message

@blanca_tp: check out #general

would be forwarded as

<@U025GEW2Y>: check out <#C024G0DP0>

And since slackline is stateless and the outgoing webhook's payload doesn't include the real names for the user and the channel, it doesn't have a way to compose the apropriate message.

Also, since it doesn't have a token to get the list of users/channels from the API, the only possible workarould would be to store the team_id, user_name and user_id from the messages it processes and try to resolve user names when such links appear. However I don't think it's worth it since:

• That would require slackline to be stateful
• It would only be able to resolve user names from users who have written messages previously
• Channel names would still be broken since slackline doesn't have information about what other channels are in each organization

Assumptions

I obviously don't know the details of your technical solutions, so let me write down my assumptions before I propose a proposal.

• The message formatting of the links is happening on the client and your backend already receives just the IDs
• This is OK for Slack, since links are resolved by your clients and gateways where you already have the IDs do resolve the names
• Messages are barely processed/modified once sent to avoid increasing latency. All processing for indexing/gateways/integrations/etc is done asynchronously with queues to keep latency between clients to the minimum

Proposal

From my point of view as a 3rd party, the ideal would be to receive the message from the following example as follows:

<@U025GEW2Y|blanca_tp>: check out <#C024G0DP0|general>

Given my assumptions, I would probably suggest:

1. Upgrading your clients to start sending real names piped with the IDs
2. Modifying the outgoing webhook to expand IDs for messages from older clients or 3rd party integrations not sending real names

By doing implementing the first point, the outgoing webhook would not need to resolve so many messages.

Hi. I'm having this issue right now with matterbridge: . How did you resolve this in the end?

42wim/matterbridge#138