Matrix, ZigBee, Python, Big O, Signal, MNM


  1. Just when I posted about my wishes about Matrix message and key management improvements, this post got posted: Implementing support for message retention policies in Matrix (@ brendan.abolivier.bzh) and Message Retention Policy (@ GitHub). Great news! I just wish the clients would also get rid of the stale encryption keys, currently those old encryption keys just pile up and consume space and can be security issue in some cases. Let's see if there are any details in the post which are worth of commenting: Long article, all extreme basic stuff, what they did is just how I usually do database purge stuff. Yet using milliseconds is probably bit overkill. I usually use seconds. But if Matrix generally uses milliseconds everywhere, then it's well standard solution. - One comment, about now being able to delete the last event. How about inserting new event, event purge and deleting the user events. Then there would be one event, which just tells that there are no events. I use something like that, when it's mandatory to have some data, which doesn't practically have any value. This case is still wide open after several years. kw: matrix, m.room.retention. room_retention, data expiry and expiration

  2. More ZigBee (@ Wikipedia) home automation and sensor and home-assistant related work and coding. Not yet finished, lot's of things to take care of. Also did read lots of ZigBee security, and issues related to pairing, when the initial encryption keys aren't exchanged securely. As well as some devices send unencrypted data.

  3. SortedContainers for Python (@ grantjenks.com). I've been looking for something like this, yet with small datasets which aren't updated too often, you can just simply call the sorted. But at some stage, that's just a bad way of getting around it.

  4. Another really nice post about Big O notation explained as easily as possible (@ thatcomputerscientist.com). Nicely linked to the previous topic. As well as to the next topic, do you want to use linear, quadratic or exponential back-off?

  5. Interesting discussion about Signal (signalapp) failures. How they potentially DDoSed them selves by blindly retrying requests at high rate. There's nothing new about bulk heading, circuit breakers, exponential back-off (+ jitter) and so on. All very basic stuff. As well as handling operations atomically, so it's known if something is done or isn't done. Depending on expected service loads and protocol complexity and so on. I also like pattern where the server side can tell the client to retry after N seconds. Having this implemented in the client, allows time slotting clients into buckets. As example if normal update is 1 unit, and for some special reason there's huge update which is 20 times bigger, the servers can tell the clients to get the update bit later. This is especially important for services which poll often for small updates. Similarly depending on the request the clients can be prioritized in the buckets. All update requests with potentially old vulnerable version, could be allowed to download sooner, than the update requesters which already got version which doesn't have vulnerability, but there would still be some kind of update for those to be downloaded. Got X, update? A) Nope, all good. B) Here's your update. C) Busy, try again in 9332 seconds. - Thanks. Having that pattern allows adding smarts to the server side. Optionally, depending on the update server side, the C could also contain redirect to get the update from alternate source(s) and so on. All US download servers swamped, but EU servers unloaded or something similar.

  6. Nice blog post about: Matrix OLM / MEGOLM encryption protocol (@ jabberhead.tk) and of course the related FOSDEM 2019 talk 'Matrix in the French State'.

  7. MNM (@ mnmnotmail.org). First it looked good, but when they hit the secondary objectives, like providing specific features like forms, surveys, data driven charts and other stuff, I got immediately put off by it. There are reasons why systems use stacks of software. Each layer got it's own job, and could be replaced by something else. A single too large monolith is problematic. - Yet this doesn't mean that the SMTP / Email system wouldn't badly need a much better replacement. Current system is complex, insecure, unreliable, hard to manage and in general terms just very broken.

2022-03-27