I have just seen that neither the signalapp / Signal-Desktop nor the deltachat-desktop app has been ported to FreeBSD yet.

Has anyone already taken a look if it's possible or to run the (Debian-based) Linux binary? Or to run the Windows app with Wine?

P.S. I'm not using FreeBSD (waiting for 13.0 RELEASE to go onto my new laptop) or Signal yet, nor am I a developer, so this is just out of interest.
 
Last edited:
I am using signal-cli with siggo (written in go) client, works fantastically. Some weeks back, I was using the scli frontend, but after each and every update it had some problem, so I switched to siggo. I recommend that for OP.
 
I am using signal-cli with siggo (written in go) client, works fantastically. Some weeks back, I was using the scli frontend, but after each and every update it had some problem, so I switched to siggo. I recommend that for OP.
Nice, but unfortunately there is no port for siggo either. I'd prefer software that's easy to install and keep up-to-date.

I'm trying to build a native version. It doesn't work yet, I hope I'll be able to fix this 'last' error that is blocking me.
Awesome! Do you have a web page or repo for that to be able to follow your progress?
 
Nice, but unfortunately there is no port for siggo either. I'd prefer software that's easy to install and keep up-to-date.


Awesome! Do you have a web page or repo for that to be able to follow your progress?
yeah, there isn't. But for me, siggo is still preferable to scli. You need to rm -rf ~/.local/cache/scli (IIRC) after each update and you'll lose all chat history.
 
Found another interesting piece of software, that makes use of the email infrastructure, but it's Electron as well and not available as a FreeBSD port (yet) either:

deltachat-desktop - Desktop Application for delta.chat

If Electron / vscode were recently updated, it would be great to see more of such desktop-specific software come to FreeBSD.
 
Should I ever manage to get that magic commit bit, I hereby swore I'll smuggle some code into the yea free BeaSD to circumvent all hurdles & boycott all that crap to be void! Discord, Signal, Electron, VSCode -- are you serious?!
 
Should I ever manage to get that magic commit bit, I hereby swore I'll smuggle some code into the yea free BeaSD to circumvent all hurdles & boycott all that crap to be void! Discord, Signal -- are you serious?!
I'm sorry, but I don't have the slightest clue what that's supposed to mean.

I'm looking for a secure open source communication app/service that respects privacy as a replacent for WhatsApp, which unfortunately most people that I know are using nowadays.

Signal seems to be a viable option, in contrast to Discord or Telegram, though something based on XMPP should be preferred. Not sure about the Signal versus XMPP debate though, except that Signal is more bandwidth-friendly?

If you have any more thoughts on that, please have a look at the linked other thread, which seems to be more suitable than this one.
 
Damned, is there really no Gajim equivalent for KDE Plasma / QT5?

Running an own net-im/ejabberd instance would be cool, but that's just something to keep in mind for when that opportunity will present itself in the future. For now, it should be a quick and easy solution.

IDK, but for some reasons Signal is not that tempting anymore, especially since my wife just told me that it's completely out of question that she will be able to forego WhatsApp with the usebase she has to deal with, so the alternative that I'm looking for will only be used for connecting the family in a secure and privacy aware way.

Something XMPP might be the way, but I'll also have another look at Nextcloud Talk (since I have a Nextcloud instance running on a shared webhost, though the last time I tried, it didn't work well at all).
 
You can easily verify that I'm the OP of that thread...
Which thread?

The only obvious problem I see with Signal, is if one doesn't feel comfortable with using their phone number with the service. That's an understandable concern. By itself, it's more private than simply telephone calls or SMS. Signal does need to be configured to be made more secure.

Another problem is that there isn't a GUI on FreeBSD for Signal.


Signal is hands-down better than Telegram, which claims it's secure by default, when encryption has to be enabled manually, leading people to wrongly believe their communications are already secured. Whatsapp is a joke, so using a speakerphone is more private than that.


Continuing this thread is good for discussing Signal's good points, if there are more than it's better than other specific services. Signal has endorsements, but that doesn't necessarily mean it is absent of major flaws.
 
The more I look into Delta Chat the more I like that idea, but as said (I have updated the thread title and original post), it's the same problem being an Electron app.

