[HN Gopher] Element raises $30M to boost Matrix
___________________________________________________________________
Element raises $30M to boost Matrix
Author : Sami_Lehtinen
Score : 752 points
Date : 2021-07-27 07:29 UTC (15 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| usbfingers wrote:
| Fluffychat is mentioned a lot here as a good UI/UX alternative to
| Element. Just wanted to bring up another that I'm working on
| called Syphon. It's not at the stage where it can compete with
| Fluffychat in terms of spec parity or maturity, but I think it's
| worth discussing as an effort.
|
| https://syphon.org
|
| https://github.com/syphon-org/syphon
|
| Like I said, it's still very much in Alpha and needs quite a bit
| of work, but the UX flows and design have been well received by
| others. Though there is an opinionated default UX and design
| paradigm, there is a focus is to make everything customizable and
| the theming options are growing over every release.
|
| The goal is to eventually find a sweet spot between Discord and
| Signal and bridge the gap to Matrix between those communities.
|
| I have a demanding day job and other obligations that keep me
| busy, but I spend nearly all my free time and every vacation in
| the last year working on this project. We're constantly looking
| for other contributors and there's several other ways to help
| including donations. Feel free to join the official room for
| updates to track progress and please feel free to reach out with
| feedback!
|
| https://matrix.to/#/#syphon:matrix.org
|
| Additionally, I just merged Multi-account support this week and
| it will be in the next release. Not sure of any other Matrix
| client that has this feature, so there's some unique features
| that we're focusing on to set it apart.
| Macha wrote:
| It would be nice when you're advertising on your UX, to have a
| screenshot of your application on the website.
| simcop2387 wrote:
| > Additionally, I just merged Multi-account support this week
| and it will be in the next release. Not sure of any other
| Matrix client that has this feature
|
| Mirage has this but it's the only one i know of. it also didnt
| seem to work with cross device signing last i tried it.
|
| https://matrix.org/docs/projects/client/mirage
| opan wrote:
| Quaternion and Neochat have multi-account support as well.
| simcop2387 wrote:
| nice, i tried quaternion a long time ago so i wasn't aware
| it had it now. i haven't tried neochat before even though i
| use kde. i'll give it a shot and see how well it works
| usbfingers wrote:
| Very glad there's other clients supporting this. Thanks for
| the heads up!
|
| I was under the impression some of the desktop clients had it
| in the form of swapping CLI flags on start, but it seems to
| support switching under the settings menu in the latest
| release. Much like email, many people will have more than one
| user they'd like to swap between so very glad to see other
| clients adding this feature with user friendly UX.
| simcop2387 wrote:
| Yea, element has support for multiple profiles but you have
| to run multiple clients to use multiple accounts. It;s a
| bit like firefox profiles and it works but I don't really
| count it as multiple account support.
| easygenes wrote:
| There's some good analysis here on the proposition of Matrix vs
| XMPP from both a technical view and a who-has-your-interests-at-
| heart-view: https://lukesmith.xyz/articles/matrix-vs-xmpp
|
| TLDR is Matrix leaks heaps of metadata and it seems designed to
| do that so that the creators can data-mine it for intelligence.
| encryptluks2 wrote:
| Upvoting before you get flagged... It appears Matrix is trying
| the Microsoft approach to marketing. Gaslight the public until
| you become too big to fail.
| goodpoint wrote:
| Spot on. The level of fanboying is this thread is quite
| something.
|
| Not only Matrix leaks metadata all over the place, but it
| relies on the idea of encryption being safe FOREVER.
|
| In 30 or 40 years all your messages might be public.
| xvilka wrote:
| Finally they have money to get rid of Electron.
| justshowpost wrote:
| LOL! I hope so.
|
| Just looking at their GitHub, they have an ridiculous amount of
| 7000+ open issues (5k on Web, 1k on each Android and iOS).
| Assuming they'd use a generous 1/4th of the money to fix
| outstanding bugs, assuming no duplicate bugs, and assuming a
| 100$/hour salary for the developers, they can spent on average
| about 10 hours to solve each bug (30000000$/4/7000/100$).
| jryans wrote:
| Many issues are pie in the sky enhancement / feature requests
| that may or may not be implemented some day. There is no
| intention to drive the number of open issues to 0 just for
| the sake of it.
|
| As long as Element and Matrix continues to grow, I expect the
| number of open issues will grow indefinitely, and that is a
| sign of success.
| Arathorn wrote:
| +1000000000.
|
| Judging a project by its number of open issues is like
| judging a book by its number of pages.
| goodpoint wrote:
| Not only Matrix leaks metadata all over the place, but it relies
| on the idea of encryption being safe FOREVER.
|
| In 30 or 40 years all your messages might be public.
| samatman wrote:
| Weird objection. I don't think this is solvable even in theory.
|
| I mean we have to encrypt with what we have, right? They could
| use lattices or something (my impression is this would be, er,
| hard on the battery, but that's a vague impression), but those
| could be cracked as well. They could be cracked first!
|
| Let's just say it's a risk I'm willing to take, given that the
| alternatives appear to be either my messages being public right
| now, or communicating by snail mail and carrier pigeon.
| goodpoint wrote:
| > I don't think this is solvable even in theory.
|
| It is very solvable in practice.
|
| If I encrypt a TCP connection with AES (e.g. SSL) between my
| home and your home very few attackers have the ability and
| budget to capture that traffic, store it for decades and
| break AES with some quantum-or-whatever computers in year
| 2050. NSA and perhaps few others.
|
| On the other hand, if encrypted data is shared publicly on
| DHT, a replicated database, a blockchain or similar, in year
| 2050 your nephews will see grandpa's entire message history.
|
| On a practical level, that's a huge difference.
| samatman wrote:
| That's a reasonable point I suppose, although a private
| Matrix server is just a fat peer from this perspective.
| Unless its database lasts 50 years, those messages are just
| as gone, and Matrix (I think?) uses TLS in addition to E2E.
|
| Score a point for urbit I guess: any channel is limited to
| those peers participating in it, so Mallory would have to
| get her hands on one of the planets which received the
| messages. There is no central point of failure because
| there is no privileged server.
| kyruzic wrote:
| It relies on the idea of encryption being safe forever in the
| same way any other program does. If somehow the encryption used
| is broken you will have a lot more to worry about than your
| messages.
| hellcow wrote:
| They use perfect forward secrecy through OLM, no?
| blendergeek wrote:
| "Perfect Forward Secrecy", better termed "Forward Secrecy",
| allows old messages to remain secret even if the long-term
| secrets are leaked.
|
| If current cryptographic primitives are fundamentally broken,
| all data can be decrypted if it is saved. This is why it is
| safest to destroy everything if you are worried about threats
| in the distant future.
| hellcow wrote:
| Got it. So the concern is that there's no support for time-
| based deletion of messages? That is on their public
| roadmap, and I think it's reasonable to assume that'll be
| deployed before modern ECC is broken.
|
| Or am I misunderstanding the concern?
| blendergeek wrote:
| The main concern is that the encrypted data is stored on
| the server long-term. The longer it is on the server, the
| more likely it becomes that it is saved by an adversary.
|
| If data is only stored for a minimal amount of time, we
| lower the risk of an adversary acquiring it
| foresto wrote:
| > time-based deletion of messages? That is on their
| public roadmap,
|
| How can deletion of a sent message be enforced? I realize
| that some messaging services offer this feature, but
| aren't they all misleading at best? Even on a centralized
| service with a trustworthy admin, the recipient can
| always copy/paste or take a screen shot.
| goodpoint wrote:
| You cannot delete encrypted data once it has been shared
| with the whole world.
| kitkat_new wrote:
| messages don't get shared with the whole world, but only
| the users and the homeservers the users choose
| Arathorn wrote:
| Obviously this is true of any encrypted chat system. Anyone
| could be recording your encrypted network traffic as we speak,
| your conversations will be busted wide open! It's nothing to do
| with Matrix.
|
| If you're talking about the fact that Matrix stores your
| encrypted conversation history by default on the server: a) you
| can set history retention per room, b) if we saw a
| vulnerability in the encryption we could always go and re-
| encrypt the history (although it's a bit of a lost cause by
| that point :)
| goodpoint wrote:
| No, read the other answers.
| Arathorn wrote:
| > On the other hand, if encrypted data is shared publicly
| on DHT, a replicated database, a blockchain or similar, in
| year 2050 your nephews will see grandpa's entire message
| history.
|
| No, Matrix isn't a public database or a blockchain. The
| conversations only are only replicated between the servers
| whose users participate in that given conversation.
|
| You might as well be panicking about PGP archives getting
| compromised, or backups of devices with Signal history on
| them, etc.
| ducktective wrote:
| How do people connect to matrix?
|
| I'm yet to find a TUI client for matrix. I've checked those
| weechat plugins but the python one needs libolm3 dependency which
| is a hassle to install on my system and the Rust one is not
| ready.
|
| Element webapp is clunky and slow. Element desktop is an Electron
| resource-hog. There is a Go client (gomuks) which was very buggy.
| I've also tried a QT client which was alright but not on-par with
| the official Electron webapp in terms of features.
| mschuetz wrote:
| And buggy. Element/Matrix is the worst chat app I have to use
| on a semi-regular basis.
|
| I have to click away three modal popups during every single
| login, and it doesn't remember logins so I have to login every
| time I visit the page. It also asks me to verify my
| login/device on every login because it doesn't remember. This
| happens on two devices, with two different browsers.
| bennyp101 wrote:
| Is that on a self hosted, or on app.element.io? I have a self
| hosted, and I just opened it and it logged me straight in - I
| can't remember the last time I logged in as I use the desktop
| client.
|
| I just tried app.element.io and it asks if I want to "store
| data in persistent storage" - maybe you clicked no a while
| back, and it is still blocked?
| MayeulC wrote:
| Sounds like you log in from a web browser, but clear local
| storage (or cookies) at the end of your browsing session?
|
| I log in rarely enough that this doesn't accommodate me: my
| most recent browser login must have been two years ago or so.
| mschuetz wrote:
| Any other website with login manages to remember my login.
| Not sure what causes it, but it's not fun.
| kadoban wrote:
| What are the modals you have to dismiss? That doesn't
| sound familiar to me at all. Could have something to do
| with it?
| mschuetz wrote:
| Ok, it's actually 4 popups, 2 of which are modal:
|
| - "Verify login" (now always skipping this one because I
| need to do it every single time I login, and I need to
| login every time I visit the page)
|
| - "Are you sure?" (Yes, I really don't like this one
| because I'm only skipping because verifying doesn't help)
|
| - "Verify session" (okay, not modal, still occludes parts
| of the page. Also skipping, because it's useless since I
| have to repeat it every time)
|
| - "Help us improve element by sending user data" (No, I
| don't want to send user data)
|
| Needless to say, I don't enjoy starting up Element.
| Saris wrote:
| Somehow you're clearing all the data Element uses. Those
| popups only show up on initial login to a new browser
| session.
|
| If you're clearing cookies or local data that would be
| why.
| kadoban wrote:
| Hmm, interesting, those don't really sound to me like the
| cause. Is there anything in the site settings or
| anything, maybe it's disallowed from local storage?
|
| For what little it's worth, I haven't run into the need
| to login on every visit on either FF or Chrome. Which is
| just to confirm that it's not supposed to work that way.
| paulcarroty wrote:
| I'm using Fractal several months, working fine.
| iknowstuff wrote:
| Fractal is nice and looks great on GNOME, but no e2ee and
| uses more CPU than Element.
| the_duke wrote:
| Fluffychat [1] is probably the best alternative client, written
| in Flutter. But it is also missing a lot of features and is not
| exactly polished.
|
| [1] https://fluffychat.im/
| rjzzleep wrote:
| On linux fluffy chat uses a lot more CPU than Element. That's
| not a compliment for Element, but rather a depiction of the
| poor state of Flutter apps.
|
| I tried pretty much all third party Matrix apps, if you want
| cross device signing, there's only Element, an element fork
| and some of these half working flutter clients.
|
| It's not great. The initial developer for the weechat client
| did a great job, but the move to rust has pretty much stalled
| from what I can tell.
| nyanpasu64 wrote:
| Good: FluffyChat's CPU usage has been reduced so it no
| longer burns CPU (nor makes Xorg burn CPU) when idle, only
| when typing or moving your mouse (with call stacks deep in
| Flutter event handling).
|
| Bad: It's written in Flutter, and the keyboard/mouse
| handling still has flaws.
|
| Ugly: The FluffyChat Matrix library used by FluffyChat
| (https://pub.dev/packages/matrix) requires contributors to
| sign a CLA where you sign away copyrights/trademarks, and
| perhaps even become obligated to assist the Famedly company
| in IP lawsuits.
| genewitch wrote:
| Schildichat works between devices, I get notifications on
| both riot.im element and schildichat on Android, as well as
| on my desktop.
|
| Maybe I am unclear of what cross device signing is
| MayeulC wrote:
| Nheko is not perfect and lacks polish in some places, but I
| like it a lot, and it supports cross-signing.
| hestefisk wrote:
| I can vouch for Nheko. It's fast as well (native code
| with Qt?).
| MayeulC wrote:
| Yes, most of it is Qt quick, some parts are still Qt
| widgets AFAIK.
|
| Subjectively speaking, it's one of the fastest and most
| fully-featured clients: it even supports desktop sharing
| with pipewire and gstreamer.
|
| It's a lot easier to use once you get used to the Ctrl+K
| shortcut to select a room.
| rjzzleep wrote:
| Appreciate the comment, last time I tried it all of this
| was missing. Seems like it's a fully fledged alternative
| now.
|
| I'll try it out. Seems like they implemented most code in
| a mtxclient library, so it might be possible to reuse it
| for other clients.
| deepbluev7 wrote:
| mtxclient mostly implements the API calls and some crypto
| primitives. A lot of stuff still lives in Nheko, because
| we couldn't figure out how to fit it neatly into
| mtxclient (like the storage layer, device verification
| flows, etc). But apart from that, probably. It is pure
| C++, so you don't even need to use Qt to create a client
| with it. (In general it may be better to contribute to an
| existing client though. There are a lot and they could
| use some help to become more polished.)
| foresto wrote:
| I've been reading the Nheko updates in This Week in
| Matrix with enthusiasm. How are E2EE and cross-signing
| coming along? Once those parts are fully implemented,
| stable, and trustworthy, it will look pretty attractive
| as a replacement for Element desktop.
| dkasak wrote:
| The Rust rewrite is stalled but not abandoned, there's just
| been a bit of a slump due to time constraints. Which
| features are you missing the most?
| Arathorn wrote:
| weechat-matrix works well; you should just install the libolm3
| dependency.
| ducktective wrote:
| I tried it before but the other problem is that the plugin
| seem to _only_ accept `virtualenv` method of python virtual
| env handling which I'm not familiar with.
| https://github.com/poljar/weechat-matrix#using-virtualenv
| auscompgeek wrote:
| I personally don't use a virtualenv for weechat-matrix;
| seems like a bit of a hassle.
|
| Either way, `virtualenv` is a drop-in replacement for
| `python -m venv` (or rather it was the other way around -
| virtualenv came first, but virtualenv still exists for
| different tradeoffs).
| ducktective wrote:
| It needs quite a few dependencies in its
| `requirements.txt`. Did you install them globally? If I
| use `-m venv`, it doesn't produce the `activate_this.py`
| file that this plugin needs.
| Liskni_si wrote:
| It absolutely does not work well. It only just barely works
| if all you need is chatting in public rooms that you joined
| from another client (e.g. Element). Everything else (joining
| rooms, sending private messages to people you don't have a
| 1:1 room with, viewing images sent to encrypted rooms, ...)
| is painful or impossible.
|
| And then there's the "little" issue of it not being able to
| coexist with wee-slack. That's a bug Python 3.9, not in
| weechat-matrix, but still.
|
| I mean, I still use it because all I really need is chatting
| in already joined public rooms and for that it's better than
| that Element/Electron crap, because it's still a weechat
| after all, but it absolutely is not ready for any kind of
| serious usage. It's just a quick hack that sort of maybe
| works, sometimes.
| coldpie wrote:
| > How do people connect to matrix?
|
| Unfortunately, I don't, yet. Still waiting on a decent TUI. I
| had my hopes up for weechat-matrix-rs[1] but it hasn't seen a
| commit in two months so I guess it's dead. And so I remain on
| IRC.
|
| [1] https://github.com/poljar/weechat-matrix-rs
| Macha wrote:
| The author appears to be working on the matrix-rust-sdk which
| is a dependency of that plugin pretty consistently for the
| last month: https://github.com/matrix-org/matrix-rust-
| sdk/commits/master
| [deleted]
| waz0wski wrote:
| You could use matterbridge[1] to connect & bridge the various
| new networks including matrix back to a client of your choice -
| in my case the same znc+irssi I've been using for a long
| time[2]
|
| [1] https://github.com/42wim/matterbridge/
|
| [2] https://xkcd.com/1782/
| realA12l wrote:
| > adding Threading to Element (yes, it's finally happening!)
|
| Arathorn: Please make it similar to how Zulip works, and _not_
| how Slack or Discord have implemented it.
| ThePhysicist wrote:
| _
| encryptluks2 wrote:
| I have a feeling they'll never do this with a foundation that
| truly values open source until they plan on announcing
| something else they can control.
| Arathorn wrote:
| No, the foundation has 5 directors. Two are the people who
| started the project in the first place (me & Amandine); Three
| are completely independent: one is a university professor, one
| is a decentralisation tech lawyer, one is CEO at Parity (and
| there is zero relationship of any kind between Parity and
| Element). The foundation is very deliberately structured so
| that the Element people are in minority control.
| ThePhysicist wrote:
| Indeed, my bad.
| jillesvangurp wrote:
| A few key differences with other OSS companies that IMHO are
| positive:
|
| 1) Element or other matrix components do not require a copy right
| transfer. That means Element is hard to re-license under another
| license than its current one.
|
| 2) The license for Element is Apache 2.0. A fine choice for any
| OSS project looking to maintain a healthy ecosystem of
| contributors for decades to come.
|
| 3) The ecosystem has a diversity of stakeholders and contributors
| outside of Element the company maintaining various components,
| integrations, etc. It's an ecosystem that already serves many
| millions of users.
|
| 4) Not all the Matrix components are under the Element umbrella
| (see 3). Element is probably dominant in this community but it's
| based on merit rather than ownership. E.g. the Matrix foundation
| is mostly run by people outside of Element. Even the Element apps
| have contributions from outside Element the company (see 1).
|
| 5) Decentralization is at the core of the Element sales pitch.
| They are unlikely to want to walk back on that; or even be able
| to do that without damaging their credibility. For better or
| worse, that's what they are selling and stuck with. And they seem
| successful with it too. Hence the investment.
| j1elo wrote:
| > _1) Element or other matrix components do not require a copy
| right transfer. That means Element is hard to re-license under
| another license than its current one._
|
| That helps a lot with future-proofing the openness of an open-
| source project [1], and it's a critical detail often
| overlooked, mainly because it's a technicality of copyright
| licensing and most people understandably just want to know if
| something is open-source or not, without getting into the
| details.
|
| The simplistic gist of it (not getting into differences between
| Licenses) is that if you contribute to an open source project
| that requires copyright assignments, then its only promise is
| that _current_ versions of the code will remain with the same
| (open-source) license. Future versions might as well become
| proprietary while benefiting from your code. So depending on
| your willingness to accept that, it 's an important factor to
| consider. Sometimes you just don't care, then all right just go
| ahead. Other times you might have a stronger position on this,
| then step back and think about it.
|
| On the other hand if you contribute to a project that won't ask
| you for any copyright assignment, then your contribution is
| _yours_ , its license cannot change in the future without
| asking for your explicit permission (or dropping your code
| altogether). This is, if your contribution was a significant
| enough work; _I don 't know where the line is drawn legally_,
| but I know (from reading here in HN) that trivial enough
| contributions might not need permission to be relicensed.
|
| [1]: On the other hand, it might hinder the ability to
| commercialize it, which might end up meaning that there are no
| devs pouring serious work into it, which in turn might end up
| meaning there is no project at all :-) " _pick your poison_ ",
| I guess.
| nwellnhof wrote:
| If you contribute to a project under a non-copyleft license
| (MIT, BSD, APLv2), even without copyright assignment anyone
| can use your code for proprietary, closed-source projects
| without asking for permission. There's no need to relicense
| since the original license is permissive enough. So your
| argument only applies to copyleft licenses.
| j1elo wrote:
| Yep, I went for a coffee and realized that. But this is a
| consequence of the simplistic summary, as I warned. As
| everything, the devil is in the details!
|
| If we look closer, I believe (not an expert, though) that
| without a copyright assignment your contribution would have
| to be kept with the same license. We'd be just getting into
| the fact that non-copyleft licenses typically allow to use
| the code for building proprietary software. But AFAIK the
| contributed code itself would need to be kept with the
| original license? (that's where my knowledge is lacking)
| oefrha wrote:
| The contributed code under Apache would be like any other
| permissively-licensed third party dependencies used in
| any proprietary product; you add a copyright notice and
| possibly link to a copy (a courtesy, not even necessary),
| done.
|
| There's no devil in the details. The entire codebase can
| be taken proprietary right now and there's not a thing
| you can do. You're free to extend the last permissively
| licensed version.
| richardwhiuk wrote:
| What do you mean by "kept with the original license"?
| pininja wrote:
| The proprietary+forked code would become a mix of closed
| and open source license, but just never get released so
| you'd never be able to get ahold of it.
| Proven wrote:
| He means you couldn't relicense under another license.
|
| I think if the copyright is yours then you could.
| jcelerier wrote:
| If you make a MIT project "Foo", not protected by a CLA
| and I contribute to it, then if your company uses Foo in
| a proprietary product they still have to give the
| attribution for my code as required by the MIT license,
| as my code will still remain MIT even if embedded in a
| larger non-MIT project.
|
| OTOH if I had signed a CLA, then your company would be
| within its right to entirely strip any attribution to
| give whatever license they see fit to the code I wrote.
| samatman wrote:
| Correct, also a feature, not a bug.
|
| Some of us prefer permissive licenses, or choose between
| permissive and copyleft depending on the nature of the
| application.
|
| But here's something you can't do with my MIT licensed
| code: change the license to copyleft.
|
| Point being, if one is contributing to a project with a
| permissive license, that _should_ imply being a-ok with it
| getting rolled into some binary in a form you don 't have
| access to.
| ryukafalz wrote:
| You can't just change the license to a copyleft license,
| but you can make changes to it that are licensed under a
| copyleft license. If your fork/derivative project gets
| enough attention, you've practically changed the license
| anyway.
|
| If one is contributing to a project with a permissive
| license, that should also imply being a-ok with it
| getting rolled into a copyleft project too.
| samatman wrote:
| They're welcome to try, of course.
|
| Examples of permissively licensed code being used in
| proprietary systems abound.
|
| Has anyone ever successfully copyleft-jacked such a
| project? I grant that it's possible but I'm not aware of
| it actually happening.
| gnufx wrote:
| > if you contribute to an open source project that requires
| copyright assignments, then its only promise is that current
| versions of the code will remain with the same (open-source)
| license. Future versions might as well become proprietary
|
| That depends. I don't know the current paperwork, but I
| assume assignments for GNU software still involve a contract
| promising to maintain a substantially similar free software
| licence.
| abstractbeliefs wrote:
| I fully believe that Element want Matrix to be decentralised
| and diverse, but I don't think it's actually true.
|
| Despite years of deployment, 90%[1] of the work is still done
| by paid Element employees rather than the community. Could you
| imagine a world where Microsoft make 90% of the effort to Linux
| and still tried to call it diverse?
|
| Likewise, the vast majority (>80% anecdotally) of users on the
| main Matrix federated network live on a single instance
| centrally administered by matrix.org. Again, not a shining
| example of decentralisation at work.
|
| My worry isn't about Matrix the protocol, though I think it
| leaves many aspects to be desired. My worry is that the fate of
| Matrix rests on Element Co, which seems to be a default-dead
| start up, repeatedly needs to seek funding, and nearly went
| bust in the past.
|
| [1]: https://lobste.rs/s/emxymp/introducing_p2p_matrix#c_ilr501
| [deleted]
| samatman wrote:
| As a practical matter, I'm not concerned about this. The
| French government pays for support on a large Matrix
| deployment, a couple German states and the Bundeswehr do as
| well.
|
| Those kinds of anchor clients leave me sanguine about the
| prospects of Matrix and Element.
|
| As for decentralization, what the ~80% do is totally
| irrelevant to the other 20% of us. My company finally got off
| Slack (where 100% of users are trapped in a ransomware
| monolith) and we couldn't be happier. I federate with a
| couple other servers and it all Just Works.
|
| Matrix is federated, and the way federated decentralization
| tends to play out involves a few big 'continents' and a vast
| archipelago of small instances. If you want true
| decentralization you have to force it with a peer-to-peer
| architecture, like Urbit or Secure Scuttlebutt.
|
| Those have their place, but so does Matrix.
| GekkePrutser wrote:
| It's really time for dendrite to mature as synapse is pretty
| heavy. I think a lightweight home server will really help
| adoption.
| genewitch wrote:
| I run synapse on Gentoo and it uses next to no resources
| except disk. Load averages 0.03 for all, 366.6MB used, 97%
| idle. 14 days uptime.[0] This is like rpi model B
| compatible.
|
| We only have 5 users, and we use coturn on the same
| machine, but three of those users are also linked to
| glitter and matrix.org channels/rooms. The ~/synapse
| directory weighs in at 5GB with 2GB of that being logs.
|
| The setup took me a 'few hours' over two nights, but my
| work revolves around setting up services and software[0] -
| it may take someone else a couple of days to correctly set
| up and run it.
|
| [0] uptime reflects the rolling nature of Gentoo, and I had
| a certificate update at the same time, reboots are
| inevitable. I start with Gentoo with any new online
| service, since I know the pain points and failure modes.
| This homeserver is run on a VM in a datacenter. I have no
| complaints about synapse so far.
| Arathorn wrote:
| Lots of confusion here.
|
| The lobsters comment is from me, a year ago, talking about
| the spec and implementation work published by the Matrix
| _core team_ - i.e. the contents of https://github.com/matrix-
| org. Matrix started in 2014, and the core team formed Element
| in 2017 to fund its work, so it should hardly be surprising
| that much of that code comes from Element employees. Just as
| if Linus had chosen to fund himself to work on the linux
| kernel by creating a startup, the balance of code in the
| kernel would be different. Nowadays I'd guess it's more like
| 75% of the code at github.com/matrix-org which comes from
| Element employees contracted to work on Matrix by the
| Matrix.org Foundation.
|
| However, across the wider ecosystem, Element's contributions
| are an increasingly small minority. There are completely new
| independent implementations out there like Conduit.rs (rust
| server) or the whole FluffyChat stack (cross-platform flutter
| clients) which have almost no contributions from Element and
| build on entirely different codebases to the reference
| implementations at https://github.com/matrix-org. So, where
| it counts, I'd guess that Element probably does <20% of the
| overall code in the Matrix ecosystem?
|
| > Likewise, the vast majority (>80% anecdotally) of users on
| the main Matrix federated network live on a single instance
| centrally administered by matrix.org.
|
| Looking at the phonehome stats, it's more like 30%.
|
| > My worry is that the fate of Matrix rests on Element Co,
| which seems to be a default-dead start up
|
| Nope, if you read the Element blog post at
| https://element.io/blog/element-raises-30m-as-matrix-
| explode..., you'll see that Element is explicitly default-
| alive.
|
| > repeatedly needs to seek funding
|
| Nope, we didn't need to seek funding in this instance; we
| consciously chose to. We could have just continued profitably
| at a slower rate, but we wanted to go faster in order to
| compete with Discord & Teams etc.
|
| > and nearly went bust in the past.
|
| Nope, Element was formed _after_ we lost funding for the
| original Matrix work... which is why we formed the company.
| hjhcxz wrote:
| I'm sure the comment you're replying to is being downvoted
| by employees of your company and your fanboys, but it isn't
| false, even if you contradict the claims without evidence.
|
| And yes, I know who you are. It's very unprofessional how
| you conduct yourself on HN, wading into the comments.
| People are allowed to question the motivations of your
| company.
|
| I know I do, and your petty replies on HN continually
| convince me that Matrix is a joke; the CEO can't even let
| the community handle criticism of the project, no, he
| always takes it personally.
|
| Call me when dendrite is feature complete (never) or when a
| third party homeserver is completed (definitely will never
| happen, you list some and your site has listed them for
| years, but they aren't usable. It's a lie, one I'm
| flabbergasted you have repeated above, frankly. A bald
| faced lie, but since Matrix is a fake federation protocol
| the layers of lies shouldn't surprise me)
|
| Wake me up when you figure out how to do username account
| routing with DNS like XMPP does so that you don't need a
| centralized identity server
|
| Or does it benefit you somehow that Matrix isn't able to be
| implemented by a third party? Does the centralized identity
| server benefit you? Probably.
|
| Enjoy fleecing more investors and sucking the air out of
| the federated chat space!
| emptysongglass wrote:
| I downvoted you (I'm not an employee or affiliated with
| Matrix in any way except that I selfhost Synapse because
| it's cool) because you've veered off the good faith
| criticism path into paranoia and what looks like a
| personal vendetta, which I can't understand what for.
|
| This is a tech chat product but the way you dig into it
| makes it sound like you have bones to pick with someone
| who came to your house and killed your cat.
| hjhcxz wrote:
| "Arathorn" is the only tech CEO who has personally
| insulted me in past comments, when I used to be much more
| charitable, so yeah it's personal. I listed problems I
| had trying to run Synapse and explained the fake identity
| federation and he came out of the woodwork to run
| interference about how it's ONLY name addressing that
| isn't federated, as though that matters
|
| So yeah, it is personal. I love chat protocols and
| federation and want to be excited about Matrix but
| "Arathorn" is a liar and an asshole and he's made it
| personal. The protocol has serious problems and isn't
| above criticism but "Arathorn" isn't open to it.
|
| And he's sullying a good JRR Tolkien reference with his
| handle. He doesn't deserve that handle, that's why it's
| in scare quotes.
| soupbowl wrote:
| You come into every matrix comment section to grief
| Arathorn, you come off as the bad guy.
| kazoomonger wrote:
| Looking at https://matrix.org/faq/, I see this:
| Can I run my own identity server? See also: What
| is an identity server? Yes - the reference
| implementation is sydent and you can run your own ID
| server cluster that tracks 3rd party to Matrix ID
| mappings. This won't be very useful right now, though,
| and we don't recommend it. If you want your
| server to participate in the global replicated Matrix ID
| service then please get in touch with us. Meanwhile, we
| are looking at ways of decentralising the 'official'
| Matrix identity service so that identity servers are 100%
| decentralised and can openly federate with each other.
| N.B. that you can use Matrix without ever using the
| identity service - it exists only to map 3rd party IDs
| (e.g. email addresses) to matrix IDs to aid user
| discovery.
|
| As someone that really likes Matrix because of its
| decentralized nature, I'm not really seeing a problem
| here. TBH, I don't really care about mapping a
| foo@bar.com to @foo:bar.com. All of my matrix contacts
| I've just asked them what their username is, then started
| chatting with them.
| galbar wrote:
| The Element app even supports QR codes... It is super
| easy to start a chat with someone new
| easygenes wrote:
| I think those "phonehome stats" are exactly what most
| people are up in arms about. Particularly the exhaustive
| non-depersonalized nature of them. [0]
|
| It appears that the data which is collected includes [1]:
| Message senders Message senders are never
| encrypted Session/device IDs Due to
| Matrix's design, encrypting this would break verification
| Message timestamps It's impossible to prevent
| timestamps from leaking, since the server can simply note
| when an event is received anyway Room members
| (join/leave/invite events) Join/leave/invite and
| other room events are never encrypted Message edit
| events While contents are not leaked, an attacker
| can know when messages are edited Message reactions
| Reactions are never encrypted Read receipts
| Read receipts are never encrypted Nicknames
| Nicknames are never encrypted Profile pictures
| Profile pictures are never encrypted
|
| Put another way [2]: The Matrix ID of
| users, usually including their username. Email
| addresses, phone numbers of the user and their contacts.
| Associations of Email, phone numbers with Matrix IDs.
| Usage patterns of the user. IP address of the user,
| which can give more or less precise geographical location
| information. The user's devices and system
| information. The other servers that users talks to.
| Room IDs, potentially identifying the Direct chat ones and
| the other user/server.
|
| --
|
| [0] <https://www.hackea.org/notas/matrix.html>
|
| [1] <https://serpentsec.1337.cx/matrix>
|
| [2] <https://www.hackea.org/notas/matrix.html#facing-the-
| real-and...>
| Arathorn wrote:
| no, the "phonehome stats" i was referring to are the opt-
| in anonymous aggregated usage stats that synapse
| provides: https://github.com/matrix-
| org/synapse/blob/master/synapse/ap... etc.
|
| All the stuff you enumerate is metadata that your server
| stores in order to store your conversations. Until P2P
| Matrix lands, if you're worried about metadata, only talk
| to people on servers whose admins you trust.
| easygenes wrote:
| Thanks for the clarification.
|
| Congrats on your round. Best wishes for turning that into
| a robust truly decentralized E2EE communications platform
| that the average person won't shy from. Btw, I hope SNEK
| sticks!
| Arathorn wrote:
| Thanks :) Also, another improvement to protect metadata
| that we're working on is https://github.com/matrix-
| org/matrix-doc/blob/rav/proposal/r... (and relatedly
| https://github.com/matrix-org/matrix-
| doc/blob/neilalexander/...). By giving each sender in a
| given room its own public key, you can de-correlate the
| identities between rooms by blowing away the mapping that
| links a matrix ID to an identity in a given room. (Of
| course, a malicious actor could deliberately monitor this
| and de-de-correlate - to which P2P is the longer term
| solution.)
| kitkat_new wrote:
| > Associations of Email, phone numbers with Matrix IDs.
|
| Collected hashed at a identity server (you can choose) in
| case you decide that other people should be able to use
| the identity server to discover you via phone number
| gregwebs wrote:
| What other projects would be an example of a fast growing
| open source project with lots of development and that are
| highly distributed?
| stevenicr wrote:
| You mean like wordpress.org ?
| yakubin wrote:
| _> 2) The license for Element is Apache 2.0. A fine choice for
| any OSS project looking to maintain a healthy ecosystem of
| contributors for decades to come._
|
| The problem with Apache 2.0 is that it's incompatible with
| GPLv2. That's the main problem with copyleft licenses, they are
| made as if they were the only FOSS licenses in the world and
| just introduce incompatibilites between different camps. Apache
| 2.0 vs GPLv2, GPL vs CDDL, GPLv2 vs GPLv3[1]. I prefer to go
| with permissive licenses and save myself the headache.
| Regarding Apache, a common solution is dual-licensing under
| Apache+MIT (e.g. the default for Rust projects created with
| Cargo), which takes care of this problem.
|
| [1]: And "vN or later" is not a solution, since that's just a
| backdoor of a random org in US.
| trasz wrote:
| The problem isn't with copyleft licenses, only with GPL (in
| its various variations). You don't get license
| incompatibility problems with other copyleft licenses, eg
| MPL; you need GPL for that.
| glandium wrote:
| Don't forget the LGPL, which, in its attempt to allow
| proprietary software to use LGPLed code with conditions,
| makes it painful to use LGPLed code in free software licensed
| under anything other than the GPL.
| glogla wrote:
| Does Apache 2.0 license protect from Embrace, Extend,
| Extinguish (Microsoft) or from Embrace, SaaS, Tax (AWS and the
| like) in any way?
| goodpoint wrote:
| No. Like BSD and MIT it cannot protect from prorietization,
| tivoization and SaaS. You need GPLv3 or AGPL for that.
| skinkestek wrote:
| It is a bit more nuanced than that:
|
| The way you wrote it makes it sound like someone can make
| the project proprietary over night.
|
| They cannot and I wish GPL people would stop pretending.
|
| Whoever has a copy of the repo or even a snapshot of the
| source can continue using and developing it under the
| original license.
|
| What one, strong contributor can do is make a proprietary
| fork and stop contributing towards the original open source
| one, possibly dumping prices and thereby starving the
| original project of code and donations.
| whimsicalism wrote:
| Gplv3 doesn't protect against saas
| goodpoint wrote:
| That's why I wrote AGPL in the sentence.
| whimsicalism wrote:
| Yes, but your sentence suggests either of those would be
| protective against all of the former.
| jillesvangurp wrote:
| Together with the lack of copyright transfers, it just
| guarantees the code will always be available under the same
| license. There can't be any re-licensing of existing code
| without twisting the arms of every single copyright holder.
| No more, no less. It gives nobody an exclusive control point.
| It gives nobody exclusive rights to exploit.
|
| So, yes, Amazon can spin up as many matrix servers as they
| want. And so can MS. And so can Google. Maybe that wouldn't
| be such a horrible idea as they have mutually incompatible
| products that loosely overlap with the matrix feature set;
| those things interconnecting would be progress. Email is
| doing pretty OK decades after MS tried to embrace and extend
| via outlook and exchange. Federated communication networks
| are nice.
|
| So, that's a feature not a bug.
| maxme3 wrote:
| The MPL v2 license would be a better choice. It offers the same
| kind of terms and it explicitly compatible with the GPL
| licenses.
| georgyo wrote:
| There is no such thing as a GPL compatible license. The GPL
| is only compatible with GPL.
|
| When a license is "compatible", it allows you to relicense
| that code as GPL, sometimes with additional conditions.
|
| This means that if you link it GPL code into a MPL code base,
| the GPL requires that entire code base to now be GPL. And as
| such all other code linked against it also must become GPL.
|
| This can lead to accidentally violations.
| [deleted]
| fddddd wrote:
| please, stop comenting about this topic.
|
| you are wrong about basic gpl code linking concepts.
| marcosdumay wrote:
| Well, the bundle is GPL, the particular code is still MPL,
| so that you can still take that portion away from the
| bundle and do anything that the MPL allows.
| numpad0 wrote:
| I don't think you can ever rellicense or sublicense someone
| else's code without consent or prior arrangements.
|
| Like if I said this comment is licensed under GFDL 12.34
| and you thought GFDL 10.01 is "compatible" with it, it's
| still mine to decide under what license it is licensed.
|
| A popular phrasing found on many GPL projects are "Version
| 2 or later", but that doesn't mean you get to rewrite it to
| "AGPL 3 or stricter". That'll be a copyright violation.
| goodpoint wrote:
| > There is no such thing as a GPL compatible license
|
| On the contrary, you can use MIT, BSD, MPL, LGPL code in a
| GPL codebase without any issue. You can dynamically link
| LGPL in any codebase. You can statically link GPL in
| another GPL codebase.
|
| This is all working as intended.
| georgyo wrote:
| I don't think you are correct here:
| https://www.gnu.org/licenses/gpl-
| faq.en.html#WhatDoesCompatM...
|
| > All GNU GPL versions permit such combinations privately
|
| IE, the copyright holder can permit anything they want,
| as they own the copyright
|
| > they also permit distribution of such combinations
| provided the combination is released under the same GNU
| GPL version. The other license is compatible with the GPL
| if it permits this too.
|
| IE the license grants the ability to add the GPL license
| that code.
|
| ---
|
| Taking this to the MPL example:
| https://www.mozilla.org/en-US/MPL/2.0/
|
| > 1.12. "Secondary License"
|
| > means either the GNU General Public License, Version
| 2.0, the GNU Lesser General Public License, Version 2.1,
| the GNU Affero General Public License, Version 3.0, or
| any later versions of those licenses.
|
| > 3.3. Distribution of a Larger Work
|
| > ... If the Larger Work is a combination of Covered
| Software with a work governed by one or more Secondary
| Licenses, and the Covered Software is not Incompatible
| With Secondary Licenses, this License permits You to
| additionally distribute such Covered Software under the
| terms of such Secondary License(s), so that the recipient
| of the Larger Work may, at their option, further
| distribute the Covered Software under the terms of either
| this License or such Secondary License(s).
|
| ---
|
| The MPL 2.0 is compatible with GPL because it explicitly
| grants the right to release MPL code as GPL. All the
| copyright holders of MPL 2.0 code have authorized this
| secondary licensing because the license they released it
| as says so.
|
| This means that in cases where compatibility matters,
| then the MPL2.0 code base has all the additional
| restrictions that the GPL has. And the GPL is _all_ code,
| which means it spreads out from there. If you are using
| GPL-2.1, MPL-2.0, and APACHE-2.0 code in the same code
| base, there is a violation.
| goodpoint wrote:
| First you wrote:
|
| > There is no such thing as a GPL compatible license
|
| ...and later on:
|
| > MPL 2.0 is compatible with GPL
| georgyo wrote:
| If you want air quotes around compatible, I can add them.
| However the entire point remains.
|
| It is GPL compatible because the GPL licenses can
| explicitly be added to it. Adding the license requires
| all of the restrictions that licence brings.
| goodpoint wrote:
| Is your entire point that GPL implements copyleft?
| georgyo wrote:
| My original comment and point has not changed. The GPL is
| only compatible with the GPL. The only way for a license
| to be compatible with the GPL is to have the ability to
| license under the GPL. We have proven that is the case.
|
| There is a lack of awareness and understanding of how
| this can transitively affect things accidentally.
|
| For the record I am all for GPL code. I think the GPL is
| a fantastic license that has enabled great good in the
| world. But there are reasons why a company may not want
| to release code that is compatible with it.
| Artistry121 wrote:
| I have a pretty firm belief that matrix will form a core
| background of the next era and am building a software solution
| for project and life management that's completely decentralized
| on top of it.
|
| There's a magic here in the interoperability and fact that so
| much hard work has been done to make it ready. The ability for
| this and IPFS to work together is pretty remarkable in the scope
| of what can be created.
| Artistry121 wrote:
| Sneak peek of the interface we're building on top of matrix - a
| timeline focused universal interface for projects
| [deleted]
| jazzyjackson wrote:
| It's not clear to me what extent IPFS is already in use in
| matrix applications. If I want to use web torrents or
| beaker/hyperdrive instead that should be possible, no? What
| assumptions does the matrix protocol make about attachments /
| media uploads?
|
| Haven't tried developing for matrix yet but I'm intrigued by
| its inertia right now.
| cvwright wrote:
| It looks like some of the Matrix devs were thinking about
| using IPFS for the Matrix "media" repository. It's basically
| an object store where the Matrix server keeps images and
| videos and files.
|
| Coincidentally, that spec change proposal looks to have been
| posted exactly one year ago today. Doesn't look like there's
| anything concrete yet, but still there's obvious
| opportunities for combining a content-addressable object
| store API with a distributed content-addressable file system
| back end.
|
| https://github.com/matrix-org/matrix-
| doc/blob/travis/msc/ipf...
| jsjsjsjsjsjs wrote:
| Magic will be gone when there is no mass adoption due to bad
| UX. And UX is not that good right now.
| domoritz wrote:
| This. They really need to invest in a better UX above
| anything else right now, imo.
| MayeulC wrote:
| Oh, but Matrix is much more than an instant messenger. It's a
| replicated database with ACLs.
|
| It could theoretically fail in the IM space and still succeed
| in the data sharing space. For instance, you could build an
| Activitypub-like ecosystem on top of it.
| pkulak wrote:
| Really? I've been extremely happy with Element.
| [deleted]
| Artistry121 wrote:
| I imagine that these eventually become an "OS" that ties and
| links together peoples interactions through time. And the
| federation allows people to share timelines / information in a
| way that allows for new forms of collaboration- ones where it's
| less focused on owner - employee relations and more P2P. Email
| me if you're interested. I need some final designs made and am
| looking for developer partners - I have business cases and
| clients set up.
| encryptluks2 wrote:
| Matrix isn't P2P. You didn't even provide an email. No one is
| going to reach out unless you can create something to
| document at a high level what you think is so special about
| your ideas.
| seizethegdgap wrote:
| > Matrix isn't P2P
|
| Incorrect.
|
| https://github.com/matrix-org/pinecone
|
| It's nowhere near mature/stable, but they are definitely
| working on it.
| goodpoint wrote:
| This is a very bold claim. There are a lot of projects and
| protocols to do so.
|
| Matrix was not designed with that goal in mind.
| Artistry121 wrote:
| Matrix was designed to be extensible and with extreme ability
| to customize and interact with outside tools. A solid
| interface on top of Matrix could allow for everything from
| messaging to transactions to project management - and even
| massive timeline interfaces. Matrix is an interface for
| federation at scale - for any type of communication.
|
| Here's a sneak peek at some of our interfaces:
|
| https://www.icloud.com/sharedalbum/#B165qXGF1GxreFs
| goodpoint wrote:
| The very same can be said of XMPP, ActivityPub and even
| XHTML. It's far from enough.
|
| Even email can carry arbitrary payloads, federates natively
| and scales extremely well.
| eimrine wrote:
| Element is strange, Ive tried to connect a buddy and he told me
| that he cannot read my msgs depsite I can read his ones. So, we
| decided to switch to xmpp and it works great for us.
| notyourday wrote:
| So... how is whoever invested in Element going to exit?
| foreign-inc wrote:
| Everyone who thinks that because Matrix is Apache v2 license, it
| will remain permissive open source is ignoring the reality of an
| active project. If Matrix changes license tomorrow, the old code
| will still be Apache v2. But are you going to fork the project to
| keep it Apache v2?
|
| For some data point, look at recent relicense of MinIO, Grafana,
| Loki, Vector.dev etc.
| lolinder wrote:
| Top comment right now points out that Matrix doesn't require
| copyright assignment, which means they have to get permission
| from every contributor or rewrite the code in order to
| relicense.
| foreign-inc wrote:
| They don't. They can fork the "apache v2" version and start
| adding non apache v2 code given they are the primary
| contributor. If they own the trademark, they can call the new
| forked version "matrix".
|
| What non having copy right assignment means is that they
| can't change the license of existing stuff. But they can
| change the license of future stuff using existing apache v2
| licensed code which is permitted.
| 4mmFp3ae wrote:
| I really hope they'll use the money to fix the confusing account
| creation and maintenance because I cannot use Element anymore for
| some reason.
|
| My main gripes are that you cannot reset a password by username,
| and you cannot add a phone number that belonged to a deactivated
| account.
| aasasd wrote:
| I hope fifty bucks out of this go toward Element on Android not
| slapping together separate paragraphs. And another hundred to
| display images that are larger than 5.5 mb.
| Amin699 wrote:
| Needless to say, Matrix wouldn't exist without you: the protocol
| and network would have fizzled out long ago were it not for all
| the people supporting it (the matrix.org server can now see over
| 35.5M addressible users on the network!) - and meanwhile the
| ever-increasing energy of the community and the core team
| combines to keep the protocol advancing forwards faster than
| ever.
| grishka wrote:
| I want to love Matrix, but it still hasn't got a real native
| macOS client (not qt, not electron, _native_ one made with
| Cocoa). It 's really a shame. Though I do see its potential as a
| protocol, and the nice part is that it's federated.
| 29083011397778 wrote:
| I don't have a Mac, so I can't test it, but isn't Seaglass [0]
| a native Mac client?
|
| [0] https://matrix.org/docs/projects/client/seaglass
| grishka wrote:
| Yes. Of course that was the first thing I installed. It's
| buggy and abandoned.
| Andrew_nenakhov wrote:
| Matrix people like to claim that it is a protocol, because it is
| 'governed by the foundation'. Make no mistake, it is not. It is a
| product.
|
| True foundation directs the development of a standard, and
| considers the interests of all parties. But in this case, there
| is just one party that means anything - the company that creates
| the actual product - and it is obvious that the foundation is
| powerless to resist any of its initiatives. Which makes the
| Matrix foundation just a facade, to better appeal to some people.
| user_agent wrote:
| This is where I'm getting suspicious. 30M isn't a trivial
| amount of money...
|
| @Andrew_nenakhov's comment is on point. Normal initiatives of
| this kind are organized differently. This doesn't look good
| regarding the future stability of the initiative.
|
| ---
|
| On top of that @sprash has mentioned some valid concerns about
| Matrix being a potential metadata sponge (below in the
| comments).
|
| Let me add some food for thought for you. Maybe you're going to
| get suspicious too.
|
| a) On the Matrix website, the one with the news about getting
| the 30M, we're being given only two kind of information: who's
| behind the leading round regarding the investments made, and
| what features are going to be developed due to that donation.
| Now, we know nothing about who's actually giving the money,
| because both Protocol Labs and Metaplanet serve as proxies
| here. On top of that pointing the reader to the new features
| part seems to me like a: ,,forget about the money part, take a
| look on what we're going to do with that, take a look on all
| those shiny things!!!".
|
| b) Both Protocol Labs and Metaplanet are kind of famous
| companies (proxies). The second one invested in the Boring
| Company for instance. It just looks so good. It's like a
| miracle. Matrix is getting attention it deserves... But why on
| earth that happened? (take a look on (c)).
|
| c) Protocol Labs has strange ties to World Economic Forum
| [1][2]. They are interested in Protocol's work in the internet
| space in general. I don't like that at all. I fundamentally
| don't trust WEF and I consider whatever they ,,touch" cancer.
|
| ---
|
| I'm on the market for something that's going to help me and my
| friends replace Signal. Matrix looks very promising, but after
| a careful consideration it also looks like it really might be a
| metadata sponge. Yeah, it's all rumors, and establishing real
| information about the parties involved and their motivations
| isn't possible. But a suspicion is enough. It looks almost too
| good...
|
| This is how I decided to go with XMPP instead.
|
| Good luck. Make your own informed decisions.
|
| ---
|
| [1] https://www.weforum.org/organizations/protocol-labs
|
| [2]
| https://www.reddit.com/r/ipfs/comments/os8plh/the_world_econ...
| jnsaff2 wrote:
| Metaplanet is the investment fund for Jaan Tallinn, one of
| the four founding engineers of Skype. He is definitely a very
| positive sign for this investment in my eyes. Having worked
| with him a long time ago and followed his doings and
| presentations [1] it gives me much hope for Matrix,
| especially as I run my own homeserver and really like the
| vision.
|
| [0] https://www.theregister.com/2021/07/27/element_seriesb_th
| irt...
|
| [1] https://www.youtube.com/results?search_query=jaan+tallinn
| kitkat_new wrote:
| > But in this case, there is just one party that means anything
|
| not true, two more companies building on Matrix:
|
| - https://www.beeper.com/
|
| - https://famedly.com/
| Andrew_nenakhov wrote:
| There were a lot of companies building on Twitter API back in
| 2010. Do you remember what happened to them?
| encryptluks2 wrote:
| Most accurate comment right here. Anytime any legitimate
| criticisms get brought up they are quickly downvoted.. here on
| HN they get flagged so you can't even see them. If you want
| open and federated then go with XMPP.
| goodpoint wrote:
| The downvotes you are getting only prove the echo chamber :(
| unethical_ban wrote:
| I think people complaining about echo chambers get
| downvoted for being annoying and without substance, which
| unfortunately validates their victim complex.
|
| The root comment of this thread isn't "oppressed" - at
| least he put effort into the post, and others in their
| rebuttal.
| rvz wrote:
| I welcome these alternative suspicions and will be taking
| them with a grain of salt. We'll see what the Matrix
| ecosystem will do with the money. Until then, we can only sit
| back and wait.
|
| > Anytime any legitimate criticisms get brought up they are
| quickly downvoted.. here on HN they get flagged so you can't
| even see them.
|
| First time?
|
| I have the suspicion that someone on HN setup a downvote bot
| on me so that for any comment I post, it is immediately
| downvoted even when I follow the _' HN guidelines'_ and
| submit tons of evidence to backup my claims.
|
| This innocent comment will probably prove both of us right on
| our suspicions. Ultimately I want to be proven wrong here,
| but we'll see.
| thrwaeasddsaf wrote:
| Why don't you just stop posting. You're not welcome here.
| FieryTransition wrote:
| How do you know this is a negative influence?
|
| Element being made by the same people who made matrix, how much
| difference is there?
|
| Is it not possible to see the source code? Is it not possible
| to partake in the development process in the same way most
| other open source projects work? Is it hard to connect to the
| network?
|
| I see it more as a net positive given what is known.
| Andrew_nenakhov wrote:
| For a product, it is a positive influence. For protocol - not
| so much.
|
| Would you be happy if Google had the ability to unilaterally
| define web standards?
| FieryTransition wrote:
| But everything is based on a hunch with a negative
| worldview as a lens to view the information with, that just
| how it feels when giving out these speculations. Politely
| understand, I'm not saying you are wrong, but I am saying
| it is wrong to assume malintent due to lack of information.
|
| And given their goal of being a general underlying
| protocol, to be used in different specific professional
| industries, it would be very damaging to close down
| feedback or the protocol in general, from outside
| influence. A hospital might need a specialized client to
| handle the needs of the profession, while a ministry might
| have a third, one does not fit all.
|
| But I see the skepticism, because if the protocol can be
| used by one party, which ends up hosting most of the
| servers, to gather metadata, then having widespread use
| would allow insight into a rather large dataset of people
| and countries. But the onsite premise of this software, is
| the whole reason that etc. the French government started to
| back the protocol and mistrust for foreign communication
| services. If you have secrets, why would you not just host
| this yourself? And there's the big difference between
| google and matrix, you can control all your data yourself,
| if you want. Totally block outside communication, setup
| private tunneling, separate a virtual network etc. I don't
| think twitter/whatsapp/whatever allows you to host their
| server infrastructure and block off access :-)
| Arathorn wrote:
| Matrix is a protocol because... it's a protocol. The spec is at
| https://matrix.org/docs/spec. There are loads of completely
| independent implementations of it, both clientside and
| serverside. Additionally, the spec is governed by the non-
| profit Matrix.org Foundation (https://matrix.org/foundation).
|
| It's true that we (the team who created Matrix) also created
| Element as a for-profit startup to fund the core team to work
| fulltime on Matrix - and as anyone who works at Element will
| tell you, the reason the company exists is to grow Matrix and
| make it successful. In an ideal world Matrix ends up being a
| huge industry in its own right, effectively replacing the PSTN
| & email industries, and Element ends up with some small (10%?)
| marketshare alongside loads of other Matrix vendors out there
| doing their thing.
|
| Just as XMPP wouldn't have happened if Jabber Inc hadn't
| bootstrapped the ecosystem back in the day; Element has a
| similar (but hopefully more successful) mission with Matrix.
| Or, perhaps similar to how Netscape helped bootstrap the open
| Web.
|
| In other words: you are wrong; it's not a facade.
| Andrew_nenakhov wrote:
| Rocketchat also has the open spec.
|
| On 'loads of completely independent implementations': how can
| those independent developers stop Element from pushing some
| hypothetical changes to the protocol you would want to
| introduce against their wishes?
| goodpoint wrote:
| Spot on. When one organization controls servers, protocols
| and main implementation it creates lock-in just like closed
| source software.
|
| Signal is a good example.
| d110af5ccf wrote:
| It's permissively licensed FOSS. If the primary maintainers
| go against the community and can't be reasoned with it will
| be forked. If a fork doesn't end up having enough momentum
| to maintain it then perhaps the original wasn't actually
| doing such a bad job after all.
|
| This issue is hardly unique to Matrix.
| Andrew_nenakhov wrote:
| Not really. You are ignoring the network effect. The vast
| majority of the matrix network, including the by far the
| largest node, is using the software developed by Element.
| If they change something, any competing spec will lose
| access to federation, and, subsequently, users.
| Arathorn wrote:
| They'd object, either while the MSC was being drafted, or
| during the FCP (Final Call for Proposal) period. If the
| Spec Core Team voted to merge something which the community
| didn't believe was aligned with Matrix, then they'd appeal
| to the board of the Foundation (i.e. the Guardians), who
| are legally obligated to ensure that the only things which
| get merged into the spec are aligned with the stated
| mission and values of the project (as per the Mission and
| Values sections of https://matrix.org/foundation). If the
| Guardians fail to adhere this, they would complain to the
| UK non-profit regulator, and the foundation would get
| fined/dissolved. The recourse of the guardians would be to
| either get the Spec Core Team to change their mind or to
| replace the Spec Core Team to get back in line with the
| mission. The process for doing this is laid out in the
| Articles of Association of the foundation: https://matrix.o
| rg/media/2019-06-10%20-%20Matrix.org%20Found...
| Andrew_nenakhov wrote:
| So, all the safeguarding positions are predominantly
| filled with Element employees (according to another
| commenter)? [1]
|
| Consider me not impressed.
|
| [1]: https://news.ycombinator.com/item?id=27970233
| Arathorn wrote:
| No, those are not the safeguarding positions; the Spec
| Core Team are the folks who approve PRs to the spec.
| Originally they were 50/50 element and non-element,
| although it's drifted thanks to members of the team
| choosing to work at Element so they can work on Matrix
| fulltime.
|
| The safeguarding positions are the directors of the
| Foundation (aka Guardians), which is very deliberately
| majority non-element (3:2).
|
| Why not spend your time improving XMPP rather than
| complaining about Matrix?
| Andrew_nenakhov wrote:
| I'm criticizing matrix because it is a product of NIH
| syndrome [1] that should not have existed in the first
| place.
|
| If you wanted an open federated protocol, you could have
| spent your time adding to an existing federated network.
| Everything you do with matrix is easily possible with
| XMPP. Instead, you want a protocol fully controlled by
| _you_. I oppose this goal and spread of such products.
|
| And yes, I do spend all my time improving XMPP.
|
| [1]: https://en.wikipedia.org/wiki/Not_invented_here
| soupbowl wrote:
| XMPP failed for normal users. When I switched to matrix
| years ago it was because the XMPP ecosystem was totally
| inconsistent. The best client was on android but no
| desktop clients integrated properly with it (send files,
| encryption, roaming) especially across multi OSs. I moved
| to matrix in the early days and all those problems went
| way.
|
| What you see as NIH I see as building something from the
| ground up that works better than what was currently
| available.
| Andrew_nenakhov wrote:
| No. Matrix could just build Xmpp clients for all
| platforms consistently, and it would work out much better
| than building their own atrocious server. It is a very
| typical NIH-approach.
|
| Also, what you call a totally inconsistent ecosystem is
| what real ecosystem looks like. Matrix looks better in
| this regard precisely because it is not a protocol. It
| didn't yet deserve to have such problems.
|
| I also don't think it'll ever be able to successfully
| transition to a real ecosystem because Arathorn here
| always brushes off concerns about governance of the
| protocol, which shows that he doesn't have the mature
| understanding of the nature of the problem.
| foresto wrote:
| Unless something has recently changed, XMPP also failed
| on the server side for normal users:
|
| - Finding a practical provider is nearly impossible,
| because all of the major ones closed their public XMPP
| service years ago, and most people don't know what
| qualities to look for in a small provider, let alone
| understand why those qualities matter.
|
| - Even if they get help from a friend and manage to find
| a reliable server that supports the magic combination of
| XEPs that are needed to make things work, chances are
| that server is no longer accepting new users.
|
| - Even if they manage to get an account on a
| featureful[1], trustworthy, stable, free[2] server, many
| don't last more than a few years, so there is a high
| chance that the user's new online identity will evaporate
| before long.
|
| [1](Required features include end-to-end encrypted group
| chats with offline delivery, among other things.)
|
| [2](Yes, free. That is critically important for mass
| adoption today.)
|
| I'm not a normal user, in the sense that I have far more
| technical knowledge than most people who use messaging
| services. I actively used XMPP for at least a decade;
| probably closer to two. I tried last year to piece
| together an XMPP-based solution that my friends and
| family could use, but even I was unable to solve all the
| problems I found in a way that would work for normal
| users.
|
| And then there's the client side, which is also
| problematic, as soupbowl said.
|
| This has been the state of things for quite a few years.
| The only people I still see pushing for XMPP are people
| who have major blind spots. Some of them have experience
| only with small groups, and have not considered how a
| whole world of people conversing presents different
| challenges. Others (usually tech folks) have had a good
| XMPP provider and comfortable client software for years,
| and have forgotten how much knowledge it takes to get set
| up in the first place. A few are people who run small
| for-profit XMPP services or develop XMPP software, and
| are therefore not exactly seeing things objectively.
|
| Dear Jabber, I'm sorry. I liked you. I had high hopes for
| you. I might even still consider you for niche purposes.
| But as a general purpose messaging network for regular
| people, you have failed. It would take a lot of effort
| and resources to make you viable, and I don't see any
| sign of that coming. The closest you came was when Google
| and Facebook embraced you, but those days are long gone.
|
| Meanwhile, Matrix is succeeding. The rough spots are
| being fixed. The bloated clients are getting competition.
| The missing features are appearing. Even as a work in
| progress, it is already usable for some of us, and it's
| consistently moving in the right direction. Importantly,
| I can tell a regular person where to get it and (often
| with no help) they can be chatting with me in a few
| minutes.
| rkangel wrote:
| > effectively replacing the PSTN & email industries
|
| I could see a path to Matrix replacing email (and it's the
| _only_ one of the current candidates I would be happy with
| doing that), but how could it end up replacing the telephone
| network? Does it have voice capability?
| hestefisk wrote:
| Yes there is VoIP capability. And video as well.
| lbotos wrote:
| Matrix does support voice chat. I use it every day (and
| it's been pretty good.)
| oever wrote:
| Did you measure the latency? Latency should be below
| 100ms to have a pleasant conversation. Talking over a
| dedicated low-latency app like Jamulus is much nicer than
| the enormous latency in video calls.
| lbotos wrote:
| I have not measured the latency but if both participants
| are on wifi there is usually no perceptible latency with
| my participants. (US -> UK calling daily)
|
| If either of us is on mobile, sometimes latency can creep
| in, but this also happened on whatsapp too. That's the
| nature of mobile IMO.
| lokedhs wrote:
| Yes. I haven't used it so I can't tell how complete it is.
| But it exists.
| https://matrix.org/blog/2018/02/05/3-d-video-calling-with-
| ma...
| ThePhysicist wrote:
| _
| Arathorn wrote:
| what are you talking about? Are you confusing Parity with
| Protocol Labs? They are completely unrelated companies
| (other than both beginning with the letter P :/)
| ThePhysicist wrote:
| Ah ok, my mistake, sorry.
| jasonzemos wrote:
| > Element ends up with some small (10%?) marketshare
| alongside loads of other Matrix vendors out there doing their
| thing.
|
| What is a good reason for Element to relegate itself to only
| 10% of its own market and allow other vendors to pick up the
| remaining 90%? Can you name a product or service which
| Element is unable or unwilling to provide that competing
| investment could make returns on? If you can, why not pivot
| into that yourself? Can you assure parties investing in
| Matrix that Element is a trustworthy and synergistic counter-
| party?
| scrollaway wrote:
| > _What is a good reason for Element to relegate itself to
| only 10% of its own market and allow other vendors to pick
| up the remaining 90%?_
|
| In a healthy ecosystem, the primary implementations do not
| represent most of the clients and servers.
|
| HTTP for example is healthy because there are many http
| servers, many http clients, they're all pretty compatible
| and replaceable, and none of them represent the primary
| implementation with its own off spec quirks that others
| need to take into account.
| OJFord wrote:
| The obvious answer is that it would be jack-of-all-trading,
| and others would focus on one area, do it better, perceived
| to be better, or just differently.
| Arathorn wrote:
| > What is a good reason for Element to relegate itself to
| only 10% of its own market and allow other vendors to pick
| up the remaining 90%?
|
| From a purely capitalist perspective, 10% of a $1TB
| industry is better than 100% of a $10B company.
| dsr_ wrote:
| A growing ecosystem where the largest participant is 10% of
| the userbase is one which is immune from antitrust
| concerns.
|
| It's likely one that is responsive to user needs.
|
| It's everything that capitalists say that they want: a
| healthy competitive marketplace.
| roblabla wrote:
| Every single time matrix comes up, people make this argument
| like it's some sort of massive illumination. Guess what? Every
| protocol started with a single major stakeholder. The internet
| was the military, HTTP/2 was google, and JS was netscape.
|
| The foundation is not a facade. It has a rather clear
| governance system, and while it is predominantly populated by
| Element employees, that's mostly because most people passionate
| about matrix end up working there. When the fondation was set
| up, it actually had a 50/50 split between community members and
| elements employees in the core team, but the community members
| ended up joining element.
|
| What makes matrix a protocol is that absolutely anyone can
| implement it, and anyone can get involved in the process to
| improve the spec.
| Andrew_nenakhov wrote:
| > What makes matrix a protocol is that absolutely anyone can
| implement it, and anyone can get involved in the process to
| improve the spec.
|
| What makes matrix a product is that nobody can tell Element
| what to do, and people who can get involved in the process of
| improving the specs would have to accept any changes brought
| to them by the people who truly own it.
| staz wrote:
| > Every single time matrix comes up, people make this
| argument
|
| it's often the same group of people too... Andrew_nenakhov
| "forgot" to mention it but he develops a XMPP client and
| likes to pop up in the comments ofpost on Matrix to complain
|
| edit: I'm not really taking a side on either XMPP or Matrix,
| I wish for both to succeed but I'm currently disappointed by
| both. I'm just getting a bit tired of XMPP fanboys spewing
| FUD every time Matrix is mentioned
| Andrew_nenakhov wrote:
| What I do has little do to with Matrix masquerading as an
| open internet protocol while being fully owned by one
| commercial corporation. It is roughly the same to XMPP as
| AMP are to HTTP. That is the only reason I oppose it.
|
| If it wasn't, I would not rule out developing a Matrix
| client (though doubtful, I don't really like the protocol
| and implementation)
| Arathorn wrote:
| why disappointed on the Matrix side ooi?
| staz wrote:
| Mainly messages getting delayed or undelivered (often on
| the IRC bridge), everything getting randomly very slow,
| encryption randomly breaking... sadly what I consider the
| usual for Matrix.
|
| I recently had a particularly vexing issue in a small
| encrypted room of 3 people, new messages were shown as
| undecrytable and then only readable a few hours later, we
| never figured out why.
|
| I re test it every few months/years because I hear it's
| getting better, the server is properly configured now,
| encryption system was remade, there is a new client,
| etc...
|
| Losing my whole chat history each time made the endeavor
| even more frustrating. I know not everyone keep logs but
| I can search my Mails and Irc logs from 20 years ago and
| I find it really useful.
|
| Sorry for the rant but since you asked. Like I said I
| fully support your work on Matrix, I just find it so ...
| frustrating and it make me sad because I really like the
| idea.
| vector_spaces wrote:
| I hear you. Personally I'm hesitant to recommend anything
| in the Matrix ecosystem in large part because there are
| mutually verified users on my server who haven't been
| able to talk to each other in like 10 months, and the
| issue thread has been stagnant for about that long.
| Frankly it's fine that there are bugs and it's even fine
| that there are bugs impacting core functionality for such
| an ambitious project, but it's frustrating that this
| ecosystem falls down so hard when it comes to providing
| an accessible experience for non-technical users (i.e.
| when things don't work, it's extremely ungraceful and
| unclear what exactly is happening or why).
| Arathorn wrote:
| Thanks for spelling it out. You really shouldn't ever
| lose your chat history, but it sounds like something is
| going horribly wrong on your encryption.
|
| As part of the funding we're setting up a dedicated
| crypto team (at last) to focus on nothing but the
| remaining encryption problems. It's super embarassing
| that these failure modes can still exist today though -
| sorry :(
| shoto_io wrote:
| How will the investors get their money back on this investment?
| normaler wrote:
| https://news.ycombinator.com/item?id=27906336
|
| In this case for example Matrix has been choosen as the
| Protocol to be used to connect all manner of
| Healthcareproviders, Healthinsurances and State Entitys in the
| Health sector in the future.
|
| This is a highly fractured environment where there is alot of
| distrust and animosity between all the parties.
|
| I see this e.g. as an incredible chance to provide matrix
| related services even for small companies in germany.
| rapsey wrote:
| Meh that is a pretty terrible place to try and make money.
| The only thing worse may be trying to sell to schools.
| normaler wrote:
| Try not to think about hospitals, but more about all the
| individual doctors offices that also need to be connect to
| this environment and don't have to to go through a EU wide
| bidding process.
|
| E.g. there are more than thousand software solutions that
| are registered with the health insurance companies to
| manage patient data and billing processes.
| robertwt7 wrote:
| It's really cool to see how people can foresee how to
| monetize these kind of startups whereas myself as a developer
| have been struggling to think the potential in the business
| side.
| hestefisk wrote:
| Matrix / Element also run a private chat service for the French
| government to get their employees off Slack and WhatsApp for
| sensitive comms. I bet that has paid a decent support contract.
| the_duke wrote:
| Element sells business plans. [1]
|
| In addition, Matrix has been chosen for quite a few large
| deployments by governments, so there presumably are large-ish
| support contracts associated with those.
|
| If that's enough to justify a 30 Million round is another
| question.
|
| > there are no plans to use cryptocurrency incentives in Matrix
| or Element any time soon
|
| Note the wording here... "any time soon" is quite different
| from "no plans, period".
|
| [1] https://element.io/pricing
| darthrupert wrote:
| Slack's valuation in 2019 was over 20B. 30M ain't much.
| SahAssar wrote:
| Why do you think Element is trying to optimize for short
| term valuations?
| factorialboy wrote:
| Self-managed Slack / Teams alternative for enterprise users?
| Tomte wrote:
| I'd rather see Zulip adopted.
| dijit wrote:
| Seeing the Rust-lang zulip has absolutely ruined slack for
| me.
| factorialboy wrote:
| That's fine, I'm just exploring monetization options, not
| making any claims of superiority.
| scrollaway wrote:
| Matrix is a protocol. There's a lot of tooling and applications
| to be made around said protocol, plenty of which could be sold
| on on a license basis, support for enterprises etc.
|
| Matrix has a fantastic B2B potential. It's just early.
| rvz wrote:
| Exactly. The Matrix ecosystem is already used by governments
| in European countries and healthcare providers as well so
| that justifies the valuation of this fundraising round.
|
| The enterprise potential for the Matrix ecosystem which
| includes Element is almost like what GitLab has done but for
| Git services and much more.
|
| > The majority of the core team is now employed by Element,
| an independent company set up to hire the team and support
| Matrix's development. Other contributors are funded by their
| own employers or donate their own time to the project.
|
| At least they are not fully reliant on donations and they
| have a solid way of making money.
| goodpoint wrote:
| That does not answer the question.
| raxxorrax wrote:
| It should be mentioned that it also allows for distributed
| authentication providers (home servers). A very important
| feature and big tech strategy is not hiding this. But you can
| keep Google, Apple, Microsoft and similar completely out of
| the loop.
|
| The name of the protocol is very badly chosen though.
| scrollaway wrote:
| Do you know if they have a mechanism for hosted servers
| with your own domain name yet? This feels like a big thing
| missing for wider enthusiast adoption.
| [deleted]
| curryst wrote:
| Yeah, they've had that for a long time. I ran my own
| server on my own domain name a couple years ago or so.
| raxxorrax wrote:
| To be honest, I am no expert on Matrix, but I thought you
| can just host your own server on your own domain. That
| was the base assumption for my comment and I hope that is
| correct. They have a server reference component (synapse)
| that you could host anywhere I think.
| scrollaway wrote:
| Right but maybe you don't want to host your own server,
| but do want your own domain. Like emails.
| gary-kim wrote:
| Element's primary paid service is Element Matrix Services
| [1] which is exactly for that. They run a Matrix server
| for you, optionally on a domain that you provide.
|
| [1]: https://ems.element.io/
| karmanyaahm wrote:
| That's not possible yet, see
|
| https://github.com/matrix-org/matrix-
| doc/blob/neilalexander/...
| karmanyaahm wrote:
| That's not possible yet, see this proposal
|
| https://github.com/matrix-org/matrix-
| doc/blob/neilalexander/...
| cvwright wrote:
| The proposal that you linked is all about portable
| identities, tied to public keys. Is that really necessary
| for Element to host a server on a user's domain?
|
| I would have thought it would work just like outsourcing
| your web server or your email service. You generate a DNS
| name and point it at their IP address. Then they get a
| certificate and start serving traffic for your domain.
| Easy peasy.
| tadfisher wrote:
| They receive shares of the company's stock, which is a security
| that can be exchanged for other forms of value, including
| money.
| sprash wrote:
| They won't. Matrix is a meta data sponge hence it is heavily
| sponsored by the intelligence community. Truly descentralized
| and peer-to-peer solutions like Jami won't recieve such
| funding.
| yuchi wrote:
| Interesting take. Do you have any reference to back these
| allegations up? (Honestly interested)
| callahad wrote:
| I work at Element. At first blush,
| https://serpentsec.1337.cx/matrix seems like a fair writeup
| of Matrix protocol metadata, with examples, by a third
| party.
| easygenes wrote:
| What's your take on this analysis?
| https://lukesmith.xyz/articles/matrix-vs-xmpp
|
| It seems like the connection to Amdocs and their interest
| in collecting metadata for surveillance is a stain on the
| privacy-focused image.
| olah_1 wrote:
| It is interesting that the funding from them happened
| very early on, at the same time as the design of the
| protocol itself.
|
| Now it is too late to rethink the design to be less of a
| honeypot. So the only solution is P2P matrix. But even
| P2P matrix will need some way to back up the metadata so
| it's saved between sessions. So again the honeypot seems
| unavoidable.
| Arathorn wrote:
| that analysis seems to be a hatchet job in favour of
| XMPP, complete with a deeply unpleasant undertone of
| antisemitism...
| kevincox wrote:
| My main problem is that many new features seem to leak
| more and more data. Encryption support is always "will be
| added later". For example if you want to send a sticker
| or any inline image you need to upload it to the server
| in plaintext. Topics and profiles are unencrypted even in
| "encrypted rooms". Matrix is a pain-text protocol with a
| couple of encrypted extensions on top. Even worse is that
| most clients will happily let you use these leaky
| features in encrypted rooms with no warnings.
|
| I love Matrix, it is actually my primary chat network.
| But the way these features are getting added makes me
| really disappointed. You don't make a secure protocol by
| stuffing as many features as you can then adding
| encryption later. You build a secure protocol by making
| sure that every feature added is secure from the start,
| otherwise it is rejected or needs to explicitly justify
| why it can't or shouldn't be made secure.
| goodpoint wrote:
| It's a simple fact: a distributed/p2p application that
| cannot be monetized does not generate revenue.
| Arathorn wrote:
| Matrix's architecture today means that the servers can see
| who their users are talking to, and when - but not what
| (assuming it's end-to-end encrypted). Just like a PGP mail
| service like Protonmail. Because Matrix stores conversation
| history on the server (unlike Signal) so you can get at it
| when from multiple logins, you end up with that metadata
| stored on the server.
|
| We're fixing this by working on P2P Matrix (as per the blog
| post - it's one of the main initiatives that the funding is
| going towards).
| https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
| explains how P2P addresses the metadata problem.
|
| The whole "heavily sponsored by the intelligence community"
| thing is a conspiracy theory. It's true that Matrix is
| popular with government and national security folks and
| Element gets money from them... but it's because they want
| the E2EE and data sovereignty for themselves, rather than
| because they are trying to torment their citizens(!!)
| logikblok wrote:
| Congratulations on the raise and keep up the good work!
| the_duke wrote:
| If you read the post, the very first work item they mention
| is
|
| > finish building out P2P Matrix and get it live
|
| ps: p2p is nice to have, but also comes with a lot of
| problems and and probably shouldn't be a first choice for
| many users.
| Arathorn wrote:
| We're hoping to get it good enough so that it literally is
| the first choice for new users - and it's only if they
| consciously want to pin their data (and metadata) to a
| server that they'd do so.
| olah_1 wrote:
| Who wouldn't want their data pinned? That is the expected
| behavior of a chat app today. So to provide a "first
| choice" experience, they will need to do so. So, how does
| P2P solve the metadata sponge problem?
| Arathorn wrote:
| 'Pinning your data on a server' basically means having a
| backup so that if you lose your phone or other logged in
| clients, you can still get at your account. Lots of
| people are happy to run without a cloud backup of their
| data - and in fact many orgs mandate that you _don 't_
| back up data from your clients onto a server somewhere,
| given it makes it easier to steal.
| factorialboy wrote:
| How is Libera vs. Discord vs. Matrix playing out in the open
| source community?
| kungito wrote:
| but Discord is closed source...
| crazysim wrote:
| And so is GitHub.
| account42 wrote:
| Sure, but Discord is more closed than GitHub - at least
| with GitHub the core part - ie the git repos - can be fully
| used with the standard open-source git client. If github
| decides they want to fuck you over, you push your repo
| somewhere else and go on with your life (issues etc will
| need more work). If Discord decides to fuck you over, all
| your content and participants are gone.
| normaler wrote:
| I think IRC vs. Matrix does not exist. There is a certain
| decision what is going to be the main communication source, but
| then you are going to bridge whatever you have on IRC to
| whatever you have on matrix.
| lucideer wrote:
| I think Libera is (and only intends to be) restricted to
| catering to the pre-existing Freenode community; their sights
| are not particularly set on expanding/competing with newer
| platforms any more than the Freenode community's were. They
| just cater to people who like & want to stick to IRC, for
| whatever variety of reasons. I don't see any "growth" (nor
| "shrinkage") happening here beyond migration of users from
| Freenode.
|
| Discord is not open-source, so I don't see how it's relevant;
| it's "communities" are primarily gamers & streamers. While
| there are some open-source communities based on Discord, the
| same goes for other closed-source platforms such as Slack &
| Telegram, and I'm sure the number of software development
| communities on Slack is (sadly) much larger than on Discord.
|
| Of actual open-source options: Gitter, Discourse, Rocket,
| Mattermost, etc. - Matrix would seem to be competing relatively
| well.
| exciteabletom wrote:
| > closed-source platforms such as Slack & Telegram
|
| I'm pretty sure Telegram is open-source (at least the client)
|
| https://github.com/telegramdesktop
| lucideer wrote:
| The server is closed-source, which is all that matters for
| centralised platforms.
|
| An open-source client would be relevant for something P2P
| like SSB/Manyverse*, but for all other tech the sourcecode
| of the server will be your primary concern.
|
| * And even with something like Manyverse, the sourcecode of
| things commonly used as "de facto servers", like SSB
| "pubs", ends up still being extremely relevant in practice
| just because of the UX of using the platform.
| M2Ys4U wrote:
| >Of actual open-source options: Gitter
|
| Gitter was bought by Element, it's effectively a Matrix
| client now.
| [deleted]
| Arathorn wrote:
| Many people use Libera & Matrix interchangeably (although the
| bridge hasn't been perfect so far, but we're working on
| improving it). You can get to #foo on libera as
| #foo:libera.chat on Matrix and it should Just Work(tm).
|
| Discord is... for folks who have got lost.
| Macha wrote:
| Libera retained like 90% of the freenode channels, with maybe
| 5% jumping ship to other IRC networks, mostly OFTC, and 5%
| jumping ship to Matrix, Discord and Slack, from the posts about
| channels leaving freenode. Libera is also bridged to Matrix, so
| Matrix users can participate in Libera channels, so there's
| also a decent amount of people using Matrix as a glorified
| bouncer.
|
| Very few new communities are setting up on IRC. My impression
| is that until the Freenode meltdown, Discord was most common,
| followed by Matrix, then Slack, but the freenode disaster seems
| to have benefited Matrix more than Discord or Slack.
|
| That's if you look at official channels, if you look at user
| counts in unofficial community groups as well, Discord has to
| be way in the lead. The Python community discord has about as
| many online users as Libera in its entirety, for example.
| sundarurfriend wrote:
| Others have mentioned Discord and Slack being closed source,
| but I'm interested in Zulip as an alternative. I really like
| the "branch off a topic at any time" that leads to proper
| distinct threads of conversation that get much easier to
| follow. And the interface so far seems pretty polished and
| seamlessly responsive, with rich keyboard shortcut interface
| too (which I'm yet to learn tbh). I hope it too continues to
| grow as a good FOSS option.
| egberts wrote:
| I wonder. it were to be a non-compliant of Matrix Foundation
| guideline if the federate feature can be turned off at the
| server-side, just to contain the metadata leakage. Just askin'.
| miloignis wrote:
| Yes, private federation is supported.
| pt_PT_guy wrote:
| Nice! Now please:
|
| 1) Kill the electron crap. Just look how awesome, fast,
| funcional, beautiful and feature-rich telegram is
|
| 2) Kill synapse. Is close to impossible to run a home server with
| all that python shit going on. Dendrite is the way I guess, but
| it is super resource-consuming to have a small home server (and
| slow)
|
| 3) Make it accessible and interesting for the casual john doe:
| FluffyChat is one possible route
| hestefisk wrote:
| Why is Synapse "impossible to run"? I agree it's not the most
| performance but for a small home server it's quite fast to set
| up. Dendrite is definitely going to be faster but it also has a
| lot more complexity (multiple databases, Kafka etc). Synapse is
| quite simple to understand and reason about.
| __david__ wrote:
| Re #2, it's a Debian package now which makes it super easy to
| get running on Debian systems (and probably Ubuntu). I suspect
| there are also docker images which can also make it very easy
| to get it up and running without dealing with python deps (I
| feel you as a non-python-dev, it's really hard to get python
| apps to run).
| cvwright wrote:
| If running an Ansible playbook [1] is "close to impossible" for
| you, then there are a few different companies who will host a
| server for you. Including the guys mentioned in the main
| article here.
|
| Sure, Synapse's performance isn't great, but still. Last summer
| I was able to run Synapse on a 1 vCPU, 1 GB RAM droplet from
| Digital Ocean. I had 100 copies of a bot running, each with
| their own room, constantly sending messages and replies to each
| other. With all 100 going at once, it was super slow. But with
| fewer bots, or with a lower chance of replying to a message, it
| worked pretty well. Not bad for like $10 / month.
|
| Also, if you want light and fast, check out Conduit, the
| homeserver written in Rust: https://conduit.rs/
|
| [1] https://github.com/spantaleev/matrix-docker-ansible-deploy
| Macha wrote:
| Conduit's homepage says:
|
| > Note: This project is work-in-progress. Do _not_ rely on it
| yet.
|
| Last I checked it also didn't support federation.
| karmanyaahm wrote:
| 2) Synapse works fine for me with 300MB memory to it and 400MB
| to the db, which can all be run (along with several other
| lighter applications) on the lowest tier Linode.
|
| 3) Yes
| vfclists wrote:
| > Synapse is a reference "homeserver" implementation of Matrix
| from the core development team at matrix.org, written in
| Python/Twisted. It is intended to showcase the concept of
| Matrix and let folks see the spec in the context of a codebase
| and let you run your own homeserver and generally help
| bootstrap the ecosystem.
|
| Is a _reference "homeserver" implementation_ supposed to go
| into production on a large scale?
| justshowpost wrote:
| That would be the sensible business decisions. Feed new horses,
| don't feed old horses. But they are hackers and have no idea of
| management.
|
| I'm really curious, if they manage to burn through 30 million
| and still keeping Element being crappy. At least thanks to
| Matrix being an open protocol anyone can develop a better
| alternative.
| dingo454 wrote:
| The Element foundation should use some of that sweet money to:
|
| 1) buy FluffyChat and some serious UI designers, because Element
| is probably one of the worst matrix clients in terms of UX.
|
| 2) fix decryption issues that happen randomly even by just using
| Element on the matrix.org server: https://github.com/vector-
| im/element-android/issues/1721 as it's a real show-stopper once
| you hit it
|
| 3) add support for multiple accounts and identities (too many
| requests to list on the issue tracker), since federation is
| great, but it's not always wanted.
|
| Disclaimer: I managed to convince a group of technical users to
| switch over to matrix. We stay for the principle, but not really
| for the experience so far. FluffyChat is the best client we tried
| on mobile. On desktop, I'm glad weechat-matrix and gomuks exist,
| because all the other clients "reek" to us. And even if you like
| the modern chat UIs, they're really not bug-free either.
|
| Overall many clients and some severs to choose from, but I did
| prefer irc just for the simple-no-BS-clients alone (the protocol
| has nothing to do with it).
| justshowpost wrote:
| It's funny, but I can not agree more.
|
| I never think a concrete issue will affect me. But over the
| last weeks I've been affected exactly by 2). Today I finally
| figured out that it had to do with the sender having turned on
| the setting "Never send encrypted messages to unverified
| sessions from this session". It's terribly implemented, because
| it gives the sender no feedback that they break any unverified
| receivers, and the unverified receivers only see an obscure
| error message. For more details, see my issue report:
| https://github.com/vector-im/element-web/issues/18255
|
| Also +1 on Element's terrible UI and UX. It was designed by
| programmers instead of UI designers, and you can feel that. I
| always find it weird when people talk about Element being a
| good client. It's literally the best of the worst. From the
| thousands of open issues (5000+ Web, 1000+ iOS and Android
| each!) you can clearly see they have an organization problem.
| Even most volunteer open source projects are more organized. I
| hope at least 30 million will be enough for them to hire some
| talented people and build a better management.
|
| I have the feeling most of them are hackers. Hacking and
| experimenting with new things like Matrix P2P is great, but
| it's not enough to have consistent output. You need to manage
| an organization, and I have the feeling they aren't capable of
| doing that. On that note, I'm surprised they managed (pun!) to
| get 30 million of investment.
| jryans wrote:
| > From the thousands of open issues (5000+ Web, 1000+ iOS and
| Android each!) you can clearly see they have an organization
| problem.
|
| As I said before down thread
| (https://news.ycombinator.com/item?id=27974054), there's
| nothing bad about thousands of issues, quite the reverse in
| fact. Many are feature requests that may or may not be
| implemented.
|
| A large number of open issues means the project is growing
| and many people are have ideas for new ways it can improve.
| foresto wrote:
| Furthermore, those thousands of open issues hint to me that
| a lot of people are actively contributing, and that the dev
| team takes responsibility for legitimate problems.
|
| Compare this to other projects with the illusion of quality
| because most bugs haven't been reported, or because their
| developers routinely dismiss and close reports of bugs that
| they don't feel like fixing, just to keep their bug tracker
| looking clean.
|
| Indeed, the contents of the Matrix/Element/Synapse issue
| trackers played a significant part in convincing me that
| the developers are making good decisions, and that
| investing my time and contacts in this network would also
| be a good decision. That was over a year ago, and I do not
| regret it. The project still looks very much on track to
| me.
| bennyp101 wrote:
| > because Element is probably one of the worst matrix clients
| in terms of UX
|
| I'm genuinely curious why? I use it on desktop and mobile, and
| I haven't found it lacking in anything? I've heard this said
| before, but I don't get it
| have_faith wrote:
| I want to like Element but I find strange UX issues or minor
| bugs every time I use it. It feels extremely beta from a
| polish perspective. I'm hopeful they can iterate and deliver
| something on par with the quality of mainstream chat apps
| they just need to decide that UX and look-and-feel is as
| important as delivering something conceptually novel from an
| engineering perspective.
| theshrike79 wrote:
| There aren't that many showstopper issues in the UX (except
| for wrangling bridges, but that's not really an Element
| thing, it's more of a Matrix thing).
|
| But everything is just a bit off. The text is a bit too
| spaced out for IRC users, the icons a bit too small for
| people coming from Slack and Discord. Colors are seemingly
| chosen at random by the coder and don't jive well together.
| The "These people have read the backlog this far"
| notification is just plain useless. It is death by a thousand
| cuts really. The small things stack up and make me not like
| using Element for Matrix.
|
| I do love Matrix, the underlying technology, in theory.
|
| IMO they just need to bite the bullet and make a truly user
| friendly mobile UI to replace Telegram, WhatsApp, FB
| Messenger etc. And a proper client for the major operating
| systems that's not too different from Discord and Slack.
| GekkePrutser wrote:
| For me the channel/room list is too messy with different
| parts which have their own scrolling zones. And each entry
| takes too much space leading to having to scroll all the
| time.
|
| On Quassel I can have 30 channels open without having to
| scroll. On element only 10 or so. That's way too few
| considering the number of bridges available.
|
| They have a high density xchat mode but it only affects the
| chat view, not the room list
| kinow wrote:
| Using it everyday too at $work, also used Slack and Gitter
| (and FreeNode/IRC FWIW). Quite happy with the current Element
| UI. They have slowly added features and fixed issues. I tried
| a beta some time ago with... topics? Rooms grouped in some
| sort of topic I think. It was really buggy, but I forgot
| about that I haven't seen it yet. So I assume they are doing
| some A/B testing, trying things slowly and seeing what works.
| vector_spaces wrote:
| Above all else, it's because core functionality is frequently
| broken and issues like this[1] languish for months and years
| without updates. When things don't work, it's rarely
| transparent to users whether this is due to a bug on
| Element's end (or on the server side), user error or
| misconfiguration, or operator misconfiguration.
|
| Further, there's virtually zero documentation for end users.
| There are no in-app explainers as to what E2EE is or why
| anyone should care, leaving the onus on operators to document
| and explain these things to non-technical users.
|
| [1] https://github.com/vector-im/element-ios/issues/3762
| gregoriol wrote:
| I do agree it is quite ok, it has all the basic features, but
| it feels "slow" and "beta" at some points.
|
| In addition to some decryption issues that made some of my
| friends hate Element (they could view messages on one device
| but not another one, and there was no clear action to fix
| this), one of the issues I think could be easily worked on is
| the settings: the current layout is way too complicated, too
| much scrolling, too many options, it doesn't feel clear at
| all. Also the stickers are really crappy: they are not useful
| for any serious chat (ie. work), and not useful for any fun
| chat (ie. friends).
| baby wrote:
| Personally I'm always confused about the accounts I which one
| I'm currently using (they have the same names). Also I can
| never understand when I verified someone.
| ttty2 wrote:
| I linked to desktop and most messages didn't decrypt. I
| didn't know what to do.. had to press request message again
| to decrypt. That's weird, and a pain.
|
| I remember some issues with images not decrypting.
| dingo454 wrote:
| For the average user the element UI is just confusing. This
| is the #1 complaint I got from all non-techies. They expect
| to just see a contact list, with each contact being a simple
| chat without the typing bar. Most of the other interactions
| are also too complex (like sending an image).
|
| You'd think this is a small complaint, but I've listed this
| as first as it's the biggest barrier to conversion. Ask the
| _same_ user to try FluffyChat, and no objections will be
| raised besides the expected "why another chat app".
|
| I'm not a fan of the Element UI myself, although I "get it"
| as it's targeting to something more group-oriented like
| slack. The problem is that Element is currently neither
| oriented to plain users, nor it's great to technical ones.
|
| If everything else had to stay the same, they should optimize
| for plain users on mobile and offer a better, more advanced
| desktop client instead.
| bennyp101 wrote:
| I guess it depends on what Element is trying to replace.
|
| If it's whatsapp etc then yeah, I agree, it is not going to
| work. But if it's Teams or Slack or something, then I don't
| see much difference. I don't think it is meant to be a
| whatsapp replacement, I think it is a generic chat tool
| that lets me integrate all my services in one place - kinda
| like Pidgen.
|
| As you say, maybe this cash injection cam let them get a
| mobile client that can work as a whatsapp replacement (as I
| guess that is what most people are moving from)
| dingo454 wrote:
| My suggestion, again: buy FluffyChat. Add important
| missing features, such as cross-signing. Make it the
| default client.
|
| You can keep element for advanced users.
|
| I'd argue it's still not a great client for tech users
| either, but I see an evolution in that direction more
| likely than the opposite.
| deepbluev7 wrote:
| What important features? FluffyChat had cross-signing for
| more than a year now. A lot of other features are
| unlikely to be added, since FluffyChat aims to be easy to
| use. FluffChat even supports E2EE fallback keys!
| wink wrote:
| I'm not trying to talk down your personal experience or have
| any skin in the game, but...
|
| We also have a group of technical users on Matrix, where we
| were formerly on IRC. Nobody complains about Element and most
| prefer it over the native clients they tried (but it doesn't
| rule out the possibility that everyone hates all native clients
| here).
|
| This is also just anecdata with a sample size of "handful of
| users", but from the other side.
|
| I personally would love to have a native Windows and Linux
| client I really like (preferably the same), but so far I've had
| no luck. The Android version of Element is perfect for my usage
| pattern though.
| chromatin wrote:
| I had never heard of FluffyChat and so visited its site.
| Appears to be a very attractive landing page. However, UX of
| the site leaves a lot to be desired.
|
| Their FAQ link in menu bar just links to their GitLab issues
| page, and AFAICTA nowhere on their site does it actually
| explain what FluffyChat is or which what network it operates,
| etc. (clearly from context I infer it is Matrix)
| the_duke wrote:
| It's just an alternative Matrix client built with Flutter. It
| works with any Matrix server.
| busymom0 wrote:
| I haven't tried it in a while but last time I tried about a
| year ago, the messaging was very slow - both to be sent as well
| as receive.
|
| Has this changed recently? I would like to give it another shot
| as I want to support the tech. Can someone with use experience
| please comment with their experience on the speed?
| foresto wrote:
| About a year ago was in many places just after the start of
| the pandemic, which brought a large influx of users to the
| default public server. It got overloaded, and slowed down. I
| experienced it, too.
|
| They have made several rounds of significant scaling
| improvements since then. It's almost never slow for me any
| more. (And even if it was, I could always just choose a
| server other than matrix.org, or run my own.)
| cvwright wrote:
| That was probably a problem with their main matrix.org
| homeserver, more than with the protocol or your particular
| client app. It was very slow for a while, until they worked
| out some scaling issues to handle the load.
|
| I'm on matrix.org pretty much every day now, and it's a lot
| better than it was. And when I use my own server to talk with
| other local users, I never have any latency issues.
| oever wrote:
| Fractal and NeoChat are two more Matrix clients. Fractal builds
| on the matrix-rust-sdk crate.
|
| https://invent.kde.org/network/neochat
| https://gitlab.gnome.org/GNOME/fractal
| deepbluev7 wrote:
| There is a lot more than 4 clients out there. For example I
| develop Nheko, which supports E2EE (including cross-signing)
| as well as 1:1 calls (those only on X11 though, because time
| and none seems to be interested in adding call support on
| other platforms). Then there are UX improvement forks like
| SchildiChat, clients for other platforms like SailifshOS,
| etc. Oh, and I almost forgot about Mirage.
| circularfoyers wrote:
| If you prefer FluffyChat's UI over Element's then I'm guessing
| you are after a 1:1 or group style chat (i.e. chat bubbles),
| similar to say Signal or Facebook Messenger. Element isn't
| catering to this audience from what I can tell, it has a UI
| that is similar to Slack or Discord, which is suited for large
| group chats. Just because you aren't using Element in this way
| doesn't mean that it has the "worst UX" of any other client.
|
| Your third point is a client side feature. If you meant that
| you want Element to have that feature, then yes I agree. But in
| saying that, it wouldn't surprise me that it's not high on the
| priority list when most clients (of any chat app) have this
| feature.
| dingo454 wrote:
| I totally get it, but I still disagree. Getting more users on
| the network should be a #1 priority. You don't want to keep
| another 10 chat programs, just because matrix is "not" a
| plain chat app. If the element foundation doesn't do this,
| who will?
|
| As a tech user, I still don't find the element UI great. It's
| clunky, quite slow and generally not intuitive, and wastes a
| lot of screen real-estate.
|
| I'm using slack and discord and I find both to be
| _significantly_ better for group work.
|
| But actively trying matrix on mobile, I still found the
| simplified FluffyChat UI much more usable on mobile anyway.
| Element is this sort of annoying middle ground which is not
| great for either.
|
| The third point is also important, because matrix is one of
| the few systems where you can have a private network for your
| work. You know, just like slack (again, the "group" they're
| apparently targeting?). Great feature. But if you, like me,
| would like to use matrix for both work and other
| communications, you're stuck.
|
| So in the end you run two clients. Element for work,
| fluffychat for everything else? And maybe shildychat for your
| other private group (I wish this was a joke).
| d110af5ccf wrote:
| Not to justify the missing feature in any way, but assuming
| you're on Android can't you modify the applicationId of the
| existing apk (there are tools on GitHub that will do this
| for you), resign the apk, and adb push it? Unlike desktop,
| mobile apps are so thoroughly sandboxed from one another
| that I don't think there's any way for that to cause
| problems. I guess updates might be cumbersome though.
| dingo454 wrote:
| You can. People have suggested the Element foundation to
| publish "red blue green yellow" versions of element with
| just a different app id for this.
|
| I wouldn't be against it (the _clear_ distinction between
| accounts is important!), but element is already a memory
| hog. You really don't want multiple instances running.
| [deleted]
| godelski wrote:
| This is why I've always been confused by HN's comparisons of
| Signal and Matrix. I see Signal as a replacement to
| texting/Messenger/WhatsApp (chats focused on one on one or
| small groups) but I see Matrix as a replacement to
| Slack/Discord (chats focused on organizations or large
| groups). I'm not sure why these aren't two different
| paradigms, but maybe someone sees something I don't. Telegram
| seems the most in between to me, though there are security
| reasons I see Signal/Matrix as being better.
| hellcow wrote:
| Matrix is a protocol. Element is a reference app built on
| top of that protocol, and Element looks like Slack/Discord.
|
| Other apps built on Matrix do not look like Slack, e.g.
| Fluffychat, which looks very similar to Signal.
| godelski wrote:
| But don't you still have the same server paradigm on
| Fluffychat as you do with Slack/Discord? That's very much
| not like Signal/WhatsApp.
| cvwright wrote:
| So much entitled whining in this discussion. With friends like
| open source users, who needs enemies?
|
| > Element is probably one of the worst matrix clients in terms
| of UX.
|
| If you ask nicely, I'm sure they will give you back all the
| money that you paid for it.
|
| But your point 2 is spot-on:
|
| > 2) fix decryption issues
|
| Part of the problem is that Matrix nukes your crypto keys every
| time you log out. This traces back to Element's heritage as a
| primarily web-based app, where there isn't really a great
| local, durable place to store your secrets. Not having local
| on-device storage is painful when the protocol encrypts
| messages to individual devices rather than to users.
|
| The fix is to set up encrypted key backup, aka secure server-
| side storage. Then all your keys from all your "devices"
| (including real devices and web sessions) get safely stored in
| encrypted form on the server, where you can always find them.
| You have to use a second passphrase to generate the new key-
| encryption key, so it's a little annoying. But the fix is
| pretty magical. Suddenly everything just works!
| [deleted]
| NationalPark wrote:
| I was trying to figure out why this comment rubs me the wrong
| way so much. I think it's how quickly it leaps to hostility
| and calling the user entitled, only because they shared their
| honest feedback. You say users aren't entitled to anything,
| which I guess is true, but what does that say about the value
| that this project purports to provide?
|
| I guess what I'm trying to say is I read this comment and my
| thought wasn't, "Oh, I guess those problems are handled", it
| was, "Oh, this projects advocates have a lot of contempt for
| their users."
| cvwright wrote:
| The GP comment was well beyond honest feedback. Honest
| feedback is like "I find such-and-such piece of the UI
| ugly", or "All of my friends get confused by the way it
| does XYZ".
|
| What I object to is the way our community viciously tears
| each other down. "This open source product is the worst
| thing ever! Kill it!" This crap is not productive. It's
| harmful.
|
| We're up against companies who want to monopolize markets,
| lock us in to proprietary platforms, and own our data
| forever. And then when somebody finally comes along and
| tries to do the right thing, we attack them for not being
| perfect. F that noise. So, yes, I have contempt for this
| attitude.
|
| (And no, I have no affiliation with the company being
| discussed in this article.)
| dingo454 wrote:
| Perhaps it is harsh, but element is being founded to
| improve the client, and I find several other open source
| clients to behave better than the official one.
|
| I call this honest criticism. My hope is to push matrix
| as an open protocol, to push matrix as a slack
| replacement and I genuinely wish the greatest success to
| the element foundation.
|
| I currently cannot say "element is awesome". Matrix as a
| protocol and ecosystem is awesome, but the client... I
| can't say that.
| cvwright wrote:
| Agree wholeheartedly here.
| Ambroisie wrote:
| The addition of threads and custom emoji, along with getting
| spaces out of beta, might finally mean the migration of my
| friends from Slack and Discord.
| ducktective wrote:
| I have mixed feelings about threads. In Slack, it is not
| obvious whether one should continue discussion in a thread or a
| new post since the former would hurt the visibility of chat.
|
| Is "spaces" similar to Discord channels? (#)
| Ambroisie wrote:
| Spaces are a way to group channels together according to a
| topic : they are similar to Discord servers and groups of
| channels. You can add sub-spaces to further divide your
| channels, which is better than Discord's flat hierarchy.
| ducktective wrote:
| So it's just grouping? Couldn't it be done merely in UI?
| Also how to divide each chatroom according to a topic e.g.
| #general, #dev, #off-topic (like #namespaces in discord)
| Arathorn wrote:
| It's way more than just grouping. It's like directories
| in a filesystem: you can share them; they have access
| control; they let you curate your rooms into hierarchies
| either for your own edification or for the benefit of the
| wider network. Think of it more like carving Matrix into
| a set of USENET-style namespaces - or having a global
| hierarchical filesystem for realtime data.
| feanaro wrote:
| It's more than just grouping. Spaces are rooms under the
| hood, just like rooms in which you usually chat in
| Matrix.
|
| What makes spaces what they are is the ability to specify
| some rooms as belonging to a space, in the sense of a
| collection. Since spaces are just rooms, this includes
| other spaces as well (which are then called subspaces).
| This allows building a tree which can be used for e.g.
| representing a company hierarchy. A single room can also
| be a part of more than one space.
|
| Spaces also have the concept of members. Soon support
| will land for the ability to restrict room joining to the
| members of the space a room belongs to. This will make it
| possible to use this as an on-boarding tool. For instance
| when an employee joins a company, they'd get invited to a
| company space, allowing them to see all rooms therein and
| join the ones they need.
|
| There's also a distinction between public and private
| spaces. Private spaces can be used purely as a tool for
| personal categorization. This still needs to be supported
| server-side so that you can have the same view on all
| your clients.
| f1refly wrote:
| This reads like they reinvented teamspeak, but this time
| its electron
| feanaro wrote:
| I'm not familiar enough with Teamspeak to comment, but
| there's nothing inherently Electron-specific about this.
| Other clients need to grow support for Spaces, of course.
| carlbordum wrote:
| Teamspeak 5 may be a Matrix client:
| https://news.ycombinator.com/item?id=25743874
| [deleted]
| crazysim wrote:
| Discord just got threads.
| dexterdog wrote:
| Are they as terrible as slack's implementation?
| Uke wrote:
| The biggest thing i'd like to have would be bots in fully
| encrypted chats and the android client to not break the
| encryption between clients all the time.
| kitkat_new wrote:
| Isn't this already possible (if a given bot supports it)?
|
| See t2bot.io which has some bots with encryption hosted:
| https://t2bot.io/docs/encrypted-integrations/
| rvz wrote:
| Congratulations to them on the fundraising.
|
| > However, there are no plans to use cryptocurrency incentives in
| Matrix or Element any time soon.
|
| Good.
|
| At least with this funding, I can clearly explicitly see they are
| NOT implementing a secret cryptocurrency coin to be listed on an
| exchange, but instead they are focused on improving the security
| and privacy features of Element and Matrix.
|
| Well done!
| brylie wrote:
| > instead they are focused on improving the security and
| privacy features
|
| Hopefully they also improve the UX and new user onboarding
| experience in order to gain wider adoption. I really want to
| promote Matrix for communities where I am involved but it lacks
| the product-orientation of Discord and Slack.
| rsa25519 wrote:
| > Hopefully they also improve the UX
|
| They're making great progress! There's still more work to do,
| but I've been very impressed by the improvements made by the
| Element team over the past year, ranging from many small
| details to large usability features like the UI for spaces as
| an easier way to organize communities
| jmakov wrote:
| Why would anybody use Matrix after reading
| https://www.hackea.org/notas/matrix.html ?
| trasz wrote:
| This article seems all about a particular implementation, not
| the protocol.
| Arathorn wrote:
| Perhaps because the vast majority of points in the article are
| obviously false or exaggerated out of context?
|
| Needless to say Matrix servers and clients don't send any data
| (private or otherwise) by default to central servers. The only
| central services we have are the identity lookup service (i.e.
| map phone number & email to a matrix ID), which is strictly
| opt-in and various anonymous stats reporting (which is also
| strictly opt-in).
| Kinrany wrote:
| The only section that doesn't end with "we suspect foul play
| but did not investigate" is a citation of [1], so might as well
| read that instead.
|
| [1]: https://github.com/libremonde-org/paper-research-privacy-
| mat...
| jeddy3 wrote:
| That article makes it seem like private servers unconditionally
| sends metadata to official servers (is this really the case,
| seems odd?)
|
| Other articles mentions sending metadata only to servers you
| have users from (which of course can be a problem, but at least
| is explainable).
| TroisM wrote:
| Matrix/Element is the most promising messaging platform from a
| privacy standpoint, but I wish that they didn't chose Electron
| for building the Linux client...
| Saris wrote:
| This doesn't seem to have any reasons to avoid matrix that I
| can see. The whole bridges section is strange since that's set
| up by each homeserver admin, and you can just.. not do that.
| remirk wrote:
| "Why would anyone use X after reading a critic blog post about
| it?"
| xj9 wrote:
| building matrix is really expensive i guess. i wish them luck,
| but so far i haven't been sold. probably wont be either.
| JohnWhigham wrote:
| Nothing is going to change unless we break free of this shit VC
| funny money cycle.
| zaik wrote:
| You might like XMPP then - IETF Internet standard, always had
| decentralization and e2e encryption. I still don't understand
| why so much energy was invested in building a seperate
| ecosystem. Matrix claims to be fundamentally different, but all
| their major selling points (dencentralization, e2ee, open
| protocol) were already there. And since the Matrix encryption
| protocol is incompatible with all the other ones there's
| currently no way to securely communicate with someone outside
| their network.
| tffgg wrote:
| It hasn't really been there:
|
| - encryption wasn't really there (and still is experimental)
|
| - decentralization does not exist to the degree that Matrix
| provides it
|
| And Matrix is fundamentally different. It works somewhat
| similar to git compared to XMPP being more like IRC, which
| results in a completely different form of decentralization.
| E2EE is different as well - even if both are based on the
| Signal Protocol: Matrix encrypts for groups of people instead
| of single devices
|
| I doubt Matrix would be where it is if they tried to bend
| XMPP
| Andrew_nenakhov wrote:
| Decentralization in XMPP exists to a much greater degree
| that in is in Matrix.
| Macha wrote:
| Practical decentralization, where you can talk to your
| friend that uses a different provider?
|
| Not just using the same client for Facebook and your
| corporate chat instance?
| zaik wrote:
| > Practical decentralization, where you can talk to your
| friend that uses a different provider?
|
| Yes. You can find some lists of servers participating in
| the federation here: https://xmpp.org/getting-started/
|
| It's just that XMPP providers are not required to
| participate in the federation. Sadly, large instances
| like WhatsApp choose not to.
| Andrew_nenakhov wrote:
| Practical decentralisation, as in thousands of servers
| connected to each other in one federation, working for 20
| years.
| zaik wrote:
| > encryption wasn't really there (and still is
| experimental)
|
| Clients could encrypt messages using OpenPGP and the more
| recent OMEMO seems pretty reliable to me (Conversations,
| Gajim).
| dathinab wrote:
| But XMPP failed (as a decentralized open protocol in the
| wider picture).
| olah_1 wrote:
| Maybe it failed in the consumer app space because it
| couldn't keep up with user experience expectations. But if
| that is the metric, then Matrix already failed too, right?
|
| One new server + consumer app combo could revive XMPP for
| consumers quite easily.
| tffgg wrote:
| So not keeping up to users expectations - no matter how
| much - makes a failure?
|
| I think your argumentation is flawed. If your
| server+consumer app combo can do that, do that
| olah_1 wrote:
| I was giving the person above me the benefit of the
| doubt. I assume that was their argument, not mine. But i
| entertained the idea regardless.
___________________________________________________________________
(page generated 2021-07-27 23:01 UTC)