- the "type" of the matrix id, used to update things properly next time. for example, whether it is the message text or an attachment. alternatively, whether it is a primary or supporting event for the discord message, primary being message content and supporting being embeds or attachments or etc.
There needs to be a way to easily manually trigger something later. For example, it should be easy to manually retry sending a message, or check all members for changes, etc.
## Transforming content
1. Upload attachments to mxc if they are small enough.
2. Convert discord message text and embeds to matrix event.
1. Convert discord mentions, names, channel links, message links, and emojis to intermediate formats.
2. Convert discord text to body.
3. Convert discord text to formatted_body using custom discord-markdown npm module.
2. Create channel rooms for the channels. Store the channel-room ID relationship in the database. (Probably no need to store parent-child relationships in the database?)
3. Send state events to put the channel rooms in the space.
Need to backfill any messages that were missed while offline.
After logging in, check last_message_id on each channel and compare against database to see if anything has been missed. However, mustn't interpret old channels from before the bridge was created as being "new". So, something has been missed if:
- The last_message_id is not in the table of bridged messages
- The channel is already set up with a bridged room
- A message has been bridged in that channel before
(If either of the last two conditions is false, that means the channel predates the bridge and we haven't actually missed anything there.)
For channels that have missed messages, use the getChannelMessages function, and bridge each in turn.
Can use custom transaction ID (?) to send the original timestamps to Matrix. See appservice docs for details.
- Consider using the _ooye_bot account to send all webhook messages to prevent extraneous joins?
- Downside: the profile information from the most recently sent message would stick around in the member list. This is toleable.
- Otherwise, could use an account per webhook ID, but if webhook IDs are often deleted and re-created, this could still end up leaving too many accounts in the room.
- The original bridge uses an account per webhook display name, which does the most sense in terms of canonical accounts, but leaves too many accounts in the room.