) basically allows for simple p2p audio, video, and data. The only non-p2p components are usually the initial configuration of the peers (using a server to signal to each peer network and session metadata) and sometimes an intermediary relay server for peers behind restrictive NATs.
Ethereum contracts could act as a means of restricted-access p2p session initialization for WebRTC. One contract is a key-value storage linking ethereum addresses to public keys. Another is a nameserver/key-value storage that stores an ethereum address as the key and WebRTC session metadata encrypted with various other public keys as a list as the value. Perhaps there could even be a third contract that linked an ethereum address to a list of other ethereum addresses or public keys. Of course you need logic to be able to only allow the address holder to edit his key storage. And logic to delete metadata from keys for which you no longer want to provide the session data.
What you get from all this? A completely decentralized mechanism for letting 'friends' connect with mutual 'friends' via WebRTC.
How would it work? So the first contract lets a user link a public key to an 'identity'. When a user would set up an account, they'd send a transaction to the contract with a public key (or keys) as data alongside the transaction. The contract logic would store the keys under that address (so that friends can store data that is only visible to that user).
The second contract stores the signalling information needed to connect via WebRTC. Whenever the user went online/had their networking info change, they would send a transaction with the necessary session metadata needed to connect to them via WebRTC. The contract logic would lookup the keys from the third contract and store the encrypted forms of the session metadata under that address.
The third contract stored the 'friend list' of the user. The user could send a transaction signalling to add or delete addresses. The contract logic would add or delete addresses from that address' storage space.
So after the user has updated his session metadata, the user can search through the friend list of the third contract and lookup the session metadata on the second contract for each one found. Since the user owns the private key, the one of the metadatas from each entry can be decrypted and the user can then attempt to connect to each one.
If a friend does the same, then the user will be able to connect with the friend.
Of course, once connected, you'd want to do some sort of handshake with the keys to make sure the connection is legit, but there you have it.
The first and third contracts can be reused for other applications, as well.
I'm sure this could be better optimized/interoperble with other ethereum nameservers... open to all the ideas