So not sure if there will be any way to make it run on FreeBSD or if there will ever be a port (unless someone with the necessary knowledge, time and interest will look into this).
 
Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network.
Email uses an indirect federated network, meaning the communication passes through a number of servers. This design isn't secure on its own as any server point on that connection can be corrupt, as in tampered or spoofed. That's unless the whole communication is encrypted and/or tunneled from multiple prying servers/connection points.

XMPP uses a direct federated network. There's only two or 1 servers on this kind of network (there can be only 2 more connection points if a BOSH or Websockets proxy is used). The servers have to be known as trusted, and the clients can't spoof to their host server, unless the device (such as a user's phone) is physically stolen or a password is stolen. Provided the two servers are trustworthy, these two servers make a direct connection, preventing sources of spoofing or tampering between them.

A direct federated network makes direct connections: from client, to server, to server, to client. If Bosh or Webproxy is used, it goes: a connection manager is added between a server and client on one or both ends. Sometimes the servers are the same, and the connection manager is usually on the same physical location as the server. There's some data that only the servers can write to, or overwrite for sending, so that the client can't spoof it to the other end.

An indirect federated network has something like that, plus a lot of other pass through connections, which is what email is. Delta chat may be good as an alternate way of messaging, but using the same system means it uses an indirect federated network, unless there's a difference in implementation.
 
I wouldn't be concerned about security as long as a sane end-to-end encryption is used, which is at least claimed on the project's website.

Still I think the choice to build instant messaging on top of email is pretty weird. Email was never designed to be "instant", it's designed to handle temporary errors gracefully (by queueing on each MTA and retrying failed attempts to pass the mail to the next one, with increasing waiting times, up to several days isn't uncommon) and also allow redundancy and alternative paths. And then, it's still "best effort", there's never a guarantee an email sent out would ever arrive. Taking all this into account, that's really NOT what you need for instant massaging.
 
sidetone Zirias

Delta Chat is not a newcomer, implements the Autocrypt Level 1 standard and can thus E2E-encrypt messages with other Autocrypt-capable apps, and also supports a strong form of end-to-end encryption that is even safe against active attacks (see “verified groups” and more info in the FAQ).

The whole system is a proven concept and it's obviously working very well.

The main benefits I see over XMPP is that you don't need to run your own XMPP instance or have to sign up at and trust a 3rd party server, and that you can reach anyone with an email address, even if the other side is not using Delta Chat, in which case the other party simply can participate using his/her usual email client (only then communication is unencrypted, unless that email client supports Autocrypt or manual OpenPGP setup).

It really is a fascinating concept and totally reminds on how WhatsApp became that successful (by using existing mobile phone numbers instead of regular signups). Just think about it, you can easily reach anyone with an email address without the other party having to sign up or install any software beforehand, so no convincing to move to a new service involved, with the other side hopefully getting interested and starting to use that system after the fact.
 
You just ignore the fact that email is NOT a viable transport for instant messaging, see above. Reuse isn't a bad concept in general, but I think this particular idea is, uhm, pretty strange :)

As I said, I tend to believe the end-to-end encryption is ok. Of course, only having direct s2s connections (like XMPP) still has the little benefit that fewer machines can see conversation metadata (who is communicating with whom). I don't consider that particularly important (direct connections are just a necessity for synchronous acknowledged, aka, instant communication), but I'm very sceptical about the solution for the reasons explained above.
 
FAQ: If Delta Chat uses E-Mail, is it really an Instant Messenger?

Sure, there are differences to something line XMPP, and it may be a strange idea, but from what I've read so far it really seems to be working very well.

I'm just in the research phase right now, so I haven't tested it, but whatever the outcome, having a port of deltachat-desktop for FreeBSD surely would not be a bad thing.

There are some native approaches without Electron in the works. What I have found so far (though the latter two look abandoned):

KDeltaChat - a Delta Chat client using Kirigami framework
deltar - delta desktop application in rust
deltachat-cursed - a ncurses Delta Chat client developed in Python with the urwid library

If work for Electron on FreeBSD has resumed and building Electron apps is the issue, not running them, any idea what's needed to try running a prebuilt Electron binary on FreeBSD?
 
Back
Top