Re: Thoughs about communication

[Matthew Hodgson <matthew matrix org>]

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 :)

M


--
Matthew Hodgson
Matrix.org