Discussion on how best to do text chat


High Fidelity still doesn’t have text chat, as has been brought up by several Canny voting items. I wanted to list them here for deeper discussion, and then give some thoughts:

Send a text message to someone online but in another domain:

**Send a message to a user who is offline **

** 1:1 text chat with someone online in the same domain **

Building a text chat system is a lot of work, and the required features are getting more and more as we all increasingly use tools like slack and discord. But, as has been pointed out, using those directly is a hassle because you need to create new accounts or risk exposing your privacy. Argent suggested us installing an XMPP server - does anyone have additional thoughts on this or experience with great XMPP clients?


Food for thought video

Chat must be on by default, it must allow communication between domains and allow the sharing of media files etc. We must beable to share photos of kittens
I dont know the tek terminology or what xmpp is
but I think some kind of domain peer to peer that allows Michelles domain to opt out
I think any logging should be only done locally
and I think anonymous users should be excluded from using the system
Discord does alot well
But it takes communicatioin out of hifi.
I love to chat and listen to music, text lets me do this


Discord is not really a replacement for chatting.
It’s installed. semtimes i start it. But really 99% of the time i ignore it. It’s not a good platform for chatting. Tab between windows is really annoying.

Not to talk about people that need to create extra accouint to have the option to chat outside the world. While others chat in the wold.

Chat need to work default. You need to have the option to talk with other people on other domains. Then you get a connection and people can meet each other.

XMPP. never did hear anything about that. Used google. And it seems to be open standards etc. Is thats ecure enough ?

As far i see chat need to be encrypted on open platform like high fidelity to make it harder to intercept IM. Not sure if it’s needed for local chat.

I do not like that you need to choice between listen to music or use something like high fidelity. WHile with chat you can do both. Text chat is so much more supriour in many cases compared to voice chat. That it’s strange it’s still not default.

The XMPP wiki.


To have tried to implement one.

The authentication is the first problem we hits.
and this is true for any external system we would like to plug to High Fidelity where it’s not a big deal to ask people to create an other account on the external system.

We would need something like open ID and a service to confirm the id provided from HF.


Fortunately, we did make the decision to use OAuth/OpenID as our authentication scheme - this will make it easier to connect whatever services we care to connect to.


i really dont know much about coding. but i mean i dont think we are looking for something like discord we dont need to send each other egg plant emojis or files. all we really need is a chat app where we can message each other and send links. but again thats just my opinion.


My recommendation is to put server access and API in place for us to make our own chat interfaces and designs. The reason chat is so hard for us is because we’re forced to use 3rd party instead of letting servers bridge gaps for us. If HiFi makes a proprietary chat system, it really puts us back steps if anything. Temporarily we get chat, but we can’t customize and use things as we please which is how HiFi is meant to be.

So regardless of which implementation we settle on, it should be one where we can customize our own solution with reasonable effort. Anything less and it was a bust.

XMPP is extremely robust but also relies an extreme skillset all the same, XMPP works but it will not work for our use-case in HiFi because of its complexity. We should think about making development for chat to be accessible. Ideally, this should be a fire and forget thing for HiFi, maintaining only the core systems and improving those. Give us the workable API and server systems in place by default on all servers (extension of Messaging Mixer for example). From there, we can make the appropriate extensions with clients to see the features we want to see.


You are missing an important factor here, for 5 years we have been trying to get Hifi to provide a chat solution. Users have created dozens of chat systems but they all fail for the same reason. They are in the marketplace and not in the default client, so they might as well be on Mars as far as new users are concerned.
A basic text chat system needs to be part of the default client at startup when new users log in for the first time. The lack of this has been one of the greatest failings of Hifi (imho), the inability for new users to get help because they cant communicate.
How do you ask someone how to fix the voice if the voice does not work and there is no default chat? Impossible., another user gone forever, I have seen this happen with monotonous regularity.
Contrary to what you are saying, if Hifi does not make a proprietary chat system we are back where we started, with a bunch of disparate chat systems in the market place that only provide a partial solution to existing capable users, try telling a new user how to get a chat system if you cant chat to them, this is the catch 22 that we have been living with all this time,.
Please dont discourage Phillip from putting effort into a chat system.

