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.