This is just not working - we need minimal region and direct to online user text chat back


Folks, I can’t be the only one that feels this… its serious and ruining the progress here.

Since a common mechanism which every viewer has that incudes chat was removed we have no way to make contacts even when we can see other users we know online, and we cannot have a minimal discussion to establish other modalities of communication even when we have an avatar right in front of us on our own regions.


Right now I doubt you will see anything “chat” wise in an official form any time soon. You can always try this solution from @Cracker_Hax.


I believe they have stated that HiFi will not have an official chat and are leaving it up to users. This is for the best since interface is intended to work more like a browser than a game client.


@Cracker_Hax _ thanks, I think it is premature this early in the history of ‘civilisation’ to abandon the written word and return to oratory


Voice works fine in some circumstances and supplements other modalities of interaction. But try sharing a long URL during a meeting via voice and see how you get on. Try discussions with your team members or colleague’s while a talk is in progress and see what those around you think of that.

Open chat in an area and back channel text IM is a very useful modality. It is a backstop also during setup when voice is not operational, or you are not sure if your voice is being heard, or need to get feedback on the levels you are using. Those experienced with teleconferencing and other more recent forms of multi-modal communication will know the issues of initial voice setup as a participant and those involved as an organiser more so.

Of course experienced users can add text chat and additional voice arrangements to most types of system nowadays… but that’s not the point… that requires advance agreement and setup BEFORE that instant and simple communication is available.

I urge High Fidelity to think again on this and include in the Interface a SINGLE always accessible built in text chat/IM/offline IM facility… even if its provided by a third party. Knowing its available to the recipient as well as yourself is the key important feature.


I think High Fidelity is digging a deep hole. Especially if SanSar is doing many things the correct way. But that we don’t know.


Some progress has happened since there is now a built-in text message mixer assignment client. That thing is the foundation of a general text/chat message router. Look here:

Now the mixer alone is not enough because unlike voice chat (and foundation audio mixers), the message facility is not built into the interface client app. It isn’t even built into the collection of default scripts that get loaded when interface app is launched. So, that’s the deficiency, but that assumes the HF management believe chat/text modality is equal to voice chat. They have been clear they don’t.

Now I applaud how well voice chat has turned out in High Fidelity. It is basically a highly scalable spatialized VOIP, and it works very well nowadays. You arrive and it works. Period. I do agree that a basic avatar to avatar and avatar to hub/group “IM” construct be built into interface, although it should be via scripts since there are use cases where it may not be desired.

Assuming the mixer foundation is well defined (AC exists for that facility), it should not be necessary to involved additional servers to implement an avatar to avatar text chat script. If doing text chat is more involved than that, and from looking at the @Cracker_Hax system it looks like he had to set up some server, then the foundation is deficient. Let’s get that fixed first.


I don’t think the message mixer is specifically intended for chat, although it could work but the security would be dubious without using encryption and of some sort of session hashing for private messages (even then they are not global to all of hifi).

I made craxim the way it is (using websockets) because I intend to add features that just won’t be possible with script alone.



BTW, I do like your craxim service. And, Thank you for making my point. The messaging foundation is clearly deficient. That needs to be fixed for many reasons.

I can imagine some decent scoping, such as having a simple chat messaging system that works within a domain, some new built-in AC that handles intra-domain messaging. That leaves inter domain coms available for extensible services.


I don’t see much of a distinction between using websockets and message mixer anyway, since message mixer does not have to be on the same physical hardware as the domain server (or won’t have to be). I think websockets are entirely more suitable for a task such as messaging than the message mixer because your server-side software can be more specialized to the task while ACs are designed to run AC scripts.

I imagine my c++ chat server can handle a lot more traffic at higher speeds than a AC server ever could (especially when encryption is added) as it is optimized for the specific task. ALTHOUGH I could see the advantage of having domains hosting their own local chats rather than having the entirety of all hifi messaging taking place on one single server (if you don’t want to have to be the one paying for the bandwidth anyway, which I am happy to do).