I dont know why you would say that, we are able to customise most aspects of Hifi now and I dont see the chat being any different. You can customise the edit panel, customise the tablet, even customise the interface. But most people dont want to do this, only coders do. Most people want to load up, log in, and go. We need to start catering for the masses not for the elite few as we have been doing.
If you want you can already build your own chat as I and many others already have, but that doesnt solve problem number one.

Yes I agree with your point provide server access and API so users can customise their own chat interfaces if they want to and even be able to build whole new and improved systems based on the hifi provided API, but there must also be a default basic chat that allows 2 way communication including all users in a given (adjustable) radius on each domain.

I also think there is a use case for messaging across remote domains to online users, which also calls into play a global list of online users with the ability to choose to hide (not display online status). Of course this could be extended to storing the message if the user happens to be offline at the time.


Just other problem that is torture high fidelity.

Everything is done in the tablet. The biggest problem with the tablet is that it’s single tasking. That proves alreay to be a pain when you build and need to access other setting. You lose the state if yor current app. As far i remember discord then ask to login again when you open chat.

The tablet need to work mu.ti tasking. Or better, no tablet in desktop mode but split windows.

Guilty, i need to check things again. But moved to new home so busy and no VR setup.


I am not sure if you and I are using the same definition of “proprietary” here. Generally, “proprietary” means some company has an exclusivity-protection attached to that item, meaning that it is patented and no one else is allowed to use that system. That is NOT what we want here. We do want something that’s built in straight out of the box, though, but that does not mean it has to be “proprietary,” it just means it has to be THERE.


We also need to know if there is text chat activity around. Without have to check the tablet. No need to import the insane phone-checking syndrom here.


Yes it was bad use of the word proprietary, but I continued the use of the word within the Cambridge dictionary meaning…

Proprietary goods are made and sent out by a particular company whose name is on the product

Simply to mean Hifi makes it and provides it, but not to infer any sense of closed source or exclusivity.



