Allow Participant Communication

[Strehk]

Feature Description

Problem or Use Case

No response

Proposed Solution

No response

Alternative Solutions

No response

Priority

High (Would significantly improve workflow)

User Type

End User (Delegates/Participants)

Related Areas

• User Interface/UX
• Authentication/Authorization
• Data Management
• Communication/Messaging
• Workflow/Process Management
• Reporting/Analytics
• Integration/API
• Performance/Optimization
• Mobile Experience
• Accessibility

Additional Context

No response

[ahsanfarooq210]

Hi @Strehk. I want to work on this. can you assign this to me?

[Strehk]

Hey @ahsanfarooq210, great! Thanks! A few thoughts:

1. Here is the diagram translated and a little better explained. I left the issue form description open, because I planned on implementing it myself, but I am happy to assign you anyways!

   

2. The idea is, to have a very simple, tracable and privacy-focused way for delegates to contact each other. This means:

   • They should select the other user by their conference role without seeing User Info like name, email, etc.. Where we need individual identification (e.g. for a non-state-actor that has more than one delegate but is not assigned to a certain committee and therefore not uniquely identifiable by their role, we should use acronyms of their names.
   • There is no "chat". The interface is just a simple form like a webmail interface. Subject, Message, recipient. The trick is, that the link to respond in the mail already contains search params that prefill the form for the respons.
   • To recieve mail, users must first go to account settings and activate this. This will be another field on the User Database enity. To nudge users to activate this, there should be a warning that they cannot recieve messages until this option is enabled
   • Think of all of this as a plain Email-Wrapper, that is basically just there to hide the actual email of the users from one another.

3. Please have a look at this PR (especially the emailService.ts), which soon will be merged into main. The transactional emailing is already prepeared there, so that you can use these functions for the mailing. Please create a template in German for now (or leave this to us), because we dont really have a way to track locales accurately right now.

4. If you have any ideas to make this feature better without introducing the overhead of a chat-app, we are very happy to here your thoughts!! We ruled out the possibility of anonymous emails (like github allows you to hide your private email with a relay) for a couple of reasons.

5. Timing: We want this feature implemented quite quickly, best case within the next 2-3 Weeks. If that is out of scope for you right now, I would suggest something else. And keep in mind that this is quite a big scope. We are also happy, if you just implement a part of this issue ;)

Let me know if you have any questions!