search

matrix-hacks / matrix-puppet-slack

puppet style slack bridge for matrix
47 stars 17 forks source link

Messages in a Slack thread should be turned into Matrix Replies #58

Open thomas-profitt opened 5 years ago

thomas-profitt commented 5 years ago

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

d3m3vilurr commented 5 years ago

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.

twouters commented 5 years ago

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.

thomas-profitt commented 5 years ago

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.

thomas-profitt commented 5 years ago

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.