It would be node view, and think what it implies. When you view a thread or a page like PMD every author needs a lookup. The "normal" way such information is stored is in your users settings which pmdevers will often call $VARS. These settings are a stringified hash of all of your settings and are stored in the 'settings' table. So assuming we use the settings for this information we need to fetch it out and then parse it for the correct key. If we dont use the settings then we still need an extra per node fetch for each node we display. Thats a fair cost. On top of all of this we need to make sure that $AUTHOR is set correctly whenever the parsing code is called. This is not currently complete. What im trying to say is that this is a big load for what I think is minimal gain for the site.

The opposite case however is much lower load, and IMO actually useful. Whenever a page is rendered in PM the users vars are automatically parsed out, and preloaded into the $VARS variable. This variable is always available when links are parsed so its easy and low cost to find out the users link mappings. I think a templating system with sufficient builtin patterns should suffice, and it doesnt require that much code to do, at least not in comparison to what you have in mind.