• 0 Posts
  • 36 Comments
Joined 3 months ago
cake
Cake day: February 6th, 2025

help-circle

  • Standards as in parts of the spec, as you said in the original reply:

    the new MatrixRTC spec

    Which is a fork of the WebRTC protocol and another “standard” on top of the REST HTTP protocol.

    I should have been more specific with my language, it is federated, but specifically messages (events) are a distributed DAG, and I find the Matrix protocol overly generic for a replacement for something specific like Discord.

    The end goal of Matrix is to be a ubiquitous messaging layer for synchronising arbitrary data between sets of people, devices and services


  • Matrix has moved very very slowly and I’m concerned it’ll have the same fate as XMPP, where it’s a bunch of very complicated standards, with maybe one compliant implementation that nobody wants to work on.

    I also don’t think it’s a particularly good protocol design for a Discord replacement, it’s not federated it’s a distributed message protocol, which is an order of magnitude more complicated and intensive than potential alternatives.

    That said, many non-perfect things have achieved widespread success, so I’m at least hopeful that Matrix/Element are able to catch on in a wider capacity.


  • As someone who runs a Mumble server (and has for over a decade) – it’s really not a replacement for the user experience that is Discord.

    People want a unified UI, the ability to create communities with some amount of customization, embedded/live content, plus voice and video so they can chill and play games together. Mumble is just voice, and while it’s a very good implementation of that, it’s not even in the same user space as Discord.


  • I think it’s “the algorithm”, people basically just want to be force-fed “content” – look how successful TikTok is, largely because it has an algorithm that very quickly narrows down user habits and provides endless distraction.

    Mastodon and fediverse alternatives by comparison have very simple feeds and ways to surface content, it simply doesn’t “hook” people the same way, and that’s competition.

    On one hand we should probably be doing away with “the algorithm” for reasons not enumerated here for brevity, but on the other hand maybe the fediverse should build something to accommodate this demand, otherwise the non-fedi sites will.



  • Ironically the shortening of cert lengths has pushed me to automated systems and away from the traditional paid trust providers.
    I used to roll a 1-year cert for my CDN, and manually buy renewals and go through the process of signing and uploading the new ones, it wasn’t particularly onerous, but then they moved to I think either 3 or 6 months max signing, which was the point where I just automated it with Let’s Encrypt.

    I’m in general not a fan of how we do root of trust on the web, I much prefer had DANE caught on, where I can pin a cert at the DNS level that is secured with DNSSEC and is trusted through IANA and the root zone.










  • I don’t think it’s hyperbole to say a significant percentage of Git activity happens on GitHub (and other “foundries”) – which are themselves a far cry from efficient.

    My ultimate takeaway on the topic is that we’re stuck with Git’s very counterintuitive porcelain, and only satisfactory plumbing, regardless of performance/efficiency; but if Mercurial had won out, we’d still have its better interface (and IMO workflow), and any performance problems could’ve been addressed by a rewrite in C (or the Rust one that is so very slowly happening).


  • Same with mice, Logitech uses a combination of under-designed (denounce and chatter can be fixed by using both the NO and NC terminals to perform latching in firmware) circuitry, out-of-spec voltages, and cheap wrongly spec’d microswitches, which results in their mice suffering from double click and other similar issues after a year or so of usage.

    You can put switches that are closer to spec and will last many more years, but really they should be using 5V and both momentary terminals.