kamax-matrix / matrix-appservice-email

Matrix <--> E-mail Bridge
GNU Affero General Public License v3.0
39 stars 11 forks source link

Mailing list subscription type (Plumbed rooms) #3

Open maxidorius opened 7 years ago

maxidorius commented 7 years ago

Currently, the bridge treats each user individually when processing events, regardless of which room users are in.
Incoming e-mails require a token and an active subscription to accept incoming bridge message which will be posted in Matrix.
Therefore, it is not possible to simulate the behavior of a mailing list, where people can just subscribe with their e-mail address and reach other people also subscribed to that list.

This feature will map an e-mail address to a Matrix room and forward messages between the two. Only Plumbed functional mode will be supported: The bridge has ownership of the mailing list, which means it has the responsibility to direct forward Matrix messages to subscribed e-mail users.

Once Matrix has a way to support some kind of thread mechanism within a single room, Portal rooms will be considered.


Edit: Include comments feedback and only support Plumbed rooms.

turt2live commented 7 years ago

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

maxidorius commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

turt2live commented 7 years ago

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:

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

maxidorius commented 7 years ago

Edited the issue description to include our conversation.