Coincidentally, my most-used project is on Codeberg, & is a filter list (such as uBlock Origin) for hiding a lot Microsoft GitHub’s social features, upsells, Copilot pushes, & so on to try to make it tolerable until more projects migrate away <https://codeberg.org/toastal/github-less-social>.
How are you framing this? It’s an Electron app so it exists but doesn’t integrate or perform great. Last I recall you still were required to provide a SIM to sign up & you needed an iOS or Android primary device to even use the desktop client. Can you use a standalone, fast desktop application like you can these other protocols? I would say no, so “support” has shades of gray to it.
This is how I got kicked off LINE… they had a Chromium app that I could use tethered to an app, they disabled support for LINE Lite (which had light/dark theme, E2EE, texting, voice/video calls, debatable trackers (Firebase), even stickers & sending a location @ 8MiB instead of 200MiB+ of the “heavy app”), I refused to “upgrade” as it was a downgrade to me, & since I was no longer registered with a “primary” device, I was booted from the network. I don’t think I want these mobile-duopoly-required apps to be my primary means of communication with folks—especially now that my primary phone isn’t Apple or Google (luckily Open Whisper lets WhisperFish exist).
Not GP but I've also had issues with the Signal Desktop app (installed from the Arch repos).
Its overall a little sluggish in general (like most Electron apps though, in fairness) and occasionally clicking and dragging images onto the application will cause it to freeze and eventually crash.
Plus, the general usability issues present in all variants of the signal client (like no easy way of restoring previous messages on a new device).
It's not terrible or anything, but it's just a solid 6/10 application. I personally wish they were more open to 3rd party clients, so I could have something that integrates with my desktop environment a little better and is snappier, like my Matrix clients.
I'll have to try clicking and dragging images onto the Signal application and see if I notice any difference. I usually actually click the button to add an attachment and then browse to it. I'm also on Win11 but I would hope the experience between OSs wouldn't be too drastically different.
I haven't used Signal desktop, but I find Electron apps in general to be very wasteful of system resources. Out of curiosity, I once compared an Electron-based chat app to a C++ alternative, and found that the former used about 25 times the RAM and generated more CPU load.
If GP's system resources are usually dedicated to other tasks, perhaps trying to run an Electron app on top of those led to resource contention, and poor performance. You wouldn't notice this if your hardware is overprovisioned for the things you do with it.
The Signal desktop app works fine, but you are right, it is still tied to a mobile account and a phone number. This is the main downside to Signal. I read that the Molly fork will support multiple accounts and a self hostable server. It probably won't be federated, but that is not really a problem when you can use multiple accounts and avoids a lot of headaches that come with federation.
The other downside of the Desktop is that it requires periodic re-verification with the device you used to set it up. Desktop users are definitely second class citizens in the Signal ecosystem.
XMPP has been great to run on NixOS… the servers uses so few resources compared to something extremely heavy like Matrix. The Movim client has been wonderful too allowing users to have calls/sharing from chatrooms (MUCs)—supporting a pretty new XEP in the XMPP space—which means there’s no good reason to be on Discord anymore if you care about the freedom/privacy of yourself & your communities.
Almost all clients support file sharing. The Movim client <https://mov.im/> supports screen sharing. It should be noted that both Jitsi & Zoom use XMPP for the roster/chat/handshaking as well; so if you set up a Jitsi server for calls & such, you would already have a working XMPP server on your server that could be co-opted.
I never managed to get file sharing working on my self hosted discord instance. Needing to setup DNS entries and subdomains for every little feature got tiresome and I gave up.
Also the default of "save all shared files on the server" didn't sit well with me.
But xmpp is so damn complicated I am 100% sure I am misunderstanding everything and doing something wrong.
If agents can generate text so easily, why would they be limited to Markdown instead of reStructuredText, AsciiDoc, or LaTeX which have rich features that help users understand text? I can understand developers refusing to adopt proper formats for documentation, but this seems odd for the bots. It doesn’t even generate the correct syntax block in Markdown using “bash” instead of “sh-session”.
MS GitHub can not only render rST & AsciiDoc (albeit pretty poorly since they the CSS is bad), but it also is employing its own fork of Markdown that isn’t compatible with other forks. “Just Markdown”, like the base spec, is so feature poor that everyone has their own incompatible fork which don’t make it render properly.
console/shell-session/sh-session (parsers call them different names) are for shell sessions, terminal sessions. Bash syntax is for Bash scripts, & these aren’t scripts but something you run in your terminal session.
I'm not convinced Markdown's various flaws matter for the way I'm using it here.
I want a simple, widely-enough supported format for mixing text, code samples and images. The non-standard (because what even is a standard when Markdown is in play?) subset of Markdown I've picked for this project works fine for what I need in Showboat.
If it turns out to need more I can expand the format in the future - likely though embedding YAML in frontmatter but I could add sidecar JSON files instead if that proves to be more robust.
I dunno. I’ve written a bit of LaTeX but does it really shine in this context? IMO the real advantage it has is that it can allow the user to express more complicated intents than Markdown (weird phrasing—my natural instinct was to call LaTeX more precise than Markdown, but Markdown is pretty precise for describing the type of file that it is good at…).
Anyway LLMs don’t have underlying intent so maybe it is fine to just let them express what they can in Markdown?
I think its primarily because that is the most common formatting in every editor now? I could be wrong. Markdown has become the standard for README files for over a decade now.
Winning a popularity contest doesn’t mean it’s good. That is the worst part of about these things as they just generate the most common denominator type code/tooling while also repeating anti-patterns/mistakes like the bash vs. sh-session/console issue I pointed out. Garbage in has been so much garbage out unfortunately.
Never said it was good, just making an observation that Markdown is most likely to be available to render OOTB in more editors. I don't think Markdown is bad necessarily either. It's "good enough" for simple document.
Documentation isn’t as simple document. There are tons of rich elements missing from the spec specifically for documentation… which is why so many resort to adopting one of the many incompatible forks of Markdown to try to get features that were missing (but are a part of reStructuredText & AsciiDoc for instance). That has a real tradeoff since these forks are not going to be compatible & they aren’t going to be as well defined as the specs for these richer lightweight markup syntax choices.
reply