I just came across this old thread about public messaging and it raises some questions for me about messaging as a service/facility under the apps.
The discussion in that other thread seemed to indicate 1) that messaging was a “core thing” and 2) there would be direct interaction between users and core messaging, such as white/black-listing and applying filters and such.
I’m wondering if there is such an interaction, though. Aren’t all user interactions only with an app that then uses the core to accomplish the user’s wishes?
If that’s the case, then messaging is really between different running instances of the same app by different users – it’s never for direct user consumption. It’s up to the apps to wrap/send/unwrap their messages and present something (if anything) to the user.
If that’s reasonable, then it seems messaging should provide some kind of tagging capability for the app that created it. When a user logs in and runs the SAFEMail app, the app will find its waiting messages and possibly make a presentation to the user. This is where white/black-listing should happen, IMO. For the SAFEMail example, each message may consist of envelope information that is only enough to filter against while/black lists and possibly present an inbox to the user without accepting the mail payload until the user demands it.
Even if concepts such as white-listing are considered universal, they possibly mean different things in the context of different apps.
An app that is of a collaborative nature should be able to use core messaging to initiate updates across a group of collaborators that might not result in user interactions.
Very importantly, no app should be messing with messages for any other app.
Am I close?
EDIT for clarification: In referring to direct interaction between users and core messaging, I was referring to a design where the core messaging had features/API to suit direct user needs for particular use cases.
The intent is that the message contents and the Header subject can be
a serialised anything, so different apps will encode different
structures into the data field. Your app should therefore be able to
tell which messages are for it by parsing the Header.
Additionally, apps could perhaps create their own MPID on behalf of
the user to ensure that the messages for the MPID are all for it.
The SAFE messaging system, as defined, is more a general communications infrastructure with a intermediate buffer. And the communications can be User<->User, User<->App or App<->App.
With this design the system goes far beyond that serve Email or IM. In fact the possibilities are immense (Internet of Thinks, domotics, hardware control, software like Twitter or Facebook, etc, etc, etc).
My interpretation of “Your app should therefore be able to tell which messages are for it by parsing the Header.” was that every app gets a look at all message headers (if not the messages themselves) that have arrived in an inbox, whether they are for that app or not. I believe that is confirmed by the message flow diagrams in the RFC listed above. It’s then up to each app to be honest about ignoring what it should ignore.
So, I’m still not sure about messages that are not App<->App. Messaging is always performed by an app on behalf of a user, so the flow will always contain App->message->App, correct? Of course an app message may contain a user level message such as an email or IM or whatever, but maybe not, so I think it’s a distinction that is significant (or at least seems significant while I’m putting my mental picture together).
If the App create is own Mpid the messaging system work like separate ID so not security problems.
In the second case (the App want to use the same Mpid) missing to clearly define implementation but, for example, we can use the metadata of the Mpidheader and an App like the launcher to distribute the messages between the different Apps. In this way each App will discover only the messages that apply.