Page Comparison

...

•  Throttle message input 
  • Max 10 creations per minute
  • Max 50 recipients
•  When adding a new person to a conversation, the new person should get the whole history of the conversation
  • Might be implemented by forwarding ALL the previous messages 
  • OR by concatenating all previous into one new message
•  

  Configure Amazon SES

  • Automated proposal:
    • Reroute bounce and complaints to SNS
    • Have a worker subscribe to the topic via SQS
    • Have a worker disable emails to hard-bounced recipients
    • The worker may email a Google Group to notify us of anything it cannot handle
    • 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) Add methods to send messages according to templates
  • Each individual Message should be stored in its final form.  
  • This design choice would change for very very large notification message volumes.
  • Templates:
    •  Password reset
    •  Welcome
    •  Entity shared
    •  Entity changed
    •  TBD
    

...

Message sender (worker)

•  Extend ObjectType to include a "MESSAGE" type
•  Have DBOMessage extend ObservableEntity
•  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.  Whenever the message sending worker encounters an error:
  •  Send the sender of the message a notification with the summary of delivery failures
  •  Add CloudWatch metrics to count delivery failures
  •  If the message cannot be sent to anyone, mark the sender as the receiver of the message so that it doesn't get reprocessed (i.e. after migration)
•  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

...