Thank you!
Added new column for Quantum resistance but only as place holder. If you like you can fill these out with references.
Message padding
OnionShare
No
Might be wrong because Tor itself uses padding already so OnionShare doesn’t have to do that since it is using Tor?
Reset to ? for now so the page edit can be accepted earlier.
! <!-- feature --> Signed application releases
<!-- <del>Dino IM</del> --> <!-- <ins>SimpleX</ins> --> <ins>{{Yes}}<ref></ins>
*https://github.com/simplex-chat/simplex-chat/releases
The reference does not back that up. SHA sums aren’t signed releases. Only OpenPGP, signify, codecrypt or similar would be considered signed.
Please test actual release digital signature verification before claiming it’s supported.
If you never verified digital signatures, you cannot really judge if it’s provided or not.
Please recheck / fix or set to ?.
Same for signed source code. The “verified” badge on GitHub can look nice but be nonsensical. When you click it:
This commit was created on GitHub.com and signed with GitHub’s verified signature.
That’s not a “real” signature. Real is considered if developers create their own keys and use that sign git commits. Here also, please verify git commits before claiming they’re signed.
If signed by GitHub, that’s besides the point.
Why Gajim, dino-im doesn’t support multiple devices? Since it’s XMPP, multiple device usage is trivial, no?
How OnionShare supports multiple devices?
Gajim supports voice messages?
** Telegram sends the user’s personal data to the interlocutor to the chat: registration date, region of the phone number, common groups, and any changes to the name and avatar (if it have been changed in the past 30 days).
Please specify it’s “only” month and year. Not “date”.
Common groups and changes to name/avatar needs reference.
Offline Messages / Backlog
Why XMPP based clients get “no”? If conversation partner is offline, server will still deliver the message. The sender can send a message and go offline. Recipient will receiver it from the servers as soon as the receiver goes online. This feature often does not exist in serverless (decentralized, without a server) networks.
Audited protocol/crypto/client
Confusing. We’re comparing clients. So the client should be audited. If the client wasn’t audited, that’s a disadvantage.
The protocol/crypto can be amazing but the client might in theory implemented it wrong.
So this needs either different columns (for protocol / crypto / client) or a different table. Different columns probably preferable.
Could you also please add the references to the audits as they aren’t trivially found?