Why not 0xchat?
Private key login, encrypted private chats and contacts, encrypted group chats, and lightning payments. Decentralised, built on Nostr. Available on all platforms.
Private key login, encrypted private chats and contacts, encrypted group chats, and lightning payments. Decentralised, built on Nostr. Available on all platforms.
Also, the direct messages have three types
1) NIP-04 DM: "Most widely used", but also, "not recommended". Reeks of Telegram that also has non-secret chats being the most popular option
2) Gift-Wrapped DM: Uses different encryption algorithm but no forward secrecy? Forward secrecy has been around for 20 years.
3) Secret DM: Can't be recovered on different devices. Why can't the backup be self-contained database like Signal has?
Also "Secret chat requires consent from peer." Like what :D You have to wait for contact's approval to have a private conversation with them. Sounds like it incentivizes all chats to start with less secure protocols.
The nice part about writing your own chat system is the security agility in that you can bump any security property without having to fight with protocol standardization bodies. Having three DM protocols inside the same app is wild.
Certainly if no one can implement these two things it is functionally a closed source project. It also is a security failure from the standpoint of control, validation, and also future security and vulnerability patching (there's a graveyard of dead "secure" messaging apps.)
Is DeltaChat perfect from a security standpoint? No, but it's certainly well above the hurdle most people are at now. Most people are using non-encrypted communication that is actively scanned & stored, or e2e on paper stuff where one party controls the client, server, application, and storage (trust me e2e security.)
Telegram, Discord, Facebook Messenger, stop using that shit.
edit: I didn't downvote you and I don't think someone asking an honest question like this should be downvoted
It's less safe compared to Signal, and Signal is the gold standard recommendations for average Joes. "Better than Telegram" is a low bar.
Telegram is a walking time bomb with 900 million users' data waiting to be leaked from the servers.
>and, deltachat.
That must be why I've never heard of anyone using it.
>deltachat is the only one that doesn't require a smartphone and a phone number.
It leaks the IP-address to the server, which by default (defaults matter) is nine.testrun.org. That server can amass metadata about users conversing, and any government entity that comes knocking can look at TelCo records about to which user the IP-addr was assigned at the time.
If you're going to try to address metadata privacy against service provider, you're going to have address it properly, and DeltaChat isn't the one at that point. Neither is Signal. You'll want Cwtch for that.
the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy. and maybe deltachat is not the best possible, but it is pretty good. remember, when security and privacy are to onerous then you don't have security or privacy because people will refuse to use the tool.
Which doesn't really work in practice. The closer you move to the user, the more the threat of creepy buddy watching over metadata of people they know grows. Medium sized institution like university or a company might run their own, but that's also somewhat risky.
>the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy.
No. The question is, given an architecture that imposes fundamental limitations on what can be achieved, which tools under that domain have best privacy by design system, where the UX and features are maximized with ingenious design, is the best.
Fundamental architectural limitations:
Does Delta Chat use data diodes? No? Then it can't have key exfiltration security, but it can have message forwarding.
Does Delta Chat use Tor Onion Services? No? Then it can't have proper metadata privacy for users' identity from the server, but it can have offline messages.
These are fundamental trade-offs.
DeltaChat is content-private by design. It might be metadata-private by policy (internal policy that server on nine.testrun.org does not collect metadata), but until that is tested in court like Signal is, we can't know for sure.
Signal is content-private by policy. Cwtch uses Tor Onion Services so it's metadata-private by design.
Now, it's fine to argue which is the best inside one league.
Element/Matrix is E2EE with double ratchet protocol, so it has both forward secrecy and future secrecy, which DeltaChat doesn't have.
It's only once security is more or less exactly on par, that you should be comparing general UX. Really usable but insecure tool might turn into really unusable tool when you sit in prison for your political opinions, or because you revealed your ethnicity and ICE caught on.
>maybe deltachat is not the best possible, but it is pretty good
It's not the worst out there. At least it tries to do things properly. It's just that given that there's insane obstacle of moving people to a safe platform, DeltaChat is just another distraction. Until it does what competition does security wise, and improves on their UX, it doesn't get the top podium.
>when security and privacy are to onerous then you don't have security or privacy
Sure, but when you're in prison for using crap tool, you won't have liberty, security, or privacy.
ideally yes, but that is not what the average user will do, and it is not what i can use as an argument to get people to switch to something more secure. convenience over security is still a user preference.
i get your point, but that falls on deaf ears among family and friends. especially using prison as an argument is really not helping. i mean by the same argument we should not be having this conversation on hackernews, because clearly we are trying to subvert the authorities by suggesting that people should keep their communication secret.
actually i don't follow that argument. it is more likely that my data gets caught up with someone accessing a larger server than my own server. if someone targets my own server they may as well target all my messaging clients and get all the data from there.
The proper way to address this is with p2p messaging, like Cwtch, where each user is running server for their own account. Cwtch also experimentally supports caching ciphertexts on a server that's hosting the group chats that all members will have access to anyway, so there's no peer metadata to eavesdrop on.
in fact this particular threat that you describe is more likely to happen at a university server where a rogue admin may use their privilege to snoop on people they want to stalk for whatever reason, as opposed to the friend that i chose because i trust them, like say the admin of the server of the local linux user group or the hackerspace that i am a member of.
in fact i am more likely to trust anyone that i know in person, simply because even if that person decides to snoop on me we can work that our in person, and the likely hood for it happening is low because it would affect our friendship. and i would guess that this is true for most people.
at some point you have to trust someone, and the closer you are to that person, the easier it will be to resolve problems.
University students don't get to run infrastructure of the facility, and at least in my uni, the old beard IT staff members and faculty don't really hang out with the students aside course environments or support groups, so there's a bigger gap. There's also salaries and careers in the line.
But bickering about who's trustworthy is pointless when there's trustless architectures for those situations already.
i am not saying it can't happen, but that the smaller the group the easier it is to assess the risk and the consequences. and for that reason i prefer smaller groups.
in austria and germany hiring students for part time sysadmin work is very common. i did those jobs and on the other hand stories from staff stalking that cute student they saw one day do exist.
But bickering about who's trustworthy is pointless
agreed. it all comes down to personal experience and preference.
when there's trustless architectures for those situations already
the problem is that the choice is not made in a vacuum. what good is a system if my friends don't want to use it. for almost my contacts i had to follow the choices of the others. very rarely someone followed my choice. and when they do i have to consider their technical capacity and tolerance to difficulties.
Russia probably has all the Telegram data, considering they officially intervened in the recent Romanian presidential elections taking the side of the local MAGAs.
https://www.reuters.com/world/europe/telegram-founder-says-h...
What the article doesn't say is they sent a message in romanian to all romanian telegram users with the above claim, signed Durov.
So I don't think their "security" can be trusted.
Anyone up to the challenge?
still i like the idea. but deltachat also has a nice UI, and for matrix i use fluffychat which is also quite nice.
Using an email address as an identifier for IM is a great idea (I hate that everything uses phone numbers for this, which are not internationally portable and not possible to reasonably “self-custody” the way TLDs are).
But using the actual email protocol as a backing protocol for instant messaging seems like a weird contortion and still makes this effectively a separate protocol, the split being servers that do and don’t support all necessary extensions. The overhead must also be staggering; just look at an email header to see how much is going on for each message these days.
Notes and Other Stuff Transmitted by Relays.
It’s just signed json messages distributed by [websocket] relays.
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
Effectively nostr objects lay around on relays until they reach some server-side expiry policy and sometimes forever if one can't figure out how to delete them. Nostr clients (web and mobile) are the wild west of good luck with which features and NIPs they support (XMPP all over again). My experience here led to dissatisfaction as well. Relays are another wild west - it's choice paralysis and a helping of good luck with that.
The real problem for IM: Nostr does not ensure all relays sync, instead a user chooses their preferred relays (some you pay for in crypto). It is entirely realistic (I experienced it) that you're on relays other people aren't and you can't share content. This is death for an IM app and just trying to use Nostr became frustrating. (not to mention it's flooded with porn and crypto shills)
Edit: a nostr client has to keep open network connections to all these relays, as objects can be stored on multiple relays and it's up to the client - not the relays - to query all relays and then de-dupe the JSON responses. There are combobouncers in use (who will de-dupe) but they're not the default and tend to be read-only (because you can't choose which relays to post to when using a combobouncer).
It’s worth highlighting as there are many affinity scammers spinning up tokens/blockchains called “Nostr”.
But - has there been security audit been done?