Discussion on how best to do text chat


#21

You’re concerned about developers then, not users. That’s not a huge API, and most of it can be ignored… I’m sure there’s a sample implementation that can be cargo-culted for beginners.

Jabber has the advantage that it’s not tied to a single server. You can send to a specific server via an xmpp:user@host.dom.ain URI, and servers can be standalone or federated. Or you can just connect to High Fidelity if you happen to trust them.

As opposed to proprietary protocols where third party clients are discouraged or actually grounds for termination of your account (I seem to recall Discord fits into this category).


#22

Well think about it this way. Developers make for the users, and the simpler the development pipeline is the closer that we can bridge that gap between the developer user and the non-developer user.

If we can make things simpler, that means that more people can make edits and changes to diversify the ecosystem to find the best practices that will suit all users. If it’s a black box, it’ll never get changed, fixed or improved on.

e.g. in practice: Flow app. Great app, but of course plenty of things we would want done to it. Guess what? No one does those edits. Why? It’s all freely available in one JS file right there! Well because it’s too difficult and therefore not worth many people’s time. Result? Nothing gets iterated on. Dead-end until the original devs decide to move forward with it.

This hurts the developers, and since developers can’t fix it, it hurts the users. All users.

I’m advocating for a system that is easy on developers and therefore easy on the users, and everyone in between.

Fact: We have more people on High Fidelity that know how to script basically in HiFi (at least at a beginner level) than know how to utilize and extend XMPP. That in it of itself puts XMPP in a poor position.

There are ways of using the Private/Public key pairs that already exist in HiFi and core systems that can be used to send messages. It already exists and with some wiring up, it would be all operational and scriptable. In the end, the idea should be to make this simpler and of course more secure. Using private/public key pairs at least means that the carrier need not matter for now as it cannot be broken otherwise unless someone had your key. This means we can expand and carry our messages over websockets later if we wanted, it doesn’t matter!

Utilizing existing systems and expanding on our current API is all that it would take to make this work, then we can expand in other ways if we wish. But at least we have a baseline set that anyone and everyone can understand.

Generativity cannot happen in a black box.


#23

Which chat system in the marketplace would recommend we put in by default?

I think the big issue isn’t having it by default, it is needing to be able to sign on with your HF username/account, right?


#24

For all: My takeaway on this so far is:

We should investigate if there is a full-featured XMPP client/server that we could add by default as a tablet app, with OAuth login from High Fidelity so you get you HF username. Right?


#25

Right now I dont see any chat systems in the marketplace, many have come and gone in the past, several have been developed but never been put on the market, I personally believe people put this on the back burner because of hints 18 months ago that you were going to do it.

There has been no indication since that post that Hifi were not going to make a chat system so we have just been waiting for you.

If its not on by default then I refer back to our catch 22, you cant tell someone how to turn on a chat if there is no default chat runnung and their audio isnt working. Thats why I think it needs to be on by default and able to be turned off at will.

This is a big issue yes but a separate issue, because of the unusual setup of Hifi being able to be loaded and a presence created by a non logged in annon user, there needs to be the allowance of the text chat to be used annonymously, or again catch 22 kicks in.

Yes yes yes I totally agree.


#26

Last we saw:

Also:
http://metaverse.bashora.com/HFSLchat/

Those app hasn’t been put on the market because I think we can’t put on marketplace app pointing on external systems.

In the second case it needed to be generated with a unique key hardcoded to work without any log in. Which wasn’t really possible from the marketplace.

Not sure they are geared to support a serious load. (for sure mine is more or less a prototype)

The GeorgeDeac one seems more strong.

All the other I remember was mainly local chat.


#27

Maybe I am missing something about all this. From what I am reading it seems like people want a chat app that is enabled by default so that new users can get help with sound and stuff when they first try HiFi and might run into problems.

Wouldn’t just adding the simple domain based chat that is on the marketplace right now to a subset of default scripts, as Philip was talking about at one of the meetings, solve that?

If it was easily replaceable, people could make any kind of chat that they wanted. As far as XMPP chat… didn’t we have that years ago here and no one used it? Or am I thinking wrong thing/wrong place?

I can see how a notification system for new chat is useful, but for me, I would like that to be connected to a script that was easy to disable or replace.

A lot of this debate seems kind of silly to me. Regardless of what kind of text chat system HiFi ends up with, people will always use other methods to communicate with their friends. (Social media chat du jour).


#28

