your peer ID (NetConnection.nearID) is not generated on or by the server. it is the SHA-256 hash of a certificate containing (among other data) a Diffie-Hellman public key generated by your NetConnection and using your computer's cryptographic pseudorandom number source (such as /dev/urandom on Mac and Linux, or the Windows crypto pseudorandom number source).
the amount of cryptographic pseudorandomness used by the implementation for the DH keying is enough such that the chance of even one duplicate peer ID ever is vanishingly small.
so as long as you believe in your own computer's cryptographic pseudorandom number services, your peer ID will be unique.
since Flash Player and AIR peer IDs are linked to the encryption keying, a man-in-the-middle between two peers is not possible while preserving the peer IDs. if there were a MITM and the communication was actually working, the peer IDs would have to be different.
note that the server's ID (NetConnection.farID) does not have this property. this is because the server's certificate doesn't include a static DH public key. since the server is expected to be long-lived compared to a client NetConnection, the server uses an ephemeral Diffie-Hellman key for each client connection. RTMFP doesn't have a PKI. if you want to authenticate an RTMFP connection to a server (such as FMS) on which you can run your own scripts, you can use the nearNonce and farNonce on the NetConnection (client) and Client (FMS) side and an already-authentic channel (such as HTTPS) to verify the connection. doing that is an advanced and complex topic that i'm not going to cover further in this post -- suffice to say that it's possible.
I just wanted to know if someone can write on behalf of another user.
a client peer ID cannot be forged. it is up to you to securely map between users and peer IDs.