Re: Thoughs about communication

On 27/01/2017 14:56, Alexandre Franke wrote:
On Fri, Jan 27, 2017 at 12:03 PM, Matthew Hodgson
<matthew matrix org> wrote:
There may be some confusion here about the dynamics of Matrix
bridging. In practice, when bridging to IRC, Matrix just acts as a
big decentralised IRC bouncer. It connects on a per-network, not a
per-channel basis, and the Matrix users who pop up on IRC look and
feel like a normal IRC client connection... because they are. It
just happens to be that the client is running on a Matrix/IRC
bridge and syncing that user's history into Matrix for them.

One can lock a bridge to a particular channel, but generally that's
missing the point.

That raises the following concern: we have some channels which are
semi-private. They are commonly used by well defined groups for
sensitive conversation (that part I assume is not a problem as you
could have an invitation only room or a similar protection) but from
time to time people are temporarily invited to join those rooms to
discuss a particular topic. In such a case, sending the guest any
history is not desirable. Can Matrix handle this situation?

Yes, it can. This (and related problems) are very common, and there are various ways to address them:

* You can configure the history visibility of the room so that it's not visible to newcomers. This tends to be the default for IRC-bridged rooms, given it's the expected semantics for IRC (unless the room's charter explicitly allows public logging). * If you're worried about conversation being visible to sysadmins, you can E2E encrypt it (which for now also prevents history being shared with newcomers, and lets users cherry-pick precisely who can decrypt their messages) * You can also run the bridge on your own server, and as long as the participating users are also local to that server, the history will never leave. * For super-private rooms, you can deliberately disable federation to lock them to the server they were created on, to stop history or conversation ever leaking elsewhere.

That said, there's still a lot of work to be done on ACLs - we're currently implementing group ACLs (really useful for auto-inviting a team into a room, etc), and there's a long-standing bug that you can't retrospectively change ACLs; they only apply from the current point in time. Fixing this is a relatively hard problem due to the decentralised/byzantine nature of Matrix, but we're working on it :)


Matthew Hodgson

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]