# BasicMessage Replacement Protocol Ideas

# Overview
The purpose of this draft BasicMessage replacement protocol is to extend basic message transmissions and enable a new message type / iteration that will facilitate a wider array of additional content delivery, activation, and signalling capabilities. Some of the new features will become a part of this proposed protocol while others may be facilitated by it and further defined is an additional, separate protocol layer.

# Possible Names
- AdvancedMessage
- EnhancedMessage
- **RichMessage**

# Possible Features

- Read receipts
- Receive receipts (acks?)
- Emojii responses
- images/file Attachments
- Threaded replies (message in response to another message)
- Message tagging (urgent, information, etc.)
- Question/Response

# Notes
- Some features may be best built as co-protocols
- credential exchange

# Questions
- Topic vs ThreadID / ParentThreadID?

## Messages

- Message
- threadid - required. Same as message id if new thread
- text content/type [utf8, markdown, html]
- Text [UTF8 string]
- Formatted text (e.g., HTML)
- Activtion Scripts?

- Attachments
- Image
- Video
- Audio
- Identity information (e.g., V-Cards, DIDs / DIDDocs, etc.)
- Location objects
- Encrypted content
- Encoded content
- Calendar invite

- Processing Requests
- NOTE: These are requested by Sender's agent, but optionally carried out by the receiving agent. There should be no inferrence of guaranteed execution.
- Self-deleting messages (e.g., delete after read or replied to)
- Time expiring (date message is no longer relevant, e.g., a coupon that is removed by the receiving agent after the expiration date)

- Routing
- Sender
- Recipients
- Forwarding
- CC (list, optional, unverifiable)

- Security
- Encrypted
- Signed
- Algorithm(s)

- Message Thread Management
- Threading mechanism to coodinate threaded message sequences

- Receipt (received, read)
- MessageID
- Status [received, read, time opened, responded, etc]

- Emoji
- Unicode emoji standard (https://unicode.org/emoji/charts/full-emoji-list.html)
- Types
- Reply Message (e.g., a separate message reply)
- Response to a message (e.g., 'liked' a message)
- MessageID

- Updatable Messages
- A message that can be edited or updated after it has been sent / received
- MessageID
- Action [remove, replace]
- Replacement
- Viewable edit history?

- Add recipient to topic
- threadid
- did
- remove me from topic
- threadid

- message share (used when the recipient has not received a particular message)

# Groups
When responding to a topic with multiple recipients, the sender must send the same message to all recipients.
The recipient list for a topic is modified when an add or remove message is received. Those modification messages are sent to every recipient.

Possible Releases?

# To Gossyp or to Simple

The Gossyp Protocol allows for a robust sync mechanism that we could leverage for messaging:

https://github.com/decentralized-identity/didcomm.org/blob/74e3c9b492150ca3909a777d7b6f20a5891e123d/gossyp/README.md

### Upsides
- Built in group sync / reliable message delivery
- Much higher scale - Potential for 100 - 1000 member groups
- Potential for 'super peers' to support larger groups.
- Built in message sharing for new group additions

### Downsides
- Two protocols (this would be the first Gossyp Driven Protocol) to build instead of just one.
- More Complex
- Higher cognitive load

gossyp potential features
add person
remove person
lock (agree to not add or remove)
cancel/forget/unsend a message