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:
- User A clicks on another User B name
- Check what port of the comms assignment-client is
- Check what the server address and port the client is listening to
- Request handshake with comms assignment-client to allow user A to open channel user B
- User B Accepts
- Window opens between A and B.
- Communications occur.
Flow for public comms
- User A says Hi
- Messages get sent to comms assignment-client
- assignment-client broadcasts message to all users in domain at that moment
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
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)