You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a discussion to gather feedback and ideas from community and experts on end-to-end encryption in Inline.
We'd love to give the users and ourselves peace of mind but there are technical challenges and trade-offs that resulted in not implementing it at this stage.
Currently due to technical limitations, conflict with other core features we have in mind, and our very small team, end-to-end encryption is a non-goal in Inline. If any of the three aforementioned matters change, we'll re-consider.
These are my notes on some of the limitations/challenges:
Bot DX: Implementing bots must be really easy for the community. Is it possible to prevent E2EE from over-complicating this?
Sync: From a UX standpoint, cross-device syncing in Signal seems to be noticable slower than cloud sync in Telegram for example. Is there any research/paper on how to make this fast?
Large communities: Would we need two types of channels so for larger/public communities we switch to a cloud-based method?
AI: More and more users expect their work apps to support AI features such as search, completion, processing, classification, etc. How would this work? Especially for RAG/generating embeddings or captions for images which need to be passively processing messages. Would those users would have to just disable end-to-end encryption? I expect majority of the users wanting such features which would make E2EE mostly pointless at least in channels.
Media and files: This is more a question. I don't have an idea how this could work for a workspace seamlessly while providing E2EE.
Search: Local search is great, and we're implementing it. But users coming from Slack expect instant search from all their devices across the space. From what I understand, we'd have to download the whole space data in the background to enable this.
Alternatives
Only in DMs: This could be a balance between privacy and user experience. But still doesn't solve the whole trust problem.
Self-hostable: If the above concerns become impossible to solve, we could explore making a self-hostable open-source version available instead.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello all,
This is a discussion to gather feedback and ideas from community and experts on end-to-end encryption in Inline.
We'd love to give the users and ourselves peace of mind but there are technical challenges and trade-offs that resulted in not implementing it at this stage.
Currently due to technical limitations, conflict with other core features we have in mind, and our very small team, end-to-end encryption is a non-goal in Inline. If any of the three aforementioned matters change, we'll re-consider.
These are my notes on some of the limitations/challenges:
Alternatives
Beta Was this translation helpful? Give feedback.
All reactions