[HN Gopher] Cross-signing and end-to-end encryption by default
___________________________________________________________________
Cross-signing and end-to-end encryption by default
Author : thanksforfish
Score : 274 points
Date : 2020-05-07 20:02 UTC (2 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| Arathorn wrote:
| See also https://news.ycombinator.com/item?id=23092269 and
| https://news.ycombinator.com/item?id=23088852 (these should be
| merged perhaps)?
| gramakri wrote:
| For those looking to selfhost synapse and riot, we (cloudron.io)
| recently made both these packages stable. If you need help in
| setting them up, happy to help here (even if not on cloudron)
| godelski wrote:
| On HN I'm always seeing a fight between Signal and Matrix. Can
| someone explain this to me? As far as I see it: Signal replaces
| SMS; Matrix replaces Slack/IRC. These seem like different
| products that work in different spaces.
| ryukafalz wrote:
| There's nothing about the Matrix protocol that makes it better
| for one or the other though; it's a pretty general messaging
| protocol. Riot looks more like Slack, yes, but there are other
| clients that look more like SMS apps, e.g.:
| https://dittochat.org/
| remir wrote:
| Damn, this looks good! Thanks for the link!
| godelski wrote:
| THANKS! This actually clears things up better than the other
| comments. Is there a list of these things somewhere so I can
| learn more?
| ryukafalz wrote:
| This is probably the best place to start:
| https://matrix.org/clients
|
| And of course more broadly, Matrix as a whole isn't even
| limited to only messaging apps, although that's where most
| of the focus has been thus far. There have been some fun
| demos/projects in the past though:
|
| - Synchronized presentation slides:
| https://github.com/Half-Shot/matrix-presents
|
| - MIDI over Matrix: https://github.com/McOmghall/midi-over-
| matrix
|
| - VR videoconferencing:
| https://matrix.org/docs/projects/other/matrix-vr-demo
| [deleted]
| MayeulC wrote:
| Well, https://matrix.org is a good place to start (but
| could use a face-lift for non-techies). There's a good list
| of clients, servers, SDKs, etc at
| https://matrix.org/docs/projects/try-matrix-now
|
| And of course, there is the Matrix spec itself, but I
| learned most of what I know idling in matrix channels
| (#matrix:matrix.org and #synapse:matrix.org) and hosting my
| own synapse instance.
| tptacek wrote:
| Among technologists, the two most divisive aspects of Signal
| are that it requires phone numbers, and that it isn't (and
| likely won't ever be) federated --- that is, you can't run your
| own Signal server and be accessible to people using ordinary
| Signal clients.
|
| Matrix doesn't use phone numbers, and is federated (that's what
| makes Matrix interesting), so it's naturally the "antidote"
| suggestion on threads when people bring up these aspects of
| Signal.
|
| The fact is that they're not really comparable projects; they
| have different audiences and different goals. People have an
| innate narrative bias that constant hunts for horse races to
| spectate, and so you'll see a lot of "Signal vs. Matrix"
| arguments, but it's an artifact, not anything substantive.
| CameronNemo wrote:
| >The fact is that they're not really comparable projects;
| they have different audiences and different goals.
|
| Agree on the second part, but two messaging solutions can and
| should be compared. 1-to-1 (text/voice/video) messaging is
| entirely possible with both Signal and Matrix, and evaluating
| that narrow use case is a reasonable way to compare the two.
| tptacek wrote:
| Lots of technologists believe that everyone should use IRC,
| or some next-gen IRC-alike, to communicate. Anything you
| can do with a specialized messaging app you can do with a
| messaging relay network. But, of course, specialized
| messaging apps outstrip messaging relay networks by orders
| of magnitude; IRC itself has usage that is a rounding error
| of WhatsApp's. Most people do not perceive any value from
| being part of a federated relay network; the audiences are
| not, in fact, the same.
| [deleted]
| oehtXRwMkIs wrote:
| I see Matrix as a sort of generalization of Signal. It's
| federated and decentralized, and they literally had to scale up
| the E2E system that Signal came up with. I use it for every
| form of digital communication (bridges are nice) including
| 1-to-1 but I think most would use it for group chats or
| organizations.
| hutzlibu wrote:
| But maybe people don't want to use different software for the
| same purpose: sending text to other people. No matter they are
| on a PC or smartphone. That's what botters me with Signal.
| Bound to a phone (number).
|
| But Signal just works and is fast (though not as fast as
| WhatsApp)
|
| Matrix in the default login also works, but when you choose the
| default open Matrix Server ... it is slow.
|
| So I also will continue to use .. not only 2 but 6 different
| text sending applications. But in the future I would love to
| just use the Matrix protocol and one software.
| godelski wrote:
| I guess the difference I see is that texting I find useful
| for one on one conversation, or a small group. Slack I find
| good for big groups. I actually like to have two different
| apps for these because it lets me better compartmentalize my
| socialization, especially since the latter tends to be
| associated with work (I like to compartmentalize work from my
| social life).
| some_furry wrote:
| Yay! This is the right move for their users.
|
| There's still a ton of work left to do, but I'm thankful for all
| the hard work that went into making this possible.
| ex3ndr wrote:
| How they made scalable webrtc end-to-end encrypted? I guess it is
| not scalable (~5 members max).
| Arathorn wrote:
| Multi-way video conferencing in Matrix isn't e2ee yet; the
| e2ee-by-default here refers to private group chats, DMs, and
| 1:1 video/voip calls.
|
| Once Jitsi lands their E2EE support (hopefully using Matrix's
| E2EE for key management, c.f.
| https://news.ycombinator.com/item?id=22855407) then we'll get
| E2EE video conferencing too.
|
| Until then, Matrix (but not Riot) also supports E2EE video
| conferencing via full mesh webrtc, but as you say, it scales to
| relatively few users.
| qertoip wrote:
| Both are asynchronous messengers.
|
| Signal: + protects metadata + protects the content (e2e
| encryption) - is not anonymous - is not resilient against
| regulations
|
| Matrix: - does not protect metadata + protects the content (e2e
| encryption) + is anonymous + is maybe, potentially resilient
| against regulations (federated, not centralized architecture)
| Arathorn wrote:
| You could argue that Matrix does protect metadata if you run
| your own server - and in extremis, one way of running your own
| server and protect metadata is to go P2P and embed it into your
| client (which is one thing we're currently working on).
|
| That said, there are some other pretty big differences between
| Matrix & Signal; the biggest one is probably that Matrix is an
| open standard and open network, encouraging 3rd party clients,
| servers, bridges, bots etc - optimising both for
| freedom/liberty as well as encryption. Signal optimises for
| privacy at all costs and doesn't allow 3rd party clients or
| services. See https://matrix.org/blog/2020/01/02/on-privacy-
| versus-freedom for more.
| tptacek wrote:
| That's not really a reasonable argument. Signal makes a
| profound UX tradeoff to protect metadata by not requiring
| servers to store it in the first place: it drafts off
| people's phone contact lists, and thus everyone who uses it
| needs to be identified by a phone number.
|
| Matrix doesn't have any special way of avoiding that
| tradeoff. It just takes the other end of the trade: Matrix
| servers are exposed to valuable metadata, so that people can
| use whatever identifier they want.
|
| And, of course, the flip side of Matrix's "freedom and
| liberty" federalized design is that it is May 7, 2020, and
| the project is just now announcing E2E by default for private
| conversations. This is exactly why, years ago, Moxie
| Marlinspike wrote his post arguing about the downsides of
| federalization. It sure looks like his predictions were borne
| out!
|
| I think both of these projects are valid and important, and
| that they have different goals and audiences, and we do
| people a disservice when we pretend like they're in any kind
| of serious competition. Matrix is what you'd replace an IRC
| server with. Signal is what you'd tell an immigration lawyer
| to use for messaging.
| fiter wrote:
| I believe you consider phone numbers pseudo-anonymous
| identifiers, which I believe Matrix names also qualify as.
|
| Is there any technical reason why Matrix servers would have
| to store contact lists?
|
| Both Signal and Matrix would have store message metadata to
| deliver it.
|
| I searched for what the significant difference is, but
| could not come up with a good document to read.
| badrabbit wrote:
| Phone numbers are the most identifying piece of
| information. They are precise identifiers not pseudo-
| anonymous. A non-burner phone can easily be converted to
| a complete background check on the person for under $50
| ,for a higher price it can be converted to current
| realtime physical address.
| tptacek wrote:
| Signal's servers store no contact lists at all. It's not
| that phone numbers are some especially good anonymizing
| identifier; obviously, they are if anything the opposite.
| It's that everyone who uses Signal already has a _local_
| contact list keyed on phone numbers, which Signal 's
| client applications can access, which means the server
| doesn't have to know about contact lists in the first
| place.
| chrisweekly wrote:
| Thank you for this illuminating comment; it was helpful and
| imho exemplary.
| nimbius wrote:
| Signal has publicly threatened to shutter their US operations
| if EARN IT passes, so id say its relatively resilient.
| https://www.wired.com/story/signal-earn-it-ransomware-securi...
|
| regardless, the e2e encryption debate seems largely settled by
| the key players at this point. I think any legislation that
| makes its way through is likely to see brinkmanship again.
| Theres no reason these services cant use darknets. At the risk
| of sounding like a cryptobro, theres also no reason they have
| to use a server at all with blockchain.
| KingMachiavelli wrote:
| Having to leave a country is pretty much the opposite of
| 'resilient' in this context. They have to leave because it is
| a centrialized system and can be regulated like any other
| entitiy.
|
| Matrix is federated and individual servers can be run by
| volunteers/individuals for whom EARN IT would not apply.
| sm4rk0 wrote:
| Perfect timing: https://news.ycombinator.com/item?id=23102430
| Congratulations!
| jason0597 wrote:
| Pretty sure the person posting the Matrix page knew this
| Aaronn wrote:
| Actually this was all released a couple of days ago, just
| took a bit of time for them to write the blog post.
| rattray wrote:
| Folks who have tried Matrix/Riot and Slack - how does the product
| quality compare?
|
| Slack has many issues (little bugs, latency, notification issues,
| the shitshow markdown editor) but overall delivers a smooth
| product experience IME. When you self-host Matrix, do you
| typically get great perf without much effort? Is the product
| experience of the Riot client smooth and complete?
| rpm91 wrote:
| For the client experience, it's not even close: Slack's product
| experience is _far_ superior. I love the idea of Riot as a
| decentralized e2ee group chat client, but the implementation is
| so buggy and far from being production-ready that any attempt
| to use it seriously is an exercise in frustration. In
| comparison, Slack is mildly annoying at worst, and usually just
| works.
|
| If it were one or two little things, I'd file some bugs or even
| try to fix the issues myself in the Android app, but my
| experience has been that I have at least one experience-
| breaking bug or UX issue at least every other time I interact
| with the client. _Especially_ if you have encryption enabled.
| f38zf5vdt wrote:
| I use it. It's extremely easy to setup your own server and I
| got mine running in about 30 minutes following their
| instructions. Aside from issues around key exchange in earlier
| versions, it's been great and on par with Discord or Slack, and
| with similar reliability.
|
| I've been told the apps (Android/iOS) aren't as good as the
| Desktop version by coworkers.
| Arathorn wrote:
| Interesting - Riot is actually four entirely different
| codebases: Riot Web/Desktop (JS/TS/React), Riot iOS
| (ObjC/Swift), RiotX Android (Kotlin) and Riot Android
| (obsolete, Java).
|
| Riot iOS has been a bit under resourced over the last few
| years, but other than some jank it's a decent native app,
| albeit trailing behind Desktop a bit. RiotX meanwhile is of
| very similar quality to Desktop, albeit beta (but exiting
| next month, hopefully). Finally, Riot Android is abandoned
| now and we'll replace it with RiotX when RiotX is ready. Many
| folks' bad impression of Riot on mobile is due to Riot
| Android having been abandoned in favour of RiotX or the last
| year - such is the cost of a rewrite :/
| Arathorn wrote:
| Historically, Riot's UI hasn't been as smooth as Slack's - for
| many years we didn't have any professional UX/UI designers
| contributing to the project, and we built up a lot design debt
| along the way.
|
| Over the last year or so we've been progressively working
| through fixing it, and as of Monday we now have three(!)
| professional designers working full time on the problem. Having
| turned on E2EE by default, our next big project and single
| biggest priority is First Time User Experience - making sure
| that the app is at least as smooth as Slack and Discord,
| particularly on first impressions.
| https://blog.riot.im/e2e-encryption-by-default-cross-signing...
| has more details - and the sections before it show some of the
| UI/UX work which has been landing in the last few months.
| godelski wrote:
| I just played around with Riot for the first time. Can you
| directly reply to a comment in a chat room like you can in
| Slack (like the sub chat thing, I'm not sure what to call
| it)? I actually find this an extremely useful feature that
| allows rooms to to be uncluttered with side conversations
| (which as room sizes grow, this becomes a HUGE benefit). I
| may be missing this or I can't do it in a room of only me?
| j-james wrote:
| No, it looks like threads aren't (yet) supported in either
| Riot or the Matrix spec.
|
| https://github.com/matrix-org/synapse/issues/2329
|
| https://github.com/vector-im/riot-web/issues/2349
| ShamelessC wrote:
| I believe those are threads and while I have no opinion on
| the subject because I don't really use slack anymore, I
| remember them being pretty controversial here.
| Arathorn wrote:
| We have 'replies' (which lets you post a message into the
| main timeline which refers to an existing message in the
| timeline), but we don't yet have 'threads' (which lets you
| branch the conversation into a sidebar).
|
| The protocol actually has support for label-based threading
| (i.e. "hide all messages tagged #gif" or "only show
| messages/conversations in this room tagged #work") already,
| as per https://github.com/matrix-org/matrix-
| doc/blob/matthew/msc232.... But we haven't had a chance to
| hook this up into Riot yet, thanks to all the work spent on
| E2EE by default.
|
| Proper threads will come in time however.
| godelski wrote:
| Thanks for the reply! Yes, threads. That's what I'm
| thinking of. I find these super useful. I know some
| people don't like them, but they can just not use them if
| that's their preferred style. I would really just like
| threading a comment rather than having to label
| everything. I'll be honest, I'll just get lazy and not
| label. I doubt I'm the only one too, or in the minority.
|
| > Proper threads will come in time however.
|
| Awesome, this was really the only thing that makes me
| hesitant to switch. I can stand an ugly UI if I can get
| good conversational flow.
| x3haloed wrote:
| In my experience, Matrix and Riot are great. I love the
| protocol and concepts around it, and Riot was much higher
| quality than I expected it would be. Since trying it out for a
| while a few months ago, I have since abandoned it, however,
| because operating my own Synapse server was just too much work.
|
| Specific pain points were:
|
| - setting up SSL - getting Let's Encrypt certs onto a server
| without a web server was a pain, and keeping them up to date
| was even worse. I would love to see ACMEv2 support integrated
| into Synapse for painless SSL setup.
|
| - TURN server - if you want to use voice chat, you need to set
| up a separate TURN server, which has its own set of challenges.
| Again, I would love to see a solution integrated into Synapse.
|
| - Video chat - Even with a TURN server in place, video chat
| requires a separate plugin to work. Jitsi is recommended, I
| believe. Yet again, I want this integrated into Synapse and
| Riot.
|
| - Federation - Federation is part of what makes the Matrix
| protocol so great, but it was a huge pain to configure in
| Synapse. I spent hours to get it working, and it still had
| quirks about matrix.mydomain.tld vs mydomain.tld. I would like
| to see this simplified.
|
| Probably the thing I was happiest about is that a ton of
| administrative settings are easy to work with in the Riot web
| client.
|
| Keep it up, guys! I hope Matrix takes over the world, and I
| hope to come back some day.
| lifty wrote:
| Synapse is a beast. I am looking forward to a more compact
| server to become viable. Matrix is working on Dendrite
| (https://github.com/matrix-org/dendrite) and there is Conduit
| (https://conduit.rs) as well.
| Arathorn wrote:
| Dendrite is rapidly approaching the point where it could be
| considered beta rather than alpha. However, it doesn't have
| any of the richness of Synapse yet, and it'll be a while
| before it can be used as a Synapse replacement. Meanwhile,
| Synapse keeps shrinking and is getting a _lot_ of
| performance love - so personally I 'd give keep giving
| Synapse a go for now. It's a smaller cuter beast these days
| :)
| drdaeman wrote:
| I've just tried it again a week ago (last time was ~2
| years ago).
|
| While there's definitely lots of improvement, it's still
| painfully slow and eats lots (like, 40% of 1 core) of CPU
| time. Took me a two attempts and a couple minutes (!) to
| join a relatively crowded room at #synapse:matrix.org on
| a freshly installed Synapse. I get it that there are over
| 12k people in there, but I haven't seen any other
| platforms having similar issues.
|
| And this just doesn't feel right, design-wise. It could
| take a long while loading user pictures, presence states,
| ancient chat history and extra fluff. But seeing the most
| recent messages* and having an impression of joining the
| room should be nearly instantaneous.
|
| Still a huge improvement over what it used to be. I
| remember waiting for no less than 10 minutes in a similar
| scenario, and it used to consume nearly 100% of CPU
| available.
|
| *) For some reason, previews never worked for me. Despite
| being able to join, when just trying to peek I always get
| either the never-ending "loading" spinner or "this room
| can't be previewed" message.
| Arathorn wrote:
| So the problem is that if you join a room with lots of
| different servers, your server has to go handshake with
| each one to check its signing key in order to verify the
| events the server has emitted. #synapse:matrix.org is
| almost by definition one of the worst rooms for this,
| given most people in there are joining from their own
| server.
|
| Solving this is an interesting challenge - one option
| could be to opportunistically trust events. Another could
| be to opportunistically fetch server signing keys. A
| better one would be to implement MSC1228, which switches
| all our IDs for public keys, which should make
| verification much easier and less burdensome.
|
| In terms of peeking rooms over federation - sadly this
| still isn't implemented yet. https://github.com/matrix-
| org/matrix-doc/blob/matthew/msc244... is the proposal to
| fix that however.
| drdaeman wrote:
| Ah, so the server that hosts the room is not fully
| authoritative and messages from participants are all
| signed by their respective server owners?
|
| This makes sense. Thank you for explaining!
| Arathorn wrote:
| Yup, precisely. In Matrix, rooms are not hosted by any
| single server - instead, they're replicated over all
| participating servers, much like git. But you need to
| check the provenance of the original messages to stop
| spoofing, hence needing to go check signatures the first
| time you interact with messages from a given server. Once
| you're joined, things should be fast however.
| [deleted]
| x3haloed wrote:
| Thanks for sharing! I'll give them a look. As an aside,
| another protocol I would really love to see a simple
| implementation for is LDAP. Through my research, it seems
| that every LDAP controller server out there is just
| monstrous. I would love a cross-platform, turn-key solution
| that provides just the basics: user management,
| authentication, and replication. There has to be a better
| way to manage identities across internal networks.
| MayeulC wrote:
| Oh, and there is construct as well, not to be forgotten
| (C++ homeserver). It federates, and works with most
| clients, though it lacks a few features (link previews, a
| couple others). I've interacted with a few of its users
| over federation, though I haven't tried it myself.
|
| Compared to synapse's resource use, it seems completely
| anemic (I've read that the lead developer makes it run on a
| 800 MHz pentium, though that could have been a joke).
|
| https://github.com/matrix-construct/construct
|
| https://matrix.org/docs/projects/server/construct
| [deleted]
| Arathorn wrote:
| Sorry to hear that :( There are two things we've tried to do
| to fix it:
|
| 1) Running Synapse really isn't that hard if you follow best
| practices... but I think we've done a bad job of
| communicating those best practices; instead Synapse's
| INSTALL.md lays out tonnes of different options and expects
| folks to pick their poison. I tried to fix this a few weeks
| ago by sitting down and recorded a dorky video to try to
| steer folks through best practices for setting up Synapse +
| certbot + Jitsi: https://matrix.org/blog/2020/04/06/running-
| your-own-secure-c.... (I need to extend it to coturn, but
| again, coturn should be straightforward. I don't think we
| should be baking TURN into Synapse though!). You could also
| shove everything in Docker and forget about it.
|
| 2) Peer-to-peer Matrix will let you get up and running
| without even needing a server. This is progressing alarmingly
| rapidly at the moment - https://p2p.riot.im is a version of
| Riot/Web which installs a homeserver (Dendrite) in your
| browser as a WASM service worker. It's alpha, but it mostly
| works pretty well, and is hopefully the shape of things to
| come - to let people have autonomy over their comms without
| ever needing to understand SSL, TURN, etc.
| abnercoimbre wrote:
| 3) I also think we should promote Modular's service [0]. I
| used to operate my own Synapse instance but didn't want the
| maintenance work so I'm paying them. Very happy with it so
| far!
|
| [0] https://modular.im
| x3haloed wrote:
| Thanks for the reply! I understand not wanting to re-
| implement entire servers within Synapse. Maybe an installer
| util would go a long way towards making setup more
| manageable. A step to automatically download and configure
| coturn, for example, could be very helpful.
|
| I also understand that making things too turn-key (no pun
| intended) can be extremely difficult to do well and can
| also impede advanced configuration. But there is somewhat
| of an incongruity between the Matrix philosophy of keeping
| private servers vs. the expertise required to actually get
| that done.
|
| P2P sounds really cool! I'll try it out.
| [deleted]
| xamlhacker wrote:
| For the SSL part , I have been looking at Caddy as it seems
| to have pretty simple reverse proxy over SSL setup.
| rakoo wrote:
| Been self-hosting for a few weeks, and it's working exactly as
| expected. I find Slack to be slightly more reactive but not by
| much (I'm comparing a company-wide workspace of ~10 actually
| active people, vs a little channel of ~5 actually active
| people).
|
| Personally though I can't stand the conversation view in Riot,
| the spacing between the nickname, the avatar and the text feels
| just wrong and I can't see in a glance who is talking and says
| what (yes, even with the compact view). It's minor, but it's
| the one I have under my eyes at all times so it's there. For
| now I'm using another snappier client (https://neo.pixie.town/)
| because of this issue.
|
| Apart from this client-specific issue that doesn't say anything
| about the protocol itself, everything is fine.
|
| The one thing I'm waiting for is rooms where participants are
| hidden, so that you actually get closer to a pubsub system. I
| have some ideas I want to try and play with, but this is needed
| if you want to keep some privacy
| Arathorn wrote:
| > Personally though I can't stand the conversation view in
| Riot, the spacing between the nickname, the avatar and the
| text feels just wrong
|
| Does https://github.com/matrix-org/matrix-react-sdk/pull/4531
| look any better? O:-)
|
| > The one thing I'm waiting for is rooms where participants
| are hidden, so that you actually get closer to a pubsub
| system.
|
| This is surprisingly hard (if you don't know what users are
| in a room, how do you know what servers to send messages to?)
| but we can provide at least a cosmetic solution (have the
| server filter out members below a given power level when
| relaying to the client). https://github.com/vector-im/riot-
| web/issues/6417 is the bug to upvote :)
| rakoo wrote:
| > Does https://github.com/matrix-org/matrix-react-
| sdk/pull/4531 look any better? O:-)
|
| Hey that's actually kinda sexy ! I'm not looking
| specifically for IRC-style <timestamp/nick/message>, I do
| like it when it takes a bit more space for the user, but I
| find this rendering nice to the eyes.
|
| In the quote though, why is the user cast away on the right
| ? Would be more consistent to put it right next to the
| timestamp of the quoted text
|
| Also, the nick is chopped at the end without any indicator
| that it is (like a [...] at the end or something)
|
| All nitpicking, I know, I'll try this as soon as it lands
| because I already like it :)
|
| > https://github.com/vector-im/riot-web/issues/6417 is the
| bug to upvote :)
|
| I'm following it closely ! I can't wait to experiment
| around that, Matrix.org can be and needs to be much more
| than just a messaging protocol, there's everything needed
| to get rid of centralized silos of (micro-)blogging,
| status- or photo-based social networks, ...
|
| BTW thank you for doing this and thank you for leading it
| all the way to it is today and to where it's gonna be
| tomorrow, there's a reason protocols fail or succeed and
| it's often not in the technical intricacies but definitely
| in the leadership that spearheads its spread. Matrix seems
| to be the one that has the biggest momentum for now :)
| Arathorn wrote:
| > In the quote though, why is the user cast away on the
| right ?
|
| > Also, the nick is chopped at the end without any
| indicator that it is (like a [...] at the end or
| something)
|
| These were just bugs in the first cut. I'll spin up a dev
| client and grab a screenshot of the final version (i
| think dev finished on it today!)
|
| > BTW thank you for doing this
|
| np. I just hope we realise the full potential of the
| project :) For what it's worth, I hope that Matrix can be
| to Slack/Discord what Linux was to Solaris/AIX. So, we
| just need to not screw up...
| bhauer wrote:
| > _Doeshttps://github.com/matrix-org/matrix-react-
| sdk/pull/4531 look any better? O:-)_
|
| Substantially better than the default Riot layout. I hope
| this gets merged and I get to switch to this soon.
|
| That said, I'd still like a _more_ compact version of the
| same that further reduces the spacing /padding to make more
| information fit on a single screen.
| godelski wrote:
| Not the parent, but I do think that looks better. I do
| think their client looks better than that, though. I'm a
| big fan of dark themes.
| badrabbit wrote:
| Usable for technical people,but as they note at the end of the
| blog post, they have ways to go with respect to first time user
| experience.
|
| I tried getting a team of tech savvy people to use it for
| backup encrypted comms, the UX was horrid, the key verification
| just didn't work at the time. Hopefully this is fixed.
|
| I am hoping a commercial product comes out of this,so they have
| proper QA and UAT. The FOSS approach of filing an issue/bug
| when basic things fail does not translate well to a generic
| audience. The protocol and Riot are actually decent,but I think
| the UX has yet to catch up with the rich feature set.
|
| Both Signal and Slack just worked. Slack has great UX, Signal
| is mediocre but from a security perspective, many things are
| non-obvious which to me feels like a dark pattern of
| insecurity,Riot maybe more painful but fails in more obvious
| ways.
| y7 wrote:
| Is there a Python SDK that supports encryption well yet? I have a
| simple command line script to send a message to a Matrix room.
| About three months ago I tried to add encryption, but apparently
| the old matrix-python-sdk is deprecated in favor of matrix-nio,
| but encryption support in the latter was very marginal still.
| 0x006A wrote:
| you should be able to get encryption working with nio now. nio-
| template is a good start https://github.com/anoadragon453/nio-
| template
| Arathorn wrote:
| matrix-nio's encryption is very robust now, but by far the
| easiest way to hook up a simple commandline script is to pipe
| it through pantalaimon (https://github.com/matrix-
| org/pantalaimon) - which acts as a daemon to offload E2EE from
| your script, using matrix-nio under the hood.
| fack wrote:
| w00t! my computer club hosts a homeserver and it's been running
| so smoothly since we upgraded.
| im_dario wrote:
| How is memory consumption going? I'm waiting for improvement in
| this area or a stable release of Dendrite [0] (hoping it has a
| reasonable memory usage).
|
| 0: https://github.com/matrix-org/dendrite
___________________________________________________________________
(page generated 2020-05-07 23:00 UTC)