Edit: It looks like I misunderstood what you wanted, If you want the change in status purely to reflect if the message has reached the server or not, the only 2 ways are with a Meteor method or a collections transform as stated above. Sorry for the confusion.
You can totally use
So the way to do it is to have a field on the message that is something like
Then on your template you have an if statement that checks that field and if it is false show one icon and if its true show another.
The tricky part is how to update it. The most basic solution is that in the template helper that returns
Messages.find(), before returning the messages cursor, loop through the messages and update all of them, setting viewed to true where the author is not the current user. Its that simple.
So what will happen is that on the sender side, the message will be inserted into minimongo immediately will will cause the message template helper to rerun. But since the author of the message is the current user, it will not touch the
While this is happening Meteor will be updating Mongo over DDP in the background and then pushing those changes to all the other clients. On the receivers their message template helpers will rerun since the collection has been updated and when that happens they themselves will update the
isViewed field to True since they are NOT the author.
This will then propagate changes back to Mongo and in turn back to the sender, who’s message template helper will rerun yet again since the messages collection has changed. The template will update and since you used the if statement for the icon it will change to the viewed icon.
Remember though that this is a rather basic implementation, for improvements you would want to thing about setting up autoruns on template created for updateting the viewed field and be careful about how many items you try to update, (i.e. focus on limits on queries).
So I gave a talk about meteor at my University and I made a really simple chat application to show off features, and one of those is latency compensation, I implemented it basically as described above. You can view the code at https://bitbucket.org/posnea/meteor-tech-talk
and there is a running version of the site at http://chatterbox-suits.meteor.com/
You can safely ignore the aldeed:collection2 stuff and replace it with input boxes and normal meteor events, I just used to show off an example of a model layer in the talk.