Wow, relying on Signal might actually be a Very Bad Idea™
In below longread there's a lot to unwind, but the essence is this: it is a state asset for American imperialism built on the infrastructure of Big Tech.
So... uh... @delta it is then?
counterpunch.org/2025/03/07/th…
The Revolution Will Not Be Signaled - CounterPunch.org
We are constantly told that the messaging platform Signal is totally secure and benevolent. While Signal may be preferable to the dominant alternativesThe Mapping Project (CounterPunch.org)



ltning
in reply to Emil Jacobs - Collectifission • • •@collectifission @delta
feld
in reply to ltning • • •@ltning what platforms are you referring to?
I thought Mac/Win/Linux/BSD desktops, iOS, Android, Ubuntu Touch... some CLI versions... were enough?
ltning
in reply to feld • • •feld
in reply to ltning • • •@ltning it runs on Debian AND FreeBSD !! 😇
It could run on more if they have Dovecot 2.3 and people adapt the configs
ltning
in reply to feld • • •@feld Uhm, I only find references to Debian (12) - I've been looking for a while for people running the server components on FreeBSD (without linuxulator or VMs) and haven't found any?
I wanted to invest some time in unpacking the whole pyinfra stuff with a "how hard could it be" approach, but somehow I haven't gotten around to it yet :D
feld
in reply to ltning • • •@ltning I'm the guy that maintains it on FreeBSD. I converted their pyinfra stuff to Chef so it's not hardcoded to Debian, provide custom FreeBSD packages where needed, and patched their python code as necessary (upstreaming changes, gap is closing)
github.com/feld/chatmail-cookbook
GitHub - feld/chatmail-cookbook
GitHubltning
in reply to feld • • •feld
in reply to ltning • • •ltning
in reply to feld • • •@feld I think we have diametrically opposite preferences for how to manage things. I find that having stuff install outside of /usr/local and without using pkg or ports is generally a bad idea. If I need stuff from pip/npm/whatnot, it should be installed locally to a given user, not globally like suggested here. My biggest concern is the lack of maintainability.
But I'll see if I can give this a go, somehow. There's nothing in this bundle that, apart from some custom-built packages, should need anything special, so converting to a base-package approach should be mostly a matter of "getting it done".. :)
feld
in reply to ltning • • •johnny peligro
in reply to feld • • •@feld @ltning > isolated from the OS so if packages/libraries break, it doesn't break Ruby/Chef and Chef can potentially still run/repair things
it kinda sucks that one can't really have stuff all coming from the OS' package repo because of this
feld
in reply to johnny peligro • • •@mischievoustomato @ltning for certain automation/monitoring tools you either have to break the unix mantra of "everything is shared, only one copy of stuff installed" or build static binaries
that's another reason why Go got so popular -- it avoids this mess by producing mostly static binaries
ltning
in reply to johnny peligro • • •@mischievoustomato @feld I don't quite understand this concern. If stuff is broken in the OS package repo then you're screwed anyway and I certainly wouldn't trust a config mgmt tool to "fix" anything. But I'm sure there are pains I have not experienced, so what do I know ;)
And regardless of all this: chatrelay depending on custom patches to upstream software is bad enough; that it seems hard-to-impossible to manage it using standard tools (even on the recommended platform) seems to me to be unfortunate. Each individual part looks fairly straight-forward from a cursory glance..
All that said: @feld - thank you for making the effort. You've made it much easier for me to understand how it all works, and potentially getting my own relay off the ground.
feld
in reply to ltning • • •@ltning @mischievoustomato
> chatrelay depending on custom patches to upstream software
It's actually zero. The only patch they have is a dovecot change that removes an unnecessary sleep/debounce that slows down message notification/delivery by 500ms
github.com/dovecot/core/pull/2…
everything else is just the specialized configuration and some custom python (later: rust) services that filter emails, lua scripts for dovecot and opendkim.
feld
in reply to ltning • • •@ltning @mischievoustomato
> If stuff is broken in the OS package repo then you're screwed anyway
I think FreeBSD believes the opposite. It's why we have a /rescue. 😀