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

Congrats to the Matrix team (mostly Matthew/Arathorn?) for this! This is a really cool proof of concept for making a native mobile client for Linux. One question, though: my understanding was that some of the work needed to use megolm/olm correctly and securely was in matrix-js-sdk (unless I read the audit wrong). That said, how much work would need to be done to current Qt/GTK SDKs to replicate this (I assume it's mostly key management stuff), and how would the team keep this in sync with any changes made to the JS SDK in the future? Alternatively, am I misunderstanding something fundamental?

I've already backed Purism's Librem 5 campaign, and I think everyone else should too, if they care about a fully free handset. It can be found at https://puri.sm/shop/librem-5/ if you were looking for it.



At the moment about 60% of the code required to do e2e encryption is in the main SDK layer (as it has to hook into all of the Matrix API stuff, client UI/UX and local storage), and 40% in libolm. This isn’t great as it makes porting the app code between platforms more work than it could be and risks bugs - but we have already ported it to ios and android, and kitsune is working at porting to libqmatrixclient and penguin42 is porting it to glib for use in libpurple. In future we’ll try to push more of this down into crossplatform library on top of libolm (libolmmatrix?) which can then have a slightly hairy API to call back to the main SDK to do HTTP and storage operations etc - but for now we’re trying to get it out of beta in the current architecture before we then go and refactor it all.

So: in an practice a native Librem client would use libqmatrixclient or something similar, with the application layer E2E functionality handled by that library - but in future that could be factored out to simplify life for everyone.

Another approach could be to use a sidecar process to proxy the traffic and offload all the E2E stuff (which we need for a shim for simple clients anyway - even curl etc). But nobody has yet stepped up to build this, plus integrating with UI is a bit of a pain (local popup notifs + local web interfade for key management?). It would be a superfun project for someone wanting to play with E2E though!


Thanks for the response. Seems like there's a lot of work to be done on refactoring, but I can appreciate that E2E stuff is still in beta.

As for that last remark, perhaps it's a good GSoC proposal?




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

Search: