[Standards] Requirements for "Jid Hidden" Channels

Matthew Wild mwild1 at gmail.com
Sat Jun 2 23:07:43 UTC 2018


On 2 June 2018 at 22:08, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2018-06-02 19:17 GMT+02:00 Sam Whited <sam at samwhited.com>:
>> On Sat, Jun 2, 2018, at 11:36, Steve Kille wrote:
>>> It was agreed clearly that we need JID Hidden, primarily to prevent JID
>>> Harvesting.   This is going to be useful for public and semi-public
>>> channels.
>>
>> I've mostly been avoiding the MIX discussion because in its current form I belive that it is too complex to ever gain wide adoption and as far as I can tell this is the root cause of that.
>> For the level of complexity they introduce I don't think JID hidden channels are worth it.
>> We can always explore other mechanisms later, and maybe come up with a more general anonymity protocol that works for direct communication and group chats (eg. by making burner JIDs or some alternative work for the MIX use case) and doesn't require making MIX unnecessarily complicated.
>
> sorry I’m very busy these days and haven’t followed the wider MIX
> discussion a lot but I mostly agree with Sam here
>
> in that
>
> a) public, anonymous rooms should not be a priority for MIX
> b) if hiding JIDs adds a lot of complexity to MIX it should be avoided
> c) anonymity / proxy jids can be added as an afterthought and might
> actually be useful outside MIX as well and thus should probably be in
> a separate XEP (I had be contemplating the idea of a dezentralized
> push alternative that would benefit from proxy jids as well because
> you don’t want to leak your real jid to the app server)
> d) MUC wont go away any time soon. So people who want to keep their
> anonymity and their complicated IRC-like access model will still be
> able to use MUC. So in theory you could keep MUC around for the public
> groups chats and have MIX be optimized for the WhatsApp like groups

I have to say I agree with all the points Daniel makes. In my mind MIX
does not need to solve all the use cases that MUC currently handles
well. I think we're all in agreement that this is a complex problem
we're trying to solve, and it's apparent that some of MUC's perceived
weaknesses were probably actually hard to avoid in the first place.

In tackling complex problems, I think limiting the scope works
wonders. If we can do away with proxy JIDs, that would be a big win
for making a simpler modern replacement for MUC.

By the way, I really appreciate the effort that went into splitting
MIX recently. I think that has helped to divide up the issues at hand
and enable the discussions over the past few days.

Regards,
Matthew


More information about the Standards mailing list