Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot.

The thing I haven’t figured out is... why would people find this hard to understand for chat, but not for email? Everyone uses email, and everyone knows they can send an email to whatever email address they want no matter who their provider is.



I don't see it as a question of understanding as much as caring. It's not very realistic to do a "here's technical details of the protocol we'll be using" talk every time you invite someone.


They probably don’t care that much in the case of email either. Would it be better to explain it by analogy? “This is like email, you pick a provider and you can talk to anyone from there.”


Okay, I can agree with your framing from the sibling:

> I’m not convinced that open/federated protocols are inherently more difficult for people in general to understand.

We may be disagreeing on the hierarchy of the goals. I think the priorities here are:

1. That the protocol is open and decentralized from the operator perspective (which is ensured in the case of Matrix).

2. That many people use it.

The #1 should be important for an opinionated minority pushing everyone else. The good thing is, non-technical people usually don't have much brand loyalty in these things. It's purely perceived convenience.

That the majority of people understand and care about #1 may or may not be realistic. I see it as partially another cause. Today, we have much of de facto centralization in email while the protocol is still decentralized. It would be nice to push chat to a more or less similar state and work from there. (I would also gladly see decentralization and inter-operation of many things enforced by law, but this is even more pie in the sky.)

Still, certainly your analogy can be used in communicating with people. But the main thing I'm trying to achieve is #2, getting them on board anyway.


Yeah, I think we largely agree. I'm mostly aiming for #2, because I'm hoping that if we can get enough people using something that's hard to centralize, network effects will take care of #1.

Consider email for example: I think the main reason it's stuck around with us for so long is that we're at the point where being reachable by email is just expected. With everyone using email, someone trying to replace it with a centralized option would need to get everyone on board, while someone who wants to interoperate with email in general doesn't have that issue.

ISPs and phone companies are similar; nobody's going to start one that can't interoperate with the others nowadays. The public wouldn't stand for it, even if they couldn't explain why in terms of the underlying protocols.

While I would certainly love it if we could get people to care about open protocols, I think getting enough adoption of an open protocol would really be sufficient, so long as it's not easy for one big player to lock it down. (Google Talk for example; it was XMPP, but Google was the only player that mattered then as far as the public was concerned. Matrix is in a better position than that now.)


Most people are chained to a hotmail or gmail and don’t really understand the underlying architecture in my experience.


They may not understand the underlying architecture, but they definitely do understand it from a user perspective - they can send an email regardless of provider.

Telephones are the same way, too. You get a phone number from whatever company you want and can use it to call people no matter what provider they’re using.

I’m not convinced that open/federated protocols are inherently more difficult for people in general to understand.


I think you are overestimating the level of understanding a lot of people have. For lots of people, IE == the internet. Start Firefox: "My internet looks different". Same for Outlook vs GMail. The average office worker (and home computer user?) has eg. Outlook installed and set up by the IT department.

But yes, the analogy with cell phone providers is useful. With this analogy, who would still tie their social media profile to a single provider?


It's not the idea that you can chat with people on other providers it's that you still have to choose a provider with no real guide on how you would make an informed decision among them.

You choose your phone provider by looking at the top 3 or so established providers and the choice is usually made on price or other signing incentives. With your ISP you just pick from a couple ISPs that serve your area. With email you just pick GMail or whatever your work gives you.

All of these decentralized chat systems just need to act centralized. Have Matrix.org just be the matrix server that people sign up on and let the fact that other providers exist just be something that comes naturally. Have Mastadon be the StatusNet server but casually interface with other servers.

What seems to kill these projects is that the group positioned to own the market actively shoots themselves in the foot in an attempt to not become too big.

Let the protocol be an implementation detail. Sell the provider as a service.


> The thing I haven’t figured out is... why would people find this hard to understand for chat, but not for email? Everyone uses email, and everyone knows they can send an email to whatever email address they want no matter who their provider is.

I see you haven't worked in corporate IT very much. You're missing the comparison too, Riot isn't the service, it's the client, and there are a crapload of people in the corporate world who "aren't computer people" and for whom Outlook is email. Or AOL. Or Gmail. Whichever email client they encountered first, that is email to them.

They know they can email people at different companies, they just don't know or care that many of those people are not using the same client.


I think a lot of people know that, but also a most people use one of a few email providers in their country.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: