This page is for design considerations around Messaging in Synapse.
Drivers include:
Jira Legacy | ||||
---|---|---|---|---|
|
...
Jira Legacy | ||||
---|---|---|---|---|
|
Features / Considerations
Authorization: Who can send a message to whom?
...
Is it sufficient to allow sending messages to principals (users and Teams) or do we need other targets? E.g. users might "follow" an entity and other users could "notify" all followers of that entity with a message. Or users could "follow" a user and each user can then send a message to all their followers.
Design approaches
- No proxy: Synapse just provides the user an email address. Email is sent OOB. (Might generate temporary email address to hide actual user address.)
- Simple pass through: Message goes through Synapse but Synapse doesn't retain any record.
- Message history. Synapse keeps each message.
- Web mail client: Synapse implements full-blown web-based mail client with folders, trash can, search, sort.
Other systems
- myregence.com simply provides
- in box
- out box ("sent messages")
- display a message
- compose / send a message
- reply
- delete
- discovercard.com is similar to myregence: in box, display, sent messages, compose, NO delete (messages deleted after 30 days)
Strawman design
add message object to synapse. Body is text, no attachments; services for create, read, delete, and various queries (get all messages I've created, get all messages sent to me, optionally filtered)
add message status/annotation for <message,recipient>, esp. "READ", i.e. a user can mark that a message (possibly sent to them as well as others) has been read. Could also implement "DELETE" in this way.
delete old messages (e.g. older than a month)
authorization: any single user can send a message to any other single user, but to send to a Team requires MESSAGE permission on the Team, typically granted only to Team members.
defer:
-messages and in-box quotas,
-"following" entities and users