Mailing list subscription type (Plumbed rooms) about matrix-appservice-email

[turt2live]

Mailing lists tend to have more than one conversation going on at once. How would this be handled on the matrix side?

[maxidorius]

The same happens in Matrix rooms - should we really try to split?
I don't have an idea if and how we should handle it anyway, feel free to share your ideas on the matter!

[turt2live]

Without matrix supporting threading, and without adding some AI to determine where a message is directed, I'm not sure it's reasonably possible to have the bridge reply to the correct thread on the mailing list. Default could be, for now, to just reply to the most recent message?

[maxidorius]

Good point. Maybe we should have a main read-only room where the first message of each new thread ends up with a link to join a specific room for those who wish to participate, where the full history can be found?

I wouldn't like a system where you are automatically invited to join new rooms for each new thread, it would be an annoyance more than anything (I think?)

[maxidorius]

But that doesn't work either - can't have a new topic created on the Matrix side if the room is read-only...

[turt2live]

Could still post a read only room as the bridge if the bridge bot (@_email:whatever.com) sets the speak permission to something other than 0, then each message coming into the room would need a permissions check first. So this would be the flow for a new message:

• Join room, if required
• Have bridge bot promote the new user, if required
• Send message

I'd say inviting might be a bit spammy. Possibly have some way to support the matrix user indicating "please invite me" or "just leave me alone"? An option could also be just dumping some text at the end of the message: Join #_some_weird_alias:server.com to continue the conversation

[maxidorius]

@turt2live and how would you see a Matrix user initiating a new thread?

If we follow the logic of dedicated rooms per thread, that would mean its first message can either be the subject/topic, or the content, which will trigger a new room creation and invite from the AS user.
At this point, the user would need to either set a room topic, or write a first message in the new room.
Overall, far from user-friendly.

Another approach would be to include the last X messages in any outgoing e-mail, so people can actually have some context to help with the lack of thread.

[turt2live]

Special aliasing for the room, or a command to the bridge.

Aliasing
This is a bit more complicated and doesn't make sense from a user perspective, but may still work out. If aliases for threads are namespaced to something like #_email_wlandiscuss_somethreadid, then a user could join a room on their own, such as #_email_wlandiscuss_cool_thing. The bridge would create the room, and leave the room for discussion. Maybe an m.notice to say "Use !subject <subject> to set the subject for this thread.", preventing use of the command after the first message has been sent.

Command
Something like !newthread <mailing list> <subject> in a 1:1 to the bridge bot. Would invite the user to the new room and leave a reply to the command saying something like "Join #whatever to start the conversation"

[maxidorius]

@turt2live So overall, the real issue is with portal rooms, since you must adapt to a mailing list structure which, until threads are implemented in Matrix, is just not compatible with IM style.

On the other hand, for plumbed rooms, it can be clearly communicated that people subscribe to a Matrix room, in the style of a mailing list, reusing the existing bridge mechanism.
This will not replace an actual mailing list and they will be notified for every message where everything happens on a single "thread".

I think we should start with that. What do you think?

[turt2live]

That sounds like a good start. Hopefully matrix adds threading soon :)

[maxidorius]

Edited the issue description to include our conversation.