The user may want to save emails--preventing them from being purged or automatically archived. This would be a separate action that commits the given message to the chain state. This could feature as a bookmark toggle on the message itself. Of course, unsave should also exist.
James' thoughts 2024.09.27
I think sent messages should be stored in/displayed from localstorage, rather than from a chain query.
Because once we add message encryption, the sent messages will appear garbled since the sender can't decrypt them. And if they are shown from localstorage, then they won't actually disappear like received messages unless we introduce a localstorage clean-up policy.
10:43
And if you "save" a sent message, then it would actually re-encrypt the sent message with your own keys, so you can continue to see and read the sent message
on get_msgs(), read saved messages and union them into the return set
add saved flag to saved messages
add get_saved_msgs() (not a separate call; just a flag?)
The user may want to save emails--preventing them from being purged or automatically archived. This would be a separate action that commits the given message to the chain state. This could feature as a bookmark toggle on the message itself. Of course, unsave should also exist.
James' thoughts 2024.09.27 I think sent messages should be stored in/displayed from localstorage, rather than from a chain query. Because once we add message encryption, the sent messages will appear garbled since the sender can't decrypt them. And if they are shown from localstorage, then they won't actually disappear like received messages unless we introduce a localstorage clean-up policy. 10:43 And if you "save" a sent message, then it would actually re-encrypt the sent message with your own keys, so you can continue to see and read the sent message
on get_msgs(), read saved messages and union them into the return set
remove
unsavefrom pluginhost::Server could parse and add PageInfo
Later: paginate later