Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Questions

  • How

    many messages

    should

    a user be allowed to send?
    • 10/min? <<< Let's use this at the preliminary threshold.  Shouldn't apply to Synapse admin's.
    • 1/min?
    • 1/sec?
  • How many recipients can be sent to at once?
    • 10?
    • 50? <<< Let's use this at the preliminary threshold.  Shouldn't apply to Synapse admin's.
    • Infinite?
  • How should we configure Amazon SES? <<< What can be done using readily available SES tools, dashboards and/or alarms?

    • Proposal:
      • Reroute bounce and complaints to SNS
      • Have a worker disable emails to hard-bounced recipients
      • Also flip flags in settings for complaints
      • Store the bounce/complaint in a blob
  • Should users be notified of bounces? <<< Yes, and (1) this is a special case of 'notification', i.e. a Message triggered by a Synapse event, (2) perhaps user can configure email receipt to avoid excessive email from notifications (or other sources)
  • Should some messages be stored as templates? <<< The template should be stored as a properties file. Each individual Message should be stored in its final form.  This design choice would change for very very large notification message volumes.
    • If we start sending out notifications about Entity changes and the like, most of the contents will be similar except for the ID and some small part of the message body. We could conceivably add a flag to the MessageToUser object that tells the client to fill in a messages according to some simple template.  Then we could store the key-values of the template in a blob (perhaps following the same schema as StringAnnotations) along with the message.  
  • When someone is added to a conversation, should they be allowed to see all previous messages within the conversation?  Or should it be the client's job to forward each individual message to the person?  <<< Yes, the new recipient could get the whole history of the conversation.  Might be implemented by forwarding ALL the previous messages or might be implemented by concatenating all previous into one new message. I do think is lower priority.
  • How should we tie Entities to users in terms of notifications?
    • Ownership?  << It might be this.
    • Favorites? << It might be this.
    • Permissions?  << I don't think it's this.
    • Something else?  << It could be a completely new set of services, allowing users to enable/disable notification.  (Could be initialized from Favorites and Owners.)

...

Other TODOs

  •  Throttle message input @mention joseph.wu(max 10 creations per minute) (max 50 recipients)

...

Message sender (worker)

  •  Extend ObjectType to include a "MESSAGE" type
  •  Have DBOMessage extend ObservableEntity and TaggableEntity
  •  Send a change message when a message is created
  •  Subscribe worker to the repo-changes topic
  •  Look for MESSAGE-CREATED changes to process
  •  The worker should always check to see if a message has already been sent, so that messages do not get resent every time the stack changes.
    • A message has been sent if there is a recipient.  The worker is in charge of making sure all sent messages have at least one recipient.  In the case where a user sends a message to multiple recipients, all of which are not visible to the user, then the worker should bounce the message back to the user, along with a bounce message.  This ensures the message has a row in the MessageStatus table.  
  •  Process change of other ObjectTypes (i.e. ENTITY) for notifications
    •  Needs additional state: either a link between ObjectID/Type and messageContent or ObjectID/Type and UserID

...