2022-03-06 18:46:04 +00:00
|
|
|
# Features / Roadmap #
|
|
|
|
|
|
|
|
This service offers a lot of features, but is still lacking some of the things
|
|
|
|
we want in order to further improve the security and usability of **XMPP** for.
|
|
|
|
|
|
|
|
What's there? What's to come? These are the questions we seek to answer here.
|
|
|
|
|
|
|
|
> Please note that we only talk about *server* capabilities here, to see what
|
|
|
|
> each of the **XMPP** *clients* we support can do, please refer to our [list of
|
|
|
|
> supported clients](/clients).
|
|
|
|
|
|
|
|
| Feature | Are we there yet? |
|
|
|
|
|-----------------------------------------------|-------------------|
|
|
|
|
| Basic **XMPP** | YES |
|
|
|
|
| Mobile Optimizations | YES |
|
|
|
|
| File Uploads | YES |
|
|
|
|
| Community Chatrooms | YES |
|
|
|
|
| Invite-based Registration | YES |
|
|
|
|
| Invite Creation for Community Members | NO |
|
|
|
|
| TLS-only Setup | YES |
|
|
|
|
| STUN/TURN NAT Traversal Service for A/V Calls | YES |
|
|
|
|
| Settings Bot or Dialogue | NO |
|
|
|
|
| Improved Moderation Tools | NO |
|
|
|
|
| Self-destructing Message Archive | maybe? |
|
|
|
|
| E2EE enforcement Grace Periods | YES |
|
|
|
|
| E2EE enforcement for Direct Messaging | YES |
|
|
|
|
| E2EE enforcement for Chatrooms | YES |
|
|
|
|
| E2EE enforcement for File Uploads[^fc] | NO |
|
|
|
|
| E2EE enforcement for Audio/Video Calls | NO |
|
|
|
|
| Extended Cryptographic [Canaries] | NO[^c] |
|
|
|
|
| Client-side or Encrypted Contact Rosters[^r] | NO |
|
2022-03-27 19:06:36 +00:00
|
|
|
| Automated testing | NO |
|
2022-03-06 18:46:04 +00:00
|
|
|
|
|
|
|
For more information about the protocol-level capabilities of this service,
|
|
|
|
see our entry at [compliance.conversations.im](https://compliance.conversations.im/server/phryk.net/).
|
|
|
|
|
|
|
|
[^fc]: Encrypted uploads are an area of ongoing research in the **XMPP**
|
|
|
|
community, with only one preliminary [XEP] that has limitations
|
|
|
|
and is supposed to be superseded by a well-engineered follow-up.
|
|
|
|
As such, full-fledged official support and enforcement will take
|
|
|
|
a while.
|
|
|
|
|
|
|
|
[^c]: We put a good bunch of work into this, but it's currently just not
|
|
|
|
possible with [GnuPG] because it's a [giant] [garbage] [fire].
|
|
|
|
We're currently waiting for the good folks at [Sequoia] to finish
|
|
|
|
and release the python bindings for sequoia-sop so we can do this
|
|
|
|
in a way that's not complete shit. 🤷
|
|
|
|
|
|
|
|
[^r]: This is not a feature most (if any) non-P2P messaging solutions have
|
|
|
|
and might not be technically possible/viable, but we're planning to
|
|
|
|
look into it anyhow. **XMPP** is already better than Signal in this
|
|
|
|
regard as your JID won't be leaked to everyone in the same chatroom
|
|
|
|
as you.
|
|
|
|
|
|
|
|
[Canaries]: https://en.wikipedia.org/wiki/Warrant_canary
|
|
|
|
[XEP]: https://xmpp.org/extensions/xep-0454.html
|
|
|
|
[GnuPG]: https://en.wikipedia.org/wiki/GNU_Privacy_Guard
|
|
|
|
[giant]: https://mastodon.social/@phryk/107807889352807387
|
|
|
|
[garbage]: https://mastodon.social/@phryk/107866591938927511
|
|
|
|
[fire]: https://github.com/vsajip/python-gnupg/issues/172
|
|
|
|
[Sequoia]: https://sequoia-pgp.org/
|