Open glenn-sorrentino opened 1 month ago
brassy-endomorph
commented
5 days ago Is there a requirement for this to be a modal? Because that would force the user to have JS enabled. Can this just be a second page? Like /submit/success or something?
brassy-endomorph
commented
5 days ago Second, if messages are (almost) always client-side encrypted, there's no point in displaying them as that block will be meaningless to the users. In cases where it's not encrypted, it's dangerous and could be used against them. The message should not be at all displayed back to the user once sent.
brassy-endomorph
commented
5 days ago More questions:
Do we really need the "Received" date field to be displayed back to the submitter? That's another piece of metadata we're leaking if we do, and it also is annoying because of time zones since the DB is default UTC and we'd have to store a full timestamp and then localize it for the user. Or have a tool tip saying "this server's time zone is X." Which would also mean having to have a way to set the server's timezone. This is surprisingly annoying and should probably be in its own ticket to discuss.
glenn-sorrentino
commented
4 days ago Is there a requirement for this to be a modal? Because that would force the user to have JS enabled. Can this just be a second page? Like
/submit/successor something?
We can try as its own page.
glenn-sorrentino
commented
4 days ago Second, if messages are (almost) always client-side encrypted, there's no point in displaying them as that block will be meaningless to the users. In cases where it's not encrypted, it's dangerous and could be used against them. The message should not be at all displayed back to the user once sent.
Sounds good, but the encrypted block should still be visible to the tip line owner.
glenn-sorrentino
commented
4 days ago More questions:
Do we really need the "Received" date field to be displayed back to the submitter? That's another piece of metadata we're leaking if we do, and it also is annoying because of time zones since the DB is default UTC and we'd have to store a full timestamp and then localize it for the user. Or have a tool tip saying "this server's time zone is X." Which would also mean having to have a way to set the server's timezone. This is surprisingly annoying and should probably be in its own ticket to discuss.
We can remove the date from the submitter view, but tip line owners will need to be able to filter messages by date, so keeping them will be important.
brassy-endomorph
commented
1 day ago Changing the case's status sends a predefined reply visible on the message page to both tip line owner and whistleblower.
Who is allowed to set this? Each user? Instance admins?
glenn-sorrentino
commented
1 day ago Whoever receives the message.Message ID: @.***>
Use Cases
Requirements
Whistleblower
https://tips.hushline.app/to/Ungrouped-Headphones-Aluminum-9Tip Line Owner
Mockups
Whistleblower
Step 1: Send a message When an unauthenticated user submits a new message, a modal opens displaying an autogen reply URL.
Step 2: Response Page
Clicking Continue brings the user to the message page where they can see a copy of their message. A badge prominently displays the status.
When a case has been accepted:
Tip Line Owner
Step 1: New Message
A new message is displayed with a blue indicator dot.
Step 2: Message Status
Drilling in to the message shows actions which allow the tip line owner to change its status. Replies are automatically sent when the case status changes.