Matrix, RFC4398, gRPC

  1. I've been monitoring Matrix project closely. One of the worst problems with Matrix is well, that's it's open source. So everything is messy and it takes lot of effort to figure out things, etc. One of the classic jokes is that you should choose a good home server, but I can't tell you which. Because there are no good recommendations (?). But now there's finally pikaviestin.fi (@ pikaviestin.fi). Matrix home server, run for Finnish users in Finland and administered by Finnish association and Administrators. This is nice, I really do like this kind of approach.

  2. Had interesting issues with Matrix. Root cause analysis is funny, there were some serious data loss, and people were confused why some essential bot messages were missing and so on. But after all the true root cause was the "usual type". One $ missing from one configuration file. That's it, nothing more serious than that. Yet lack of that caused the transaction identifiers (txid) to overlap in situations where there were more than one message per second, and some messages simply got lost, because the messages were sent with same id, and Matrix server simply ignored those messages as duplicates. Because the mistake was in configuration file, it was in place where it wasn't directly visible in logs, nor the issue was of course visible in source code. But after wondering for a while, I found it. A-ha, that's it, there it is. - Classic, happens to everyone every now and then. - But when talking about root cause, should the program check that essential configuration is right? Should it warn if system is misconfigured? Good questions. And why did someone fail (ahem, me) while setting up the config and leaving out the $ sign, that's probably copy paste issue or just quickly editing key API strings in vi with left hand. - Also this is great place in case misconfiguration is done by customer, that there's no problem, everything works exactly as designed, which is absolutely true! Some messages are lost, but due to system misconfiguration and result is unintended, but totally expected outcome.

  3. While writing one bot, found out that there are now so many new API features in Matrix, this requires constant new development even to maintain old code, because the old APIs I were using are now deprecated. Classic problem.

  4. Had a long discussion about embedding content from social media on website. Actually I can do that, I can embed content, but I don't want to embed their JavaScript & other junk tracking bloat. So I'll download my content, reformat it and then post it on my own server. Now content is embedded, without the gunk! This being said, my Twitter feed as RSS with links to posts can be found here (@ s.sami-lehtinen.net).

  5. Checked out RFC 4398 (@ datatracker.ietf.org) - Storing Certificates in the Domain Name System (DNS). Pretty old RFC, finally implemented by some providers. And as far as I know, not really used by any software so far. Yet there are many other kinds of DNS tricks used to provide similarish functionality. Like SSHFP (@ Wikipedia) and using PKA TXT (@ df7cb.de) records to publish OpenPGP (@Wikipedia) fingerprints.

  6. Usually I'm slightly annoyed by requests to use some exotic technologies. But now I got a case where they insisted using gRPC (@ grpc.io) and of course gRPC (@ Wikipedia). Yet, I found it to be highly joyful. Quick swift and easy integration. Much nicer and quicker to deal with that Amazon SQS which was used in one project. And naturally nice alternative to all the classic RESTful APIs. Sure, there's no lack of serialization / queue solutions out there. Yet again, it's pretty same if RabbitMQ, Apache Kafka is being used. It's just data, different wrapping and transport, doesn't matter that much. Bit different approach, logic and implementation, but the end result is exactly the same.

  7. Wow, OVH DNS management doesn't anymore warn that adding AAAA record with name which already got A record, is "duplicate record" and probable configuration mistake. - Progress.

2022-12-18