matrix-hacks / matrix-puppet-slack

puppet style slack bridge for matrix

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Messages in a Slack thread should be turned into Matrix Replies

thomas-profitt opened this issue · comments

If Matrix is getting a Threads thing, it may be best to wait for that. Personally I prefer Replies anyway.

it requires overriding event id. current time matrix-appservice-bridge(i don't remember well..) always generated that(i don't remember well, but matrix-appservice-node can get the event id & txid, but can't pass from outside wrapper),

so puppet app can't detect thread info before fixing that or store all chat info.

My idea was to use nedb to track slack timestamp and matrix event id relations like the UserStore/RoomStore stuff from matrix-appservice-bridge. Not sure if it would scale at all.

To store this state, we should be able to set arbitrary data in the JSON of a Matrix event, even if it is something like an m.room.message.

We should verify that with the spec, but I know I can create events with entirely arbitrary data, not "messages", and it's facilitated (it's really useful for things like IoT devices, where they should be able to check a room for new events with arbitrary data, and the events could come from anything that can post to the room), so I expect we can enrich the events and store our state there.

If we can do that, we should: storing state in a separate place, like a file or nosql db, would be more brittle.

Some criticism of Slack-style threading in chat from #matrix-puppet-bridge:matrix.org:

original discussion: https://matrix.to/#/!ChuQQIVJvwyJujhNIG:synapse.keyvan.pw/$1550556696173459HSHPs:matrix.org?via=matrix.org&via=synapse.keyvan.pw&via=imninja.net

What I want to say again here: I dislike threading. I think chaining replies is as close as you can get to threading while messages stay sequential, and that messages should stay sequential unless a room's threads are kept separate from the room's messages, which would be confusing. Threading in Slack is a mess; each user uses it, or uses it sporadically, or always replies inline and not in the thread, and the conversation is butchered. When using a platform with threading, you have to think, "do I reply in thread or inline?" Every time, and that makes it directly more complex.