Storage for different event kinds

[SubatomicPlanets]

Received messages should not always be stored and retrieved like they are now. For example, in my app I use get_messages() with pagination to get the last 100 messages. Right now this works because my app can only send chat messages (like texts or images). But now I want to add read receipts, reactions, online indicators, and more. Some of these new features should obviously not be stored and retrieved in the same way as chat messages (I don't want last_message to return a read receipt. I also don't want the last 100 messages to be filled with online indicators).

As discussed in #193, it would be nice to store/retrieve received messages differently depending on the event kind. I'm not sure if the storing or the retrieving should be changed (one could just add some sort of kind filter when using get_messages() and other functions). In any case, this section in NIP-01 could be helpful. Maybe MDK should just follow this when storing events so that events can be regular, replaceable, ephemeral, or addressable?

I'm not sure how this should be implemented, but currently the only way I can add ephemeral events is to drop the pagination when retrieving messages and then filter them by kind, which is obviously not ideal...

[erskingardner]

I agree we definitely want to handle some message types differently than we currently are. But for certain things like read receipts, using ephemeral events I think is actually an anti-pattern that would lead to a really bad user experience. Think about it, for every online heartbeat, every read receipt everyone in the group has to spend the compute to decrypt (twice), plus parse and handle the payload.

I think read receipts and online indicators in specific are probably going to get their own MIP and we'll do it in a different way (potentially channels over quic).