Hacker News Reader

Comment by stavros | Hacker News Reader

I'm a bit annoyed at "we can do better than X" when, you know what? Maybe we can't.

Yes, it's nice that you and I can install Element and deal with the finicky crypto handshake that for some reason always shows red for me because a friend opened the web UI and closed it before he completed the handshake and now we can never actually make that check go green, and it's nice that Mastodon is distributed but mastodon.host went down one day with all my toots without a word from the administrator, and yeah I know I should have picked a better host (though if you could predict that mastodon.host will die why didn't you tell me?), but my mom can't.

Users value their convenience, and security and privacy are inconvenient. Hell, we started decentralized and over email and newsgroups and personal websites and blogs and it's all Facebook Facebook Facebook now that the Eternal September came around.

If we could do better, we would have done better by now.

View on HN

I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it.

To me, we have to accept the incremental wins where we can get them; getting my parents on Signal means that they're not on WhatsApp.

I am a believer in federation, honestly, but the fact of the matter is that there's a reason that XMPP hasn't taken the world by storm, and people have gravitated towards centralized stuff: it's just easier, and not everyone is a software engineer.

That said, I would love to be wrong about this....if we can make Matrix/Element approachable by anyone, I would support that.

I'm not worried about people that I moved to signal "grumbling" about being moved again to Matrix. If the Signal move was successful it should build confidence in future moves.

The killer app for Matrix for most people won't be ability to run your own home server, but the easy generalization of Matrix to things like Reddit/HN with good integration with 1-1 chat someday will be. Also organizational usage. That of course is way cooler than Signal "not being facebook". So biding our time is fine.

When the time does come, we should probably campaign for HN to be officially bridged with Matrix too :D.

HN won't even get dark mode, so the only way we'd ever get Matrix on HN is through a random macroscopic quantum event.

My experience with Matrix/Element and the various standard-compliant Matrix chat clients, in an ISP environment, is that it's totally possible to set up a rock solid replacement for Slack within an organization that has a person on staff to spend some cycles setting it up, and periodically maintaining it.

We don't have any major technical challenges or problems running our own Synapse daemon server. It's a debian stable xen PV VM stored on a LVM logical volume, so easily moved between hypervisors, or cloned, if ever necessary. It runs at a load average of 0.01.

In my specific ISP environment it's the same person that admins the X.509 private root CA PKI so we're well equipped to deal with running it in a purely intranet environment with no access to the global routing table.

For widespread non technical random end user use? Totally agreed it's not ready yet.

An "internally-run-Slack" is definitely a great use case for Matrix in its current form. I don't own a business, but if I did, I would almost certainly consider running my own Synapse server, just to have a stronger guarantee that internal chats stay internal.

It's an sqlite database on disk, so in our case fairly easy to know exactly where the data lives, and keep it secure.

Yes at my bigco they've set up a whole matrix (rebranded) service. Great. Only thing I miss is some kind of 'ephemeral chatroom' option, where nothing is saved or expires after some time. Some conversations are not worth saving and wading through all the chat logs to find some stuff can be painful.

Also I like the other tools' (cisco jabber and some others) option to save chat logs in exchange folders, so you have local search indexation/capabilities.

On the other side, I'd also like a button to record a whole conf-call, so minutes of meetings can be backed up with the actual conversation. Yes, how 'trusting' of me...

It doesn't seem like these problems are fundamental to Matrix, though.

I agree that Element is not that good, but if you were to replace Signal's backend with Matrix, your experience would (could?) be nearly identical as Signal is now and we wouldn't have the issues of a closed ecosystem anymore.

Ehhh, Matrix is more than a transport protocol though, it lives a lot higher up the stack. It would be akin to trying to make Signal into a Slack client. So you’re basically saying “if you paper over all the weirdness of Matrix with a better UI” which is easier said than done.

Speaking as project lead for Matrix (and Element), I'm trying to understand the mixed feedback we've had this week, and somehow channel all the negativity into improving things. While some folks are clearly using it successfully and seem to like it, another bunch of people say "it was a huge pain in the butt to get E2EE working, and if it two software engineers struggled this much..." etc.

When did this E2EE failure happen (so I know if these are current bugs or ones fixed months/years ago)? What platforms was this (web, iOS & Android are entirely separate codebases)? What actually went wrong? The simple case of signing up and DMing someone should just work, and the E2EE should be transparent.

The main possible failure modes I'm aware of right now are:

* Risk of undecryptable messages during federation outages (due to messages being shared separately from their keys)

* Risk of verifying another user getting stuck if there are weird failures/edge cases we haven't spotted yet

* Verifying yourself when you log in on a new device has confusing UX, and there's a known bug that can stop keys being synced to the new login even once verified.

If anyone in the "I tried Matrix and it was awful" camp could give detailed feedback (either here, or on github.com/vector-im/element-{web,ios,android}/issues) then it would be genuinely useful for prioritising our work. At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.

I don't actually think anything is awful, but my main complaint about Element as a GUI app, is that aside from opening the chromium developer console and watching what it does, it has very few options to diagnose client-server connectivity or TLS crypto key handshake issues.

I wish it wasn't an Electron app built on Chromium which makes it a huge resource hog. There's lots of underlying dependency and reliance on whatever design decisions the Chromium developers might make now or in the future, which would not be best suited to the security and single-purpose-focus of a chat application.

Isn't the beauty of Matrix that you or anyone else can build a client on top of the platform easily? I know on my Linux machine there are some non-electron options, like Qt [0].

[0] https://matrix.org/clients/

> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.

That's the nature of the HN beast: getting all the "it sucked" comments without STR and/or use-case descriptions is certainly demoralizing (reading HN comments about your own work is not for the unprepared) but asking folks who've had a bad time with your product to spend more time, for free, going through that same experience again so they can do a detailed report-out for you is probably not going to get a lot of takers (even if you might get a few high quality reports).

If you're not already doing so, I would strongly recommend you invest some money in getting access to "people who've never used Matrix before but are familiar with messaging apps" to do user testing (there's a number of sites for doing that for you, where you hand over money and instructions, and they find folks to do unbiased testing for you) where you ask pairs of people to get started with your software, with the explicit goal of getting to the point where they can set up E2EE messaging, and reviewing the recordings to see what roadblocks they run into.

And for bonus points, dev-blog about those experiences on the matrix/element site (where did folks get stuck? was this a surprise to you? why? how did you fix it? what were the user reactions to the fix? how much better is Matrix now, thanks to this work?).

I couldn’t emphasise this more. Stick to the YC mantra: always talk to users. Ask them what they want or have problems with, quantitatively (questionnaire style) and qualitatively (talk to them in person, real user testing).

Added a new feature? Don’t assume it’s well designed. Assume something is wrong with it and that it can and should be further optimised and sweat the details. Details matter.

Unless you sweat the details, users will notice.

> I would strongly recommend you invest some money in getting access to "people who've never used Matrix before but are familiar with messaging apps" to do user testing

I think they already do quite a bit of this, which is probably what makes it puzzling when tech oriented users on hn keep reporting how terrible it is, thus the desire for more details to see whether it's just an older anecdote, something missed in testing, etc.

Two matrix blog posts[1][2] from the past 2 months both mention new user testing/research, and there's definitely more if you go back in their blog history.

[1] https://matrix.org/blog/2020/12/17/matrix-to-reloaded#whats-...

[2] https://matrix.org/blog/2020/11/27/this-week-in-matrix-2020-...

> If anyone in the "I tried Matrix and it was awful" camp could give detailed feedback (either here, or on github.com/vector-im/element-{web,ios,android}/issues) then it would be genuinely useful for prioritising our work. At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.

Your two modes of suggested contact (HN, GitHub) ensure only a certain type of user will contact (both require tech skills and a login). If there really are UX issues, you might want to encourage different types of users to give feedback (and if the fear is that the feedback won't be detailed/useful, maybe a guided form can help).

I can easily use both of those methods and even I always like apps that allow me to just push a button and it composes an email in my phone's email app, prefilled with application version etc., and lets me send an email to report a bug/crash.

Yep, there should be a crash or bug report form within the app itself, and an email for bugs at something like support@element.io

There is one in Element Android. When the phone is shaken, a dialogue pops up "It seems you're shaking your phone in frustration, file a bug report". It has in-app bug reporting.

Also 'Menu > Report Bug' on Element Android.

I have used Element on n off. The UX around encryption and passphrase still needs some work. I cant imagine moving my family and less tech oriented friends on it.

I logged on to it yesterday and got a prompt to enter the passphrase. I have it all in bitwarden, so easy to get around but for the average joe that would be the end of the journey. Even the verify session, when in fact Ive verified them in the past.

Minor thing, I echo the sentiment to get some average joes and non-tech oriented using the product and get some feedback.

I can share the bugs that happened to me. All of these happened in the last 6 months:

- A message would get "pinned" to the bottom in Element. Basically, you could send new messages but a specific message would always look like it was the most recent message (even though it was not). This was a purely visual bug and the other party wouldn't have the issue.

- Messages send/receive slowly compared to other services. It could also just be the matrix.org homeserver, I'm not sure. You gotta be aware you are competing against the likes of Discord however, who deliver messages nearly instantly.

- Decryption would randomly break for one party and they would be unable to decrypt new messages until they restarted the client. I couldn't identify the trigger for this as it seemed to occur randomly.

> - A message would get "pinned" to the bottom in Element. Basically, you could send new messages but a specific message would always look like it was the most recent message (even though it was not). This was a purely visual bug and the other party wouldn't have the issue.

Is this in Element Android? I've had that issue happen there too, but only there.

I don't actually remember unfortunately, I haven't had it happen in a while. It's either the Linux client or the Android client though as those are the only two I use.

For me, this was a month or two ago. I don't remember exactly now, but my friend and I tried to verify each other, but one of us quit the device verification (with the five emojis) half-way through and uninstalled the app, so now there is a half-verified device that we can never remove. My icon with him always shows up red because of this device, and there's nothing we can do.

UPDATE: I just checked now, there's a "manually verify by text" option, I clicked "verify" and that device finally turned green, so at least now there's a way to fix this.

One major source of confusion for me is that one-on-one chats and multi-user rooms are different, but one-on-one chats seem to be multi-user rooms with just two people in them? That is confusing to me, because I see "people" and I see "rooms" but apparently people are rooms too.

All that having been said, I am very pleasantly surprised by the overall experience, and especially the pace at which it seems to improve. I use Element semi-regularly with a friend and it's been working okay. Hopefully all these kinks will be ironed out, because I really really want a better IRC, and Gitter has become infinitely better now that I can just use Element to access it.

> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.

Also, I don't think that's what the majority of users are saying (and I certainly never said and don't think Matrix sucks). I'm saying "this is not good enough yet that my parents could use it", which is an extremely high bar, and I think that's the way you should take the feedback.

In case you don't know, like Gitter, Freenode has a public Matrix bridge!

I remember trying the bridge but it wasn't working entirely well, has this changed recently? That's going to be another great integration if it works well.

Another solution is for them to just delete that old device.

Settings -> Security & Privacy -> Check the box next to the old device -> Delete Session

That helps, thanks. We searched a lot but couldn't find it a few months ago, is it new? Or maybe it didn't exist on the web app?

Hi!

I'd like to share something I consider a success story.

I'm using matrix successfully with my construction contractor and his helper. They've been working on a building site 2000km away for months. He and his helper have been uploading pics and video every day. They also use the chat now and then. I've shared pdf documents with them too.

Mind you, they were used to Whatsapp, so I had to nudge them into downloading yet another app and explain. As their client, I had the necessary leverage, so they did install Element (well, riot at the time). These are people who don't speak a word of English, from a remote countryside village, and totally unfamiliar with computery stuff, and they managed.

Thank you for helping to make that possible!

This is not in the same vein as what you're looking for. (I haven't tried user-user encryption), but the verification popups are annoying.

- I don't want popups or notifications, but whenever I use it, I'm greeted with one.

- Once I click "Verify", it's not clear how to proceed. It indicates to use a mobile phone etc with the app installed to verify. There are two clickable things: A big red "Skip" that appears to be the default button: This takes you back. A green hyperlink showing "Use recovery key or passphrase". Is this the "continue with verification and making the popup go away" button? It then asks for a passphrase, which I can only pass because it's stored in Firefox. What does this have to do with phone? Is the phone picture supposed to be clickable?

- Once I get past this, it still show a popup every time I open the page; this time, it asks me to review where I've logged in.

- Once I click review, I'm sent to a "Welcome to Element" page. The popup shows again next time I refresh or open the page.

OOT: Haters are going to hate anyway. Thank you for the incredible work you do with Matrix and the open ecosystem it fosters.

On another note, yesterday I set up my own matrix-synapse [0] homeserver along with a token-based registration page [1] with nginx+lets encrypt as a reverse proxy. I spent ~1 hour setting it up on a fresh Ubuntu 20.04 VM.

I then on-boarded my wife, brother, father and mother without issue. I just sent them a text with screenshots and detailed instructions on what to do. Everyone's in, and we have E2EE group chats going. Within ~20 minutes of sending instructions everyone was participating in chat.

The only issue encountered was that my mom entered the wrong homeserver URL (I set up the sign-up page to be join.subdomain.tld and the homeserver to be chat.subdomain.tld and she entered the former into Element). My dad was able to resolve the issue quickly for her.

All clients are Element [2] right now, though I plan on trying Weechat [3] this week.

Honestly, I didn't expect it to be this easy to do after seeing all the complaints on HN. I subscribed on Patreon yesterday and wish you all the best of luck!

[0] https://github.com/matrix-org/synapse

[1] https://github.com/ZerataX/matrix-registration

[2] https://element.io

[3] https://github.com/poljar/weechat-matrix

Here's a screen recording of me trying to log in to app.element.io [0].

0:10 - Stuck on "Verify this login" despite cancelling

1:00 - Same as above. The security phrase I have saved seems to be invalid.

1:38 - Can't drag or expand the left panel. Went away when I made the window wider after I stopped recording.

1:52 - After clicking "Verify" again, the session immediately verifies? I didn't enter any passphrase or do anything in my other logged in sessions.

2:18 - Every time I log in I get a notification about trusting a bunch of old sessions. There doesn't seem to be a way to get rid of them.

This is on a non-private Firefox (68, Debian) session, so maybe the security key is saved somewhere and didn't get loaded the first 2 times I tried to verify?

Also, not necessarily a bug, but to verify by phone I should just get a notification and not have to do 'Settings > Security & Privacy > Show All Sessions > [Guess one of several identical unverified Element Web sessions] > Verify.

[0]: http://files.widloski.com/matrixbug.webm

Mirror: https://youtu.be/QIRHAusQyYI

Firefox 68? I'm running Firefox 84.0.2 on Pop_OS 20.04. I can empathize with the project maintainer for not prioritizing a browser ~20 versions behind latest.

I forgot to turn on automatic updates. Still, it's only 1.5 years old.

I'm not able to load your video, Firefox says unable to connect.

Fixed.

It's against the rules to call it out on HN, but given how incredible Matrix is, I will happily risk being banned to share that I believe there is an astroturfing campaign currently being undertaken to promote Signal and that you should take the complaints with a grain of salt. Matrix and other competition are being cast with FUD in an attempt to sway fence sitters.

Thank you for Matrix and Element. My non-technical friends and family all use it without issue.

Funnily enough it seems like opposite and people are trying to put down Singal. Seriously we are all on the same side. It's not competition.

I've been running matrix instance for probably 6 years from times even before Vector.

The constant popups happening and mysterious verification fails gotten pretty annoying. So much that my non-technical friends started to complain. It has gotten objectively worse in past year.

I happily use both Signal as SMS replacement and Matrix for community/slack. Signal can't do chatrooms / more people well and it will probably never will. Matrix on the other hand is much worse at ux of the encryption process and overall user friendliness for casual users. It's not long ago when matrix didn't have 1on1 chats and would just make new room with 2people named after them.

Signal is a single point of failure, cell-phone number dependent chat app. It should be put down along with WhatsApp.

If you don't own the server, you are not in control of your information.

Nobody cares if you own the server if there are no users on it.

Also it's not like Matrix.org is not single master instance that can fail just as easily. Even better most of data there is not e2e encrypted so yes if somebody hacks it you will loose all the information.

I should be clear, I wouldn't say Matrix/Element "sucked", and I apologize if that's the tone that my comment implied. It's pretty cool, and I greatly preferred it over trying to finagle XMPP + OMEMO, and I will probably try it again soon enough.

In my case, my issues came down to mostly your last point:

> Verifying yourself when you log in on a new device has confusing UX, and there's a known bug that can stop keys being synced to the new login even once verified.

If I installed a desktop client on two different mac computers, I would have issues with messages not decrypting properly until I do a re-verification, and figuring that out took some Googling and trial-and-error.

I've been self-hosting synapse for 6 years (? before vector) with small active group of about 30 non technical users. You've helped me to set up synapse all those years ago. I am super grateful for that and for your work.

But we've had issues over the years

Some issues i thought are happening because we are not always on the most up to date synapse (my problem) and clients expect version of the master instance but it seems happening even on the root instance: - Verification issues that are impossible to understand even for me. Often it fails even you go through the process. - In past year huge increase in amount of notifications. Everytime i log in i am greeted with "Review where you’re logged in Verify all your sessions to ensure your account & messages are safe". - Some my users enabled e2e and randomly locked self out of rooms because they log out somewhere or updated client and couldn't back in.

All my users have similar problems and actually started avoid e2e on matrix now. It's shame because most of them are now also on Signal because they want e2e.

Other issues:

- I had to make special video tutorial for users to be able to register and log in at our own instance. They keep trying to log into matrix.org instance. Custom instance seems like something second tier in clients. It would be really nice if instead "login to matrix" vs "use custom server". It would be login to your server with multiple public servers as options by default and + button to add custom servers. More like you add services/logins in ios or something. It wouldn't feel like discrimination.

Overall i feel like there is some duality in Matrix goals. On one hand it markets federation and decentralization but on other hand it promotes matrix.org so it looks like is the only instance. It would be cool to support different servers to get some diversity (like this https://www.hello-matrix.net/public_servers.php is not on matrix.org page).

Nobody thinks about it but the most professionally used communication medium is the email, and part if not all of its success if not all its success is that is decentralized.

A company cannot afford to use a service that can be closed and loose all the communications. Centralized services are single point of failure, and in that regard Signal is no better than WhatsApp, because yes, in theory you can run your own server, but have you tried to do so?

It's not practical or even endorsed by the Signal creators themself, since there is no way in the clients to make them connect to your server instead of the centralized one.

Another bad thing of Signal is the use of a phone number as the authentication method. A phone number is not something that preserves your privacy. Well in theory in countries where you can go into a shop and buy a SIM card cash yes, but in a lot of countries you have to give your ID. Another aspect in which email is just better.

> Well in theory in countries where you can go into a shop and buy a SIM card cash yes, but in a lot of countries you have to give your ID

another huge problem with using phone numbers as IDs, which software developers in the US/Canada often don't think about, is that in many developing nation environments there is no such thing as local number portability, or the ability to move your phone number between any of the major national-scale mobile phone network operators or VoIP providers as you wish.

As you can do in the USA if you become unsatisfied with your Tmobile service and want to move to ATT, keeping your phone number. This is one of the reasons why dual (and even triple) SIM phones are so popular outside of North America.

In a lot of countries I don't see number portability in the SS7/PSTN system ever becoming a political reality, due to regulatory capture on the part of the national telecom regulator. At least not before pure IP based communications and apps make the concept of a PSTN phone number irrelevant entirely.

On the other hand, email is the single largest causes of cyber attacks.

The communication is not E2E encrypted (apart from a few GPG/SMIME users), no forward secrecy and barely any signature checks. Even if outlook, thunderbird maybe supports it, goodluck getting all the mobile versions to support it too.

The clients used to view emails suffer from the same problem with browsers so are subject to all the HTML/JS/CSS privacy attacks.

I wish all companies would move to something centralized solution where communication is guaranteed to only come from those within the same service. This way Sharon from HR won't open every link, download every crypto/ransomeware.

Maybe my IT could also save 150k a year by not having to send me phishing 'training' emails and instead deal with some decent forms of signature checking. Heck billions of dollars a year are wasted because of phishing, spam, crypto attacks because of email.

From my perspective, email is a shitty legacy tech from 1990s that should be moved to a modern solution that enables E2E encryption or signature checks at a minimum.

> I wish all companies would move to something centralized solution where communication is guaranteed to only come from those within the same service. This way Sharon from HR won't open every link, download every crypto/ransomeware.

It's totally possible to set up 'email' for intranet purposes only, using your own DNS setup, standards compliant smtpd and imap daemons over TLS. The persons using it just need to know it can't send or receive emails from outside of the organization.

It's possible, but every company security, tech otherwise is not setup like this.

Frankly, I am just happy slack is picking up the slack here.

A Lets Encrypt for email certs is badly needed.

Haha, I love the angry honesty in this post. That's exactly how I feel. I think it's possible that we can get the UX right for a chat app based on a decentralized protocol such as Matrix some time in the future, but that's just not the case today.

And today, I'd rather have everyone using Signal instead of WhatsApp. Yes, Signal might go evil in the future, but we'll deal with it then. In the meantime let's improve our decentralized chat systems. And as this current period shows, it's absolutely possible for a lot of people to quickly switch from one social network to another.

It turns out that decentralization closes the door on top-down censorship, but at the same time, invites spam and abuse of the system for personal gain. It's very easy to do this in a decentralized model, and every single decentralized service suffers from this. IRC, Email, Mastodon, you name it. It's all bad.

The solution is simple. Make the decentralized systems social, with reputation.

How do you prevent bots giving each other reputation?

Some strategies:

Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot.

Implement Sybil resistance with a combination of verifiable cost and blacklisting. Make it cost real verifiable resources to create an identity (hashcash or Bitcoin burning or something) and then have a system for blacklisting fake IDs.

> Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot.

This is just 'web of trust', right? https://en.wikipedia.org/wiki/Web_of_trust

By punishing their connections when they misbehave.

Or at least, that's how you make it not matter. If spam-bot hands out reputation to spim-bot and then you get a bunch of garbage from spim-bot, derate everything coming from anyone that has given either of them reputation (and perhaps ignore their attestations also).

Now what happens when spam is done through a compromised user, or when the user acts human and has real interactions before spamming?

I suppose it depends on the details quite a lot.

But fundamentally, it isn't particularly harmful to just burn a user that starts spamming. If a compromised account is recovered, it's fine if they have to restore communication out of band, if it isn't recovered it's fine that it is burned.

I can't believe I'm suggesting this, but maybe trade it through cryptocurrency. Pay a few bucks to create an account. It might get expensive to start a server and have others agree to federate with you though.

Could also just use regular money.

And that then is extremely easy to abuse as soon as you have enough people with high rank enough deciding to start to misbehave.

Sounds like IRL

Turns out most problems are people problems, not tech problems. Tech is just how the symptoms present.

If everything revolves around people I give authority to (my "friends") then any attempt to game my feed is going to result in a swift defriend. Problem solved.

It even happens in the real world too. I remember one guy who had been on eBay or something for years working up a huge positive karma, and then one day a switch flipped and he disappeared with everyone's money and was never seen again.

“If you like my post I will like yours.” We can’t have many nice things, it’s human nature.

Will the arbiter of reputations be central or decentralized?

If each person controls the authority they provide to others (via friending, upvotes, etc) then the system can't be mass gamed, which is enough to deter most bad behavior.

I see a lot more witch hunts these days than I did 10 years ago, and most of them are as principled as the days when they were with torches and pitchforks. If I came across a system with a reputation-based feature it would be a red line I would definitely not cross.

The footnote[1] project helps to provide spam and abuse by limiting each user to 10 MB.

[1] https://github.com/kyokan/footnote/

It's not easy to do better. Sure, Moxie has has a strong opinions, but has reasoning behind it.

Not distributed or federated, because then you'll inevitable version drift, complex handshakes, more attack surface, different quality implementations, more risk to users, and overall a less secure system.

Requiring a sim, annoying, makes it easier to track people through whoever paid for the sim. However it does make it hard for an attacker to create millions of accounts and camp on user names.

> Users value their convenience, and security and privacy are inconvenient.

True. A messenger will be widely adopted if it offers features that WhatsApp et al. don't have. And by that I don't mean security or privacy, but something that people actually care about, like the stickers in telegram for example. And then that messenger just needs to be secure without interfering with functionality, convenience or UX ... problem solved.

> If we could do better, we would have done better by now.

We should have given up on Linux UIs way back then. They're still garbage when it compares to the alternatives.

> Hell, we /started/ decentralized and over email and newsgroups and personal websites and blogs and it's all Facebook Facebook Facebook now that the Eternal September came around.

We didn't do the decentralization then because of good politics and security: look how bad the other security properties were. Rather we did it because the field was new and the actors not consolidated.

Creating decentralization after in a mature, consoliditated space is a completely different enterprise. In particular, a lot more attention needs to paid to inefficiency and defense against the central hegemons.

It's a hard battle, but if won, will be a much more durable victory.

These are all complaints about the app's UI, not Matrix or federated networks.

> If we could do better, we would have done better by now.

I'm guessing you might have said something similar about a non-profit running a massively popular chat application 5 years ago.

The only pieces missing now are interoperability and community involvement.

We need to think of ways to run the various Matrix, Mastodon, peertube etc in tiny boxes in our homes! There is no real reason for not promoting self hosting. The same way i buy a small Nas or an amazon firetv stick, with apps, I would buy a small box with pihole, mastodon and matrix.

Have you tried running Mastodon and Matrix on a Pi? I'm not so confident it'd work, these aren't lean servers.

I would love a tiny server I can run on my home server (for my tiny message volume), but Mastodon and Synapse are optimized for large servers.

synapse is actually quite tiny, but its use of an sqlite db on disk and other disk-write related activities, over a long term of months or years, seems quite likely to destroy a raspberry pi microsd card in much the same way that ordinary logging will destroy a microsd card. yes the rpi4 can boot from a USB-connected 'real' sata device now, which is an improvement.

> synapse is actually quite tiny

Hmm, is it really? My server has a SSD so I don't care about writes, I just want it to be low on CPU and memory requirements.

an entire synapse with its python environment is about 150MB of disk space occupied, before any user data starts getting written to the database.

chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3.

this same machine also has a minimal nginx setup as the standard reverse proxy configuration for TLS1.2/TLS1.3 in front of the synapse daemon, which isn't set up for any crypto and only listens on localhost.

It's worth noting that this sounds to be an unfederated server.

The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources.

The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.

Yes, absolutely, this is for company internal use only. I imagine the resources for a server that talks to the outside world are much greater.

I have tried it on a RPi3 and it is painfully slow. I would not recommend this to anyone.

one of the challenges with that from the perspective of an ISP, is that residential broadband connections are very often highly asymmetric in bandwidth.

for example on two of north america's largest DOCSIS3/DOCSIS3.1 based cable modem operators, you can get 200-600 Mbps downstream speeds, but uploads may max out at 16-18 Mbps. Depending on your exact location. This is because of how RF channels are bonded together by the CMTS operator.

lots of other access technologies will face significant challenges and capacity constraints if a sizeable percentage of residential broadband end users start trying to actually use their upstream bandwidth at a greater rate than they do now, when averaged over the traffic for hundreds or thousands of individual end point users.

There's been work on integrating the server and client together in a p2p fashion.

Then you are essentially self-hosting on your phone/laptop when you run the client.

Which is more or less verbatim addressed in the article...

"While that is somewhat true — at least by the metric of “secure messengers your granny can use”, there are some promising alternatives who are especially focused on decentralizing E2EE communications.

Nobody's saying there's a better alternative already, which seems to be your main gripe. The point is that Signal's model is still imperfect, and it's worth improving upon.

>If we could do better, we would have done better by now.

To claim this regarding tech, of all fields? I seriously can't imagine what would have to happen to make me think that everything has already been invented, and what we've got now is the best we'll ever get.

I agree with this. Even Signal is just barely this year entering in the realm of practically useable for most of my friends and family.

I'm not so sure. It really hasn't been that long in a generational sense that the internet has been around. Society may still be in the honeymoon phase of it's relationship with the internet. If building network services was like building houses, we may not be anywhere near drywall.

Who is the "we" who can't do better, just technologists? Or humanity as a whole? Is it all just a demand side problem, and the people chose centralization, or was centralization a matter of policy for some group of sufficient influence? Is it just a byproduct of unfettered capitalism? A conspiracy to make the internet less 'libre' by a powerful special interest looking to profit (or a three letter agency looking to snoop) isn't outside the realm of possibility, is it?

Anyway, I guess my point is that there are a lot of different factors that got us to this moment, and as people say, change is the only constant. I don't think anyone should give up on their ideas for the future, even if they've been tried without success before in some form.

Skype was good when it used to be p2p... but when Microsoft bought it, they changed how it works.

Reply on news.ycombinator.com