Just a heads-up that #Snikket#Android has been pulled by #Google from the store. We'll work on restoring it once we figure out their (as usual) nonsensical complaints. Apologies to everyone affected. Please look at #FDroid and free yourself.
Today's excuse for delisting yet another #XMPP app?
"Your app is uploading users' Image information without posting a privacy policy link or text within the Play Distributed App."
@snikket_im
They de-listed a browser plugin I made and pulled my developer license, because I pointed out that, as data never leaves the users device, and I don't seek access to it; I don't need a data policy.
I personally feel that this is the optimal delivery and update methodology for future software distribution.
I've written about this at length in several articles, and more and more service daemons and client software are taking advantage of this form of direct from the developers method of delivery - not just Android apps.
#FairEmail is one such app that even states in the docs that this is the preferred method, although they do support a total of four methods:
Google PlayStore - crippleware due to google funding source restrictions. In all cases, this is by far the worst distribution point for software, if not with respect for the product that the developers want to deliver, but also with regards for the privacy of the users who are tracked, mined, and themselves repackaged as a quantifiable inventory item.
F-Droid custom Dev's repo - 2nd best option, because this is built with the developer's keys when the developer decides to push the product, and contain all feature sets that the developer chooses to include.
F-Droid repo - 3rd best option, since it is signed with F-Droid's keys and typically lags by some measure of time with respect to release dates, considering that F-Droid staff pushes these out on a best effort basis, according to the time they have available to do so.
Direct from the developers Git repo - This is the best method. They push a release and the next time you open the app you're notified of an update.
This is part of the magic of Slackware's philosophy too - Patrick and team don't church it up like most distro's do (Debian and AlmaLinux quite often, quite heavily wrt customizations, use Apache or Nginx HTTP servers as examples). Slackware tries to package up software as close to how the upstream intends it to be.
In earlier articles I've published on the topic, I've focused at times on a solution to a theme proffered by #Moxie_Marlinspike, who denigrates the open source model somewhat, for being at a great disadvantage when compared to that of proprietary solutions that can update and evolve protocols, APIs, etc., on a whim, because they're centrally managed and controlled by a single dictatorial source. Microsoft is one such classic example. You simply have NO CHOICE as to when you must allow your software to be EOLed, evolve, or update itself.
Using this model, however, where a central repo, or a distributed, CDN type of repo mirroring is deployed at the origin by the development team itself, FOSS has no problem upgrading even things like protocols as they evolve. Of course, it is ultimately up to the operators of the software to allow updates and the prerogative of the developers to establish the level of nags that users of the software will experience until they permit the updates to occur, but that's beyond the scope of the basis of advocating for this type of delivery model.
Okay I think I'm bordering on hijacking this thread, so I'll make a comment about these types of shennigans by Google, and how one one hand it's certainly a huge frustration, if not an impediment to being found and adopted by users, but moreover, a predatory practice by one of the most egregious violators of personal choice in the free market of consumerism and commerce.
It may hurt being pulled like that, but IMO, I don't think there's anything preventing the good folks behind #Snikket from pushing out the kind of crippleware that google wants them to, while at the same time pushing banner splashes in the app that explain just how fricken' useless it is under the terms necessary to distribute it via that medium, and encouraging users to install it instead by following the instructions at the #git_repo for a fully featured, #e2ee secure messaging platform.
IOW, there's always a silver lining - wear this dejection as a badge of honor and as the evidence to support the fact that you're on the right track!
Many people affected by the recent blocking of #Telegram in 🇪🇸 Spain are looking for alternatives - especially decentralized ones.
#Snikket is one of those alternatives, and fully open-source. However, our Spanish translations are lacking, which can lead to a poor experience for our #hispanohablante friends.
If you think you could help us with translation, please reach out 🙂
@shuro Snikket is XMPP for people who don't know what #XMPP is 🙂
If you're happy with Conversations, continue using it! Snikket is more limited because it focuses on a specific use case.
If you want an easy-to-use messaging solution for a group of people (e.g. family, friends, clubs), plus companion apps and easy onboarding without forcing people to learn what a "XEP" is, then Snikket is here for you: https://snikket.org/start/
We've published a new blog post about the recent jabber.ru security incident (a kind of attack we have not seen before). It did not affect Snikket servers, but we are taking steps to remove the possibility of such attacks in the future. This includes advice that self-hosters can follow.
@jabberati
Thanks! The problem is that we have hundreds of domains on our service, and so we really need something that can identify rogue certificates without drowning us in notifications about all the legitimate ones. That's apparently a bit harder...
@snikket_im very curious as to what you decide to do about CRT monitoring. Please share what tooling you end up using/developing, even if its something off-the-shelf!
Our latest blog post dives into the funding of the Snikket project. Funding open-source is rarely easy. Grants, donations, sponsorships - we've tried them all 🙂
Our :snikket: blog has been quiet for a while, so we just kicked off a series of blog posts reviewing the current state of the Snikket project - where we're at, and where we're heading:
@snikket_im
> big thanks to @strypey for putting the effort into this initiative
Aww, it's great to be recognized 😁
Disclaimer: Snikket is an important Free Code business project, which I'd happily support as a volunteer while it gets underway. But I was paid for some work like this in 2020, and due to... well... 2020, and the years that followed, I've only just got to a place where I can finish that work. Huge thanks to Matt for his patience, and trusting that I'd get there in the end.
@Goffi Good idea! It seems they are currently "out of stock" though 🙁
Will do some research on possible other reputable providers (it's hard to verify the security of remote systems, and they would have access to the credentials for the Apple developer account).
@whynothugo
There is no "Snikket protocol", it's just XMPP! We believe strongly in open standards. After all, the founder of Snikket is the current Executive Director of the XSF 🙂
That said, we are focused on showing the best XMPP can offer, and we prioritize things like usability and security over backwards compatibility. We do what we can to help lead the ecosystem in these things, and move XMPP forward in implementation as well as specifications.
@snikket_im Thanks, I got that impression after going through the FAQ. The current website is oriented to people who’ve never heard of XMPP. I think it’s missing an “Snikket for XMPP users” link in the footer pointing to a page tailored for people familiar with XMPP who want to understand what’s distinct about Snikket from that point of view. Eg: most of the website focuses on how this is better than WhatsApp, but for somebody comparing XMPP servers that’s not the kind of info we need. (1/2)