Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

This page is for design considerations around Messaging in Synapse.

 

Drivers include:

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

 

Features / Considerations

Authorization:  Who can send a message to whom?

Event notification:  Is this just for messages initiated by users, or should it support notification of events in Synapse (e.g. entity deletion, entity sharing...)

Should we support attachments (might be synapse file handles)?   mark-up/down?

Should Synapse keep a record of messages sent?

Should Synapse provide each user an in-box (and other boxes, and the ability to move messages between boxes, delete them)?

Should Synapse enforce quotas? (# messages sent/day, bytes sent/day, and/or in-box size limit)

Should Synapse implement filters (e.g. the ability to block users from sending messages or to block/route/delete based on keywords found in messages)?

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 Alternatives:

  1. No proxy:  Synapse just provides the user an email address.  Email is sent OOB.  (Might generate temporary email address to hide actual user address.)
  2. Simple pass through:  Message goes through Synapse but Synapse doesn't retain any record.
  3. Message history.  Synapse keeps each message.
  4. Web mail client:  Synapse implements full-blown web-based mail client with folders, trash can, search, sort.

 

Existing 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)

 

A possible design

include:

  • add message object to synapse having subject, message, to, from, where 'to' is a list.  Body is text, but might contain HTML or other formatting, but no attachments; services for create, read, delete, and various queries (get all messages I've created, get all messages sent to me, optionally filtered by status – see next line)
  • 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 (i.e the message is 'deleted' for a user though it is archived n the system).
  • 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 SEND_MESSAGE permission on the Team, typically granted only to Team members.
  • users controls whether message is sent by email or whether they go to their 'in box' to see messages (3rd option would be to be notified by email to go to Synapse in-box).  (Note, this choice might go in a 'message setting' object for the user, later extended for other settings, e.g. a 'blocked sender' list).

defer: 

  • quotas on messages and in-box size
  • notification of system events (e.g. deleting an entity) / "following" entities and users
  • blocking senders
  • distribution to groups other than individuals and teams
  • message attachments
  • "boxes" other than in-box and sent-messages (which are implicitly defined by 'from' and 'to' in the message itself)

 

 

 

  • No labels