Remote Action trigger? Possible or not?

I know I can send a message to an av anywhere in SL using a script with LLInstantMessage

The Message itself appears like a Chat Message (in green) and is private like an IM--and this is what I want.

Now, is there a way to read these messages and trigger some kind of action in a specified remote object?

I am thinking of an attachment worn by the receiving av, with a script using LLListen (or??)---and then some if else statements to get the attachment to do something (like have its texture turn visible or not).

Is it possible to read an Im sent to somebody with LLInstant Message in an attachment or remote object at all? and if so, do you use specified channels or what?

if i understand right, you can send a instant message from any object to a avatar, and it will apear green, i use it all the time in my multitools to comunicate with the owner.

yes you can send instant messages anywhere in sl.

and the last part about attachment, you would need to create a type of radio network "sl server" to do that but it can be done

avatar -> object -> avatars on list (vise versa)

no can do, llInstantMessage can't be picked up by an object/script at all, attachment or otherwise.

If you can get the key of the attachment to the broadcasting object somehow, you could use llEmail() (though it can be slow at times, and causes bunches of script delay). Remember that every time the object is attached/rezzed it will get a new key though.

Another commonly used approach is POST messages to an external web server and then GET them from the receiving object by polling (and/or with the help of XML-RPC).

Yes. llHTTPRequest would work here, if one had a webserver at hand. Personally, I'd avoid XMLRPC; Kelly Linden's comments in http://jira.secondlife.com/browse/SVC-29 don't sound encouraging for the long-term viability of that mechanism. And llEmail works pretty well, at least in my experience. The bit about the key changing is a big deal, though; it's probably best to have a couple of redundant central "post office" objects--and a way that all communicating objects can come to learn about new ones, if old ones die out. The post office would also maintain a mapping between addressee (the persistent identity of, for example, one of the attachments) and transient UUIDs.

Ok! thanks. I'm glad I asked! It saved me a lot of time.

I think going back an forth outside of SL would be a lot more laggy than I want
(Idea crashes and burns)

Thank you.

Well, object-to-object llEmail doesn't ever leave the LL network (and isn't really as heavyweight as "real" email). It might sound scarier than it really is. The gotchas I see are just two: maintaining communications when UUIDs change, and authenticating that the addressee is the identity it says it is. If it's not a real sensitive thing, that latter problem can probably just be ignored, and the former is definitely solvable.

I guess there is a practical limitation on the volume of llEmail one would want to handle, though. If there'd be thousands of addressees and/or messages every few seconds, then yeah, it probably wouldn't work very well.