My 10 cents:

  1. Default chat app built into the tablet enabled by default
  2. Sign-in with HF username
  3. Linked to ‘people’ so you can message contacts you’ve made, with ‘message’ button in the people app
  4. Secure end-to-end encryption so nobody but the participants can read the messages, potentially the whole thing should be decentralized
  5. Extendable, for instance maybe one day you want to integrate with SMS or other system like email to get messages to people who are offline in real time
  6. Ability to one day integrate apps into the chat, eg payment function

1-4 are required for MVP, but also need a plan for how to incorporate the other items for future iteration.


#29

So let me get this straight.
You want a default chat app.
That would help new users if they need help and can’t get their system to work properly.
But they have to sign in.
That kind of messes up helping new users but okay.
I’m actually good with the old version. The only update I would add is the ability to drop links into it Lake George added. Because it is HTML base. The ability to drop pictures in to it. Like George added. Instead of adding a ridiculous unnecessary external server. I would allow servers to connect their messaging mixer to other servers in the server settings. Either by adding a domain name or IP address. I would have add information about that user being sent in the Stream. Signed in not signed in Username. Then I put a toggle in the settings that people can change to not allow messages from people who are not signed in.


#30

And of course the ability to block specific users. Updated can be easily stored by their client.


#31

What do you think of this approach? It uses IPFS to build a totally decentralized chat app:


#32

That looks fascinating! Does someone want to take on figuring out how to extend that example to use HF usernames? Inotherwards (I guess) each person would also want to be able to login to HF (if desired) and get an OAuth token that they could use to prove their identity to the recipient of a message.
Broadly I agree that a fully decentralized solution would be even better. My initial investigations (admittedly dated) had suggested that IPFS did not have enough peers yet or a mechanism to incentivize file storage for others, and was also quite slow in terms of the initial lookup of a file. I had my avatar stored as an IPFS reference for a while, but through that web proxy they provide that is of course not then actually decentralized. Would be interested to see how things have grown.


#33

#34

that’s cool too, in the use of public keys to verify identity. Would need to add something to use OAuth instead of just PGP. But I also think that solution uses WebRTC for the chatting, meaning that only 1:1 chat would work, not groups or all people within a domain.

I suspect that if we want ad-hoc group chat (say all those within a domain, etc), you still end up needed a server to forward messages for the group?


#35

#36

I was looking at dat as accompaniment to the go to. Most servers, especially those ran at home. Will probably be servers that can only handle a few people. This is perfectly fine for most people. But the goto it’s not the best way for these kind of servers to be available. I am only proposing a more Discord like chat and go to. You meet somebody you like talking to or visiting them in their domain and you make a connection. That allows you to chat with them with no server necessary. Same for their Home Server. Changes in IP address are updated. A beautiful example of this technology in action is the beaker browser.


#37

@philip Thinks the introduction of text chat should herald the end of anonymous users in hifi that the login must be tied to the hfc account and if possible block proxy users
Chat cannot become a new method for banned users to harass the comunity.


#38

It would end using chat and not being signed in. Which would negatively impact new users. I don’t see how making sure people are signed in is going to lesson alt accounts. Unless you lock each computer down to one account. I don’t see it. And remember there are people who do not have multiple computers in their household for each person. If you want to deal with trolling in a rational way, read what I said earlier. Adding a peer-to-peer .dat based system. The current chat when you are in the domain. Once you establish a connection with somebody you want to continue talking to that connection can continue as long as you both have a hash. Once you delete that connection. They can no longer troll you. The connection is broken. Knowing their username is unnecessary.


#39

I suspect that all systems in which the cost of contacting someone is zero (as we see today in email where you can guess an address and send to it for free) will increasingly tend toward being turned off due to spam. I would think this would be true with chat as well, if you could send a message @philip without @philip being a friend (or something similar). Domain-wide chat would fall to the same problem… it would become a broadcast channel for advertisers… "Come to and buy "

Therefore, yes I agree, probably most people will choose to want to use chat in a mode where inbound messages come from people you have approved a relationship with, similar to how you choose to have friends able to find you in HF today.

As discussed above, I think this goal is achieved with the option to login to chat using HF OAuth service.


#40

Just to clarify, while WebRTC is peer to peer, it isn’t 1:1. Multi-peering is possible and conferencing is totally doable for chat, video and audio.

Chat would be doable, and probably audio suitable for voice too. Video, however, would potentially require a lot of bandwidth and CPU for more than a 1:1 or 1:n mostly because we have to use codecs that rely on the CPU because many video cards do not support hardware encoding for those codecs (VP8/9 and eventually AV1).