There are a bunch of already available XMPP clients (https://xmpp.org/software/clients.html) so initially all High Fidelity needs to do is host an already-written server and recommend clients.

As for the implementation in the HiFi interface, there are a bunch of XMPP libraries (https://xmpp.org/software/libraries.html) including strophe.js which should be run in the Interface browser with minimum effort and be reasonably easy to create a native interface with. BUt honestly, just having a button on the tablet that opens a browser-based chat window in the Interface browser would be a huge improvement over the current situation while leaving a straightforward path for improvement as well as good offline clients for mobile devices and low-end desktops.

Reinventing the wheel is likely to be a lot more work.


So I think you misunderstood me here. I also think you misunderstand why chat clients fail: the way they work is not integrated into HiFi. It’s too much trouble to actually bridge the connections between people, their clients, and their servers. We want to have decentralized and secure chat, but we have no good way of doing that.

My proposal is to make an API available, from there it would be straight-forward: people will then release these new chat clients that are all compatible, that work across all the clients and all the servers.

You’re assuming that the reason chat failed before will cause it to fail again even after my proposal is implemented? I highly doubt that would be the case, because a universal system that we can build on top of seems to make the most sense with the least friction. If you can use the Messages API, then you can do this. But no one is asking you to do this and roll your own client, not even close.

This is not for the elite few, this is to enable one to make for many, for many to make for all.

This is a proposal to create an open ended system from the start that doesn’t take rocket science to change and edit. Having to rely on third party libraries from the start is a non-starter, good luck trying to fork the library when you need/want more features.

High Fidelity can in fact create a chat system on top of this universally available API and preload it onto all clients, to be swapped out if you desire. Just like your client ships with an Away app that can be switched out, this can be too. My issue is not with creating a chat from the start, it’s creating something limited that hurts users trying to extend and adapt from it. We have to pick something that is reasonable to use and understand.

  1. Create API + Server extensions
  2. HiFi creates chat app on this
  3. Others create their own
  4. Let them fight
  5. ???
  6. Profit.

The ideal should be to enable chat for the masses, that is the goal we are working towards. So I would strongly urge you to give consideration to this.


I agree, but I suggest you look at this: http://strophe.im/strophejs/doc/1.3.0/files/strophe-js.html

I can’t imagine this would be the new definition of creating chat for the masses, people will not reasonably dedicate time to extend and work this out.


As mentioned before the key bit is the Authentication. Chat needs tied into the ‘Accounts’ system seamlessly, the specific implementation may not matter as much. Right now from my experiments we can access the unique username from Hifi, but not much more in terms of Auth or ID management…

Biggest thing lacking is an API from Hifi that provides auth tokens (JWT), this way Hifi itself could become an Auth and identity service for VR.

We think of Hifi as decentralized, but this is partly true since the Identity of the users is still centralized.

A really quick way to solve this… there are many chat platforms or real time databases from Google firebase to xmpp protocol based ones… Hifi should pick one and make it the defacto for all users, as mentioned add it to the tablet by default.


I suppose I’m a bit confused, why not use the account system already built-in to HiFi and make that accessible to the chat API? Let people authenticate with third parties as a custom feature on their own client/server mods.

Also, if the chat is not limited in implementation, we can still control whether or not we care to have “guests” send messages, as it should be.

Regardless of what we choose, chat should be:

  1. Decentralized
  2. Uncensorable
  3. Secure, if my message is sent, it had better get to its destination and not be read by prying eyes (or servers)
  4. Easy to use and extend


Not sure why you would expect end-users to use this rather than whichever web-based interface High Fidelity chooses to host during the transition.

My suggestion for XMPP was a response in the feature suggestions by Phillip that suggested starting out with an external system only. If that’s done using XMPP, then transitioning to a native in-world client is at least possible.

But creating a new API means you don’t start out with a bunch of good external and web-based clients, so you have to create the API, create the external client, and create the in-world client pretty much all at once.

And there are already hooks to authenticate XMPP using OAuth/OpenID which High Fidelity already uses.


The reason I linked that to you is because that is what users will have to deal with if they want to extend, change, or update the chat client in that implementation. It’s good to know what we’re getting into before we actually commit.

I agree, starting externally and bringing an in-world client would do just fine, however that can already be done voluntarily. So clearly that’s not really the issue here. Also, one must consider that having HiFi host a centralized server (what I got from the post as it was worded) is already a non-starter. If apparently chat is at the core of all this communication, why on earth would we allow HiFi to control that and be the single point of failure?

Why when avatar and entity hosting is decentralized, when every server is decentralized, when voice communication is decentralized and deployed directly by the server, is the chat going to be centralized? That seems like a pretty poor move for what is a social realm.

If an XMPP server is deployed with each domain just like we have the mixers then that’s different, each server handles it like it handles everything else, then when you want to send messages, we can bridge gaps by having the servers be relays to allow us to pierce through and pass the messages. The API should allow for us to use the metaverse API as a pointer for the servers to use on behalf of our app, but in the API we should be able to select an alternative router, from there you get the starter: full chat enabled for everyone & chat that is extendable, secure, and decentralized by nature since you can easily choose how else to route if you’d rather not use the Metaverse APIs to send messages to different places.

This allows for something cool like having a chat client in world that can connect to Discord, SL, or whatever given that you have a way to pull and push messages for each respective service.

Using existing web clients is cool for a one time out of the box thing. But to edit, modify, or work with any of that is an infinitely more difficult task.

By going that route, we are locking ourselves into the whims of third parties everywhere (the devs of any respective libraries and clients we use) and their continued contributions or lack thereof. If there truly is a concern that only the “elite” can build communication interfaces, then XMPP should not be the first choice, though consideration should be fairly given all the same.

The goal after all is safe, secure, decentralized chat for all.