Snikket is meant to be super simple to self-host. Ejabberd has a web GUI that can make configuration easier.

You could switch some of the problems with perf in switching away from the Python implementation server as well as Element clients but these support the most up-to-date features & the majority of users are now relying on these features that often don’t degrade graacefully.

The bigger issue is eventual consistency. Eventual consistency will not scale for small self-hosting. Every message & every attachment for every user in every chatroom they have joined must be duplicated to your server. This is why joining rooms sometmies takes 10 minutes. Even if you make this async from the client side instead of the current long wait, your server & storage are still taking the hit. A lot of small collectives had to drop their servers for performance & cost (read about yet another one today on the Techlore thread at c/privacy where now only Discord is used for realtime coms). This model is required to copycat the ability to search the entire history like the big, proprietary chat apps such as Slack/Telegram/Discord, but they are centralized so it is easier to manage—but its overuse for all announcement & trying to replace forums turns it into a black hole for information. Your small community probably does not need persistent chat like this—persistent info is lighter & easier to crawl as feeds & forums. With medium-sized servers shutting down, only the biggest & smallest hosts are still kicking with most metadata is largely centralized around Matrix.org who also hosts some of the other larger instances.

If you agree that chat can be chatter as well as ephemeral there is lightweight centralized chat in IRCv3 with TLS has most of the features you need with a longer legacy & massive choice for clients & XMPP for lightweight decentralized chat with a long legacy, client options too, & can be self-hosted in a bedroom on a toaster in comparison which increases the chances of self-hosters & decentralization. These were built in a time when we didn’t have such wasteful taste in tech since they needed to be efficient & only sip power/data in comparison both for clients & servers & storage. The bigger question IMO is what are fundamentally wrong with these two mature options that we need a new option built on unextensible JSON & Israeli Intelligence money?

Exactly. Our words matter & the sooner we stop using Google to mean search or MS GitHub to mean code, the sooner we can start shifting the narritive towards entities that better respect our privacy or even gasp self-hosting. Word choice for social change is just as important for spreading the message.

Hardening aside, I like that LibreWolf actually lets you turn on JPEG XL.

If you want a rush, try gyukuro. Flavor of an umami green tea with the caffeine level of a cup of coffee & high L-thiamine to cut the jitters.

I lived it the UK briefly & my roommate never understood my fascination generally preferring his Yorkshire tea (trash). One day he asked about it so I made him a mug (we used coffee mugs). He said it tasted like yard clippings like other green teas before walking off continuing to sip to not waste it. He comes back in 15–20 minutes later over halfway finished, “Did you put drugs in this‽”. “Nope.” “I feel like I want to run a marathon. Okay, I see the appeal for your mornings, but this is the worst high ever.”

Gerrit is probably the poster child for branchless, stack-based diffs in Git. It takes some get getting used to, but once adjust your thruput is really ramps up. In some sense tho, this is a hack by tagging changelist values in the commit message to help reconstruct what the heck is going on due to Git limitations, but it’s old & robust enough to trust that system & many of its users absolutely swear by it (I have limited exposure but have used it more recently I can feel the appeal). You should be able to slap it in front of any Git server—even just straight host HTTP if not something lightweight like cgit, gitweb, or Ayllu. (Jujutsu is the same commit hackery in a different package & I don’t think it moves the needle as much as folks think being ultimately shackled to Git’s design decisions).

If you look outside of snapshot-based tools like Git, Mercurial, & so on, patch-theory-based options offer refuge. Darcs & Pijul are the leading (D)VCSs in the space. Darcs is very mature & shows its age in many ways (but is still developed & works good enough). Pijul is largely based on Darcs but meant be faster (& is), but it is immature; some features are missing on purpose to avoid the swell of Git commands, but I am personally surprised theres no good story for sending patches nor rebase. That said its identity system is how VCS should do it. Both VCSs have a lot less tooling built around them. Darcs is still supported by tools like Nix (but not Flakes) as well as Opam for OCaml with darcs hub & Smederee for maintained public forges. Pijul isn’t supported by much at all unfortunately & while Nest is a public forge, its lacking in features & basic usability like being able to fetch a tarball (despite pijul archive). All the latter negativity may sound bad, but all tooling requires momentum. They would be prime candidates for the Gerrit workflow--just without the hacks needed. With the two being similar, I hope we see more tooling pop up to support them & just like trying a new paradigm of programming gives you insight on the ones you know, a new way to do VCS will teach you about version control. Do recommend.

client or server that doesn’t support the same encryption protocols

Outside of TLS which most any server uses by default, XMPP or not, the server is not responsible for E2EE. Conversations Compliance & Are We OMEMO Yet have existed for a long while & I never see anyone recommending a client not on these lists so while certain features may be fragmented, the communication essentials have been more or less established for years now. XMPP is an extensible format, and some applications that aren’t for chatting with your friends/family, don’t need many of these features which allows the protocol to morph into something stripped down for the task… which is why the base spec is basically barren, & community XEPs are what folks get behind for adding new features for different use cases.

The best is to not trust the centralized server of either of these platforms. Set up your own XMPP server & gives these the boot.

This isn’t speaking, but writing (or typing). Using ‘correct’ spelling & grammar helps ESL speakers read the language as well as those relying on text translation software. Some folks make typos & it’s fine to make mistakes but it’s also strange to act like it’s just as easy to understand. Apostrophes have a specific meaning & many folks rely on them for understanding.

I’m learning a foreign language now & I can tell you it is a massive stumbling block when you run into what you think is a new word, but is ‘just’ a misspelling.

My issue with this account is not its corrections, but if you want to be the correction bot, at least get the typography right too. ' is as ASCII holdover & it should be ’.

True. Something like XPath can really help & there are use cases where that is more concise but requires loading XPath into your head like Regex (which tends to get unloaded). The extensibility shines tho as seen by XMPP continuing to this day with very good backwards compatibility with 2 decades of updates since everything in an extension to the base.

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.

I didn’t do more due dilligence than looking at the ProtonMail downloads page + system requirements page—neither of which mentioned source which would instill better trust. So you’ve got me there, but really dumb there isn’t a link.

Open source or not, you still have to use their clients on mobile OSs even if you prefer running a client like K-9 & can’t run on a low-spec OS KaiOS (I suspect the site wouldn’t scale down to this either), etc. Mail protocols are old & should be able to run on a potato without many hoops.

Where I definitely don’t agree tho is the free-tier thing. Having access to the bridge cut off as well as not {Cal,Card}DAV is a real pain that forces the premium subscription, switching providers, or using something like Google for calender/contact defeating much of the purpose. If there was no free tier to subsidize everyone could pay a lot less & get “premium” features others deem as essential. $50 annually is a lot—$12, not so much.