Readable names in text dumps: Better identifiers?

[mootari]

Edit: Implemented in #132

I just gave the text output format a try and noticed that the dumps display the first part of a user's email address as a readable identifier. Unfortunately that fails to work if users have addresses at @ own domains, e.g. "info@example.com" or "contact@example.com". deprecated user name. Example:

> contact [THEUSERID] @ 08/05/2022 12:33:22 Z:
Yeah, I've seen his intro
Doesn't look like he's active though

I have no immediate use for the text format, so I've chosen to create this discussion instead of an issue. My recommendation would be to either display the email address in full, or to partially redact it (as is done in Monorail, Chromium's bug tracker):

cont...@example.com

For reference, this is the monorail implementation: https://chromium.googlesource.com/infra/infra/+/0af18ef4/appengine/monorail/framework/framework_bizobj.py#175

Edit: These were actually user names, not emails. The current recommendation is to show display names instead.

[rusq]

Hey @mootari, thanks for the feedback!

It uses the username (user.Name), not email. To be more precise, to determine the "Sender" name it uses this logic: https://github.com/rusq/slackdump/blob/master/internal/structures/user_index.go#L40

I don't think I ever used user emails anywhere in formatted output.

[mootari]

In slack-go/slack the display name is part of UserProfile.

Edit: Luckily the profile is already present in users.json, so additional API calls shouldn't be necessary.

[rusq]

Hahaha, deprecated since 2017 and still in use! Yeah, probably better switch to display names, to avoid unfortunate surprises in future

[rusq]

Ran some experiments with display and user names, and as a result switched to using RealNames. DisplayName can be empty, and that produces not very pleasant output

#132

[mootari]

What about defaulting to DisplayName, but falling back to RealName if it's empty? I think that's also how Slack does it?

[rusq]

Good idea, done!