Use an oid column

The nid is there specifically for node_access control. But having an oid column would provide a few things maybe. But which oid would you store When user A and user B become friends?

The user A and user B's uid are stored in the activity_messages table. But that can't be guaranteed to be the two actors. Especially as we start to move towards grouping messages.

The real issue is that an activity can have more then one 'object'. Even node creation has two (account, node). Friends have two (friend1, friend2). Comment has three (comment, node, account). User actions have one (user).

Each activity doesn't represent one object, there can be multiple.

I think if A and B become friends then A's uid is in uid column and B's uid - oid.
I think that the final 'object' is one: comment, node, flagged user. And this fields might help us to construct any variants of styled messages.
More dirty solution is to save usefull data (cid, flagged friend uid) in activity_message and explode it in views theme template.
Any others ideas to have a link to comment, flagged friend in view ?

I think if A and B become friends then A's uid is in uid column and B's uid - oid.

But how do we map this? its easy to say "case flag_friend" but thats not what we want. it has to be general.

And this fields might help us to construct any variants of styled messages.

More dirty solution is to save usefull data (cid, flagged friend uid) in activity_message and explode it in views theme template.

It has been a major design decision to NOT store extra data serialized away. It causes severe slow downs and does not scale.

You can write a token [user-picture] and implement hook_token_* and return theme('user_picture', $account);. We allow html tokens

I have started building out the grouping functionality which is basically, combining "Johny changed his profile" and "Sally have both changed their profile" into one message "Johny and Sally have both changed their profile". This is another important thing for this module. Storing an oid in this case makes even less sense as an oid is multiple values now. Therefore, each message is can no longer guaranteed to be about one activity and because one activity can't be guaranteed to be about one 'object' I'm marking this issue as "by design".

I really think the "theming" of messages is going to be accomplished only through tokens. If you need help creating tokens, post here and I can help you out. And if I can't then, we need to revisit this to make it flexible enough.

I believe this

And what about to save short texts from nodes and comments in activity table (on/off option and length are customizable in settings)?

is already achievable as a field in the View. Select field Node: Body and trim the length. You should never store this, always use existing data structures. This is another guiding principle of the 2.x branch. (If it isn't available create a new issue and I will make it so)

Also please note i started a new issue #458588: Add a maxium length field to each configured action

Thanks for clear answer!
I began to read about tokens...

Select field Node: Body and trim the length.

But Node: Body is not available :( Only Nid, Title and link...

Tokens is power!
I can make user-picture, node-teaser, comment-teaser, etc tokens...
Big thanks, Scott Reynolds !!!