Proposal: Websockets and Chat


#1

I have been for a while thinking of a method to do text based communications. I have a counter-proposal to my earlier one: Now with some of the websocket based games by @Thoys and socket experiments by @davedub, and mention from @ctrlaltdavid the idea of websockets actually might be much more feasible:

The jist is: We use Websockets handle private communication between users. with the encryption built from the users uuid. Domains would handle communications between users with the domain (Broadcasted to all users within the domain, or within range as adjusted by domain / zone rules).

Users.js currently polls information through https://metaverse.highfidelity.com/api/v1/users?status=online . This can be also put into any other url or chat system as well.

Improvements to hifi’s existing info could be Visible API should be the ability to show that you are online, but not enable anyone to teleport to you (Seriously Id like to be online, but sometimes I dont want to be disturbed by random teleports). However additional information would be a uuid pointing to the assignment client within the domain that handles communications, if one was available in the that domain the user is in.

This would be a central “handshake” server for that domain, and would handle communications to that users in the domain: but usually by the time the user has established connection with the other user, the middle man is no longer necessary.

This way the users can communicate to each other until the client is closed, or the client crashes. However scripts would still handle all of these communications, but would give hifi a framework for communications.

In Flow for private comms:

  1. User A clicks on another User B name
  2. Check what port of the comms assignment-client is
  3. Check what the server address and port the client is listening to
  4. Request handshake with comms assignment-client to allow user A to open channel user B
  5. User B Accepts
  6. Window opens between A and B.
  7. Communications occur.

Flow for public comms

  1. User A says Hi
  2. Messages get sent to comms assignment-client
  3. assignment-client broadcasts message to all users in domain at that moment
  4. etc.

The benefits of this system is:

  • Its distributed: Only relies on info on users from high fidelity, what already is available, but can be extended to be elsewhere too
  • Smaller Bandwidth for clients, no need to load up so much overhead as in the older Proposal
  • Privacy: can’t request messages by uuid, messages only available to those present

The negatives

  • Servers might get a bit more traffic

  • volatile: Once message is sent its sent, its not stored anywhere but whomever receives it.

  • Requires polish to not be exploitable (double, tripple checking)


#2

My only slight concern is that some governments seem have a strong opposition to end-to-end encrypted communication channels. I’m keen not to stir any ‘sleeping dragons’ - the last thing we want is creepy spook types poking around the HiFi codebase and demanding backdoors, as this could severely weaken encryption in other areas such as asset distribution and virtual currencies.

  • davedub

#3

I did have this in mind:

Considering that the messages sent to each other would be encrypted by uuid not by secrets, its actually quite weak encryption. Ofcourse its an area of improvement but having it simple like that would most likely not attract too much attention to it as it is just text comms.


#4

As I’m understanding this, then messages forwarded to email would not be an option if that were desired since after communication is established, there is no ‘middle man’, correct?


#5

That is the negative part of it indeed It is, as I described it “volatile”


#6

I meant to qualify that by imagining that the user had gone off line in the middle of a conversation (ie crash) but volatility does have its benefits, I suppose :smiley:


#7

Yeah in the uk were forbidden both privacy and free speech