I'll try to explain more, I *think* maybe I did not explain well
but its good you brought it up.
The databases are separate. Pligg will continue to use its database, SMF will continue to use its database.
However, our perspective is different in this point: I intended to use Pligg as an 'add on' to SMF (so the users that use my forum to get some dynamics - but I think I failed, somehow they are too bored or something to try anything new
)
So, it was easier for me to code the integration as one way only, from SMF to Pligg. Everything will continue to work as is on SMF (as the database remains intact). What got changed in Pligg was in fact the authentication part (expecially the generateHash method you will find called from a couple of files in Pligg source code).
What I needed was a single way of encrypting the passwords, and given my constraints (SMF user base as a starting point), I had to tweak Pligg sources so when Pligg will read its database (populated with username/encrypted passwords from SMF) it will still allow the logins.
So if you plan on starting from Pligg and then later on adding SMF, I guess this mod doesn't fit (as it is only able to copy users from SMF to Pligg and not vice versa).
I will maybe write to Pligg team and suggest an integration API (much the same as SMF has, one doesn't necessarily has to reinvent the wheel). Basically let an external entity do the authentication/authorisation/encryption as well as also notify an external entity that user changed his details (email/avatar/password) or maybe deleted his account.
Given the work is done on Pligg at the moment, I do not have the time to write the integration API myself (nor the knoledge) - I think myself more like a Java programmer than PHP. I do ok with PHP too
but not up to the scale of coding an integration API.
Sorry
if this isn't what you want - this is the best I could given the time constraints I had..