Message mixer is a great addition for scripts being able to talk to each other, but I think an actual instant messenger server is better for instant messaging.


I see specialized servers to handle high volume messages not that different than ATP. That protocol is designed to scale up from intra-domain server(s) to external agents. The selection of a specific implementation then becomes a load and scaling issue.

The preponderance of messaging, whether between avatars in the form of text chat, or between scripts (attached to avatar or otherwise), is going to be mostly intra-domain; that is, it is architecturally local traffic. In HF, avatar to avatar chat is for practical purposes script to script coms.

We see that already in many other virtual worlds. And, that messaging is usually not long-term stored, just short-term shallow buffers to permit flow control. That’s the kind messaging that the message mixer foundation could handle well.

I agree that store and forward messaging (classic instant messaging that works when the recipient is not around or is at a remote location in which its presence cannot be determine immediately) is best served by a store and forward system.


It sure is. I’m not knocking the MM, I am probably its biggest fan :D. I’m sure it would be great for local non-encrypted messaging (and way easier too). I am still in the process of incorporating intra-domain chat into craxim (so we end up with global chatting, intra-domain chats and instant messaging all in one client). What I want to offer is a way for domain owners to secure their domain chat by running a small AC script that keeps a session list of users, but also let craxim users have a domain chat no matter which domain they are in. What I might end up doing is using MM for non-secured domain chats and websockets for secured (i.e. administrated, encrypted, authenticated and/or logged) chats.

It is probably a no-brainer but I am assuming local unencrypted MM chats should probably take place in channel “0” (or maybe channel “” if it allows it).


Anyway so as not to derail this thread I think it is a good policy that HiFi has decided to leave chat up to its users because it allows for things like what I am working on. Each user/host will have their own personal preference of what chat client to use based on the kind of functionality they are after.

I do agree with OP though, as it might be good to have a standardized channel “0” version of a local chat to use if anything to keep all the different chat messengers that will probably appear on the same page and compatible with one another. It could be as simple as adding a script command that sends a channel “0” text. e.g. sendLocalMessage(string)


Yes, agreed, that’s a good convention for local chat.


It can be smart to use standards like XMPP (aka Jabber) for chat in order that they can be linked in to other clients and methods when away from rich graphics clients. Presence notification is just as important as the synchronous and asynchronous chat/IM itself.


The problem with chat is us. Were asking for permission when we don’t need to. Already we have a handful of working chat options. There are a range of totally suitable open source options. We have the capability to add any of these domain wide to our domains so they just turn on on arrival.I’m an idiot and managed that.
The problem is vhs beetamax
We have to just pick one and use it people will use what ever everyone uses. I kinda like the discord one.

But in truth I don’t actually care, ill use what ever everyone else uses which is usually @ctrlaltdavid 's one
Can we do one of those vote things in here?


Agrees - we all agree we need a chat solution so we can sit and moan and wait for one to arrive or just get on and do something about it. Like you I am not fussed about which of the many options we plump for - what i do want is something that everyone uses and that comes in as a default loaded when you enter the region - so its not reliant on people having to actively open the chat script (shoudlnt your previous post have been ceci n’est pas un ©hat…? ;p


@Twa_Hinkle I think has a script for a domain owner that loads up chat.js for visitors if they’re not already running the script. (I’ll check that the chat window displays by default for new users the first time they run the script.)

I’ve started work on making chat.js use the new Messaging script capability instead of the current Web service.


The available chat scripts seem functional and are relatively easy to install and then use.

So what makes them unacceptable? I mean – it stands to reason that something is standing in the way of people actually using these scripts. And whatever that is, hopefully it’s taken into account as part of any Chat 2.0 designs.

FWIW provides access to one of the most common IRC developer networks and works OK from within an Interface WebWindow.