• 1 Post
  • 27 Comments
Joined 4 years ago
cake
Cake day: June 28th, 2020

help-circle




  • You’re in a privacy-related space that values keeping data away from the corporations—that’s why your response has a worse ratio. If you don’t want your messaging data with data with Meta or Google, why would you be okay with Microsoft for your code? I like that instead of acknowledging the multitude of options you would have that puts your project in better position for contributor privacy, you chose to attack the one you disliked the most, mailing lists, & dismissed everything else. It’s really not any more difficult to pick up something like Codeberg & the UI loads faster too.

    If someone said “WhatsApp is what I know, why should I care about your $MESSAGING_APP?” would you not, like, send them the output of your project to explain how their digital privacy is at risk? Consider building another list comparing code forges & see that you get little extra from MS GitHub being closed, proprietary, centralized, for-profit/publicly-traded, requires accepting Microsoft ToS to create an account, search locked behind auth, slow to load, slow to fix bugs, has outages constantly, locks out all users from Yemen et al. due to US sanctions, plays ball with capitalists (such as following record label demands to take down youtube-dl), pushes ‘social’ features (massive can of worms), tries to monopolize the developer space on the network effect, etc.


  • Define covers… With something like Mumble for instance, you can host a server (real server, not Discord ’servers“), have low-latency real-time chat with noise cancelation algorithms, directional audio, etc. & it comes with a chat you can use, it’s just not very robust. But there’s also a decent chance your group or whatever isn’t using all of the features & could be happy with IRCv3 & XMPP since you can share text, image, videos. My biggest gripe tho is that some communities use it as a replacement for forums or Atom like you were supposed to read & follow every thread because they want to shoehorn Discord as the one-size-fits-all tool. The other issue is not treating that sort of chat as ephemeral–opting to assume users want or need the entire history (which reminds me that I should do a better job with my bookmarks & note taking than relying on search); but also while the history is ‘permanent’ it’s not publicly accessible in the cases where community decisions should be seen (such as making roadmap for an open source programming language) where those not present for the conversation may have missed it, have trouble referring to it, & the search engines can’t find it since it was locked behind Discord’s walled garden.

    In a lot of communities historically & still operate in a manner where important discussions & long-lived threads live on the forums, and real-time chat is treated as social or one-off questions/tips. Operating your community with two different tools here is okay… even a third for say video conferencing if it’s not something you do often, especially if it means one or more cogs in that wheel of communication can be non-proprietary.

    Additionally I missed adding mailing lists as an option as well as Zulip for forums/chat.


  • Adding to sibling… Discord is used in a couple of different ways at present for communities. If you mean voice coms for gaming or otherwise, Mumble should be in your repository. If it’s more of a of a Slack-like business chat, self-hosted Mattermost is actually pretty nice. If it’s just text chat, IRCv3 & XMPP have that covered & scale massively even on a home PC. If it’s voice calls, Jitsi or Jami can work. If you are posting updates or things that should be forum topics, you shouldn’t be using chat anyways where Mastodon, Misskey, Lemmy, & other Fediverse options or even Atom feeds can suffice. If you want integrated chat, community updates/posts, voice/video calls (unsure if conference calls are support) Movim is a good option–and if you don’t mind the rough UI edges, Libervia can do similar but also integrates a calendar for events. Bear in mind as well that a lot of these technologies can be bridged between one another to avoid some of the lock-in, but I would hesitate to force everyone’s chat to be piped & logged thru Discord’s servers. It’s also not bad to say “we use these 2 services” rather than requiring a kitchen sink communications application.




  • With an FPGA or special CPU instruction set, the encryption algorithms could run on a toaster—which would give access to whatever low-spec handheld you wanted without making it chug to have strong encryption. That also still isn’t covering the future hope of a Linux phone, or someone that just wants to register an account on their laptop.

    Using forks puts stress on other teams to keep up with breaking changes, & 90%+ of folks won’t be looking for forks or be willing to trust their unofficial status. I saw the code for UnifiedPush as a Mattermost plugin & it was like 50 lines or something small which is much less than the rest while allowing users to keep control of their metadata which is a big deal if you care about privacy. A fork for SMS support would encounter similar issues, & now you either need to compete with Molly or copy its featureset otherwise users have to choose, SMS or UnifiedPush. That said, I agree with the SMS situation since it was easy to convince relatives to use this new “text app” where encryption magically came to a chunk of their contact list.

    Saying emoji was the most important was tongue-in-cheek, but it makes the application feel non-native (& I think Apple’s emoji are particularly ugly). You would think at least the Google set was shipped to Android, or—now hear me out—not ship emoji, don’t override the user experience, let the user’s fontconfig display the one they set. Shipping a whole font (or images) for emoji is why the application size is so bloated for a chat app.



  • I made the mistake of getting my family to switch to Signal. It works great for messaging, but it has other issues—beyond the typical SIM-required complaint. I hate that you have to register with a ‘primary’ device on either iOS or Android fueling that duopoly (SoL if you are on a postmarketOS or KaiOS or Capyloon phone… or just don’t want a internet-capable phone). Notifications are sent thru Google’s FSM (news 1–2 months ago that of course Apple & Google send all the metadata to the feds) & refuse to support UnifiedPush (thank goodness the Molly fork does). They’re also not too happy to support alternative clients meaning you are stuck with the shitty, resource-sucking Electron client while not having a web client or native or TUI client. And the worst cherry on top is shipping those iOS emoji to Android & Linux …eww.


  • Git provides itself, so forges aren’t even required (the d is distributed version control). Issue trackers don’t need to be attached to the code forge. Even if you like someone else hosting it & an sidecar of integrated bug tracking, it should not require an account with Microsoft if privacy is the end goal—and there’s a host (pun not intend) of other options.

    PRISM Break, Calyx live on GitLab (not obscure, supports SSO). Many free software projects like Freedesktop, GNOME, KDE, DivestOS, Briar, Jami self-host the community edition of GitLab. Privacy Tools & Awesome Privacy mirror to Codeberg as well as MS GitHub, presumably to have an escape hatch to the megacorporate bubble & to practice what they preach about privacy. LibreWolf is exclusively Codeberg. Cwtch self-hosts Gitea. Prosody self-hosts its Mercurial server. Choosing not Microsoft GitHub puts you in good company.

    If a mailing lists alternative isn’t your thing, Forgefed, federation protocol for software forges, would apply for anyone with a Fediverse account (so Lemmy) could submit issues with Forgejo building it in along with others soon (GitLab expressed interest).

    Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.

    —Matt Lee, https://www.linuxjournal.com/content/opinion-github-vs-gitlab



  • Dino, Gajim turn on OMEMO by default & even the TUI Profanity prominently displays [unencrypted] in red at the top by default nudging you to pick OMEMO, OTR, or PGP for end-to-end encryption. The protocol is generic on purpose & meant to be extended with encryption which in the case of private chat applications, is now defacto. Much in the same way, TLS isn’t required since there are application that don’t require it, but defacto, all guides for setting up a XMPP server for chatting applications will suggest TLS where some servers have options like s2s TLS required or it won’t talk to the other server.

    Seems weird that there’s a big, red no even when all the defaults point in the direction yes for human-to-human chat. Much in the same way some values are wrong like apps & servers being open source when there very much are proprietary XMPP servers out there like WhatsApp & Zoom. There’s also a reason Tails OS comes with Dino (or Pidgin) & every dark web guide explains how to connect to XMPP thru Tor + OMEMO/OTR, because it can be secure & anonymous enough for criminals & whistleblowers while being lightweight & decentralized.