search

katzenpost / mixnet_uprising

repository for tracking open tasks
18 stars 1 forks source link

XMPPproxy #79

Open moba opened 5 years ago

moba commented 5 years ago

Space to discuss an XMPP proxy, like mailproxy but using XMPP and the "instant messaging" paradigm.

moba commented 5 years ago

Or would IRC actually fit better? Hm. :)

mixmasala commented 5 years ago

Is there a specific client UI you're thinking of adapting? I don't think there's a good reason to make something that speaks XMPP. In particular various client features wont work (file transfer, audio/video) and I can't think of a XMPP client I actually want to use on the desktop :(. Mailproxy is a good PoC but I think we'd rather want to build a fully integrated client for the messaging case.

moba commented 5 years ago

XMPP is pretty much alive, and nothing after it comes even close as an open and extensible protocol. Matrix could be an alternative, but there are even fewer clients for that. File transfer can work, like it works in mailproxy, and its a matter of signaling which XEPs the local proxy server supports. Of course a/v won't work but that's inherent.

The idea would be not to "build a fully integrated client" but instead pick "a messaging protocol translation layer" and allow people to use whatever client they are most comfortable with. I agree that with XMPP there are only very few (if any) good client options but people are using it, especially considering that there are almost no alternatives that use open protocols. And it's not an argument against XMPP because there aren't any other messaging clients that people use and that can be easily adopted to Katzenpost either that convey the provider model (federation).

Yes, if clients want to adopt "native Katzenpost", great. We're not there yet. We can however replace mailproxy with something that much closer resembles the "instant messaging" use case without touching any messaging clients, and without having to lobby some messenger to actually ship with Katzenpost support.

The danger of looking for ONE client to adopt it will be that everyone will think that that one client "is the mixnet client", and it will be hard to make clients interoperable. If we want more than one client, we need to have a "common layer". That layer exists, in the form of XMPP (or Matrix, or even the IRC protocol).

(This could be a project for someone to pick up, e.g. for GSOC; or an idea to pitch to funders.)

david415 commented 5 years ago

it's fine if people want to work on stuff like this but i'm definitely against these kinds of integration plans. maybe i'll change my mind later, unclear. but for now i'm going to advocate for writing a set of protocol libraries that will facilitate integration which incidentally will be of use to you in implementing your plan which i disagree with. and so i will indirectly help you with this even though i'm against it ;) funny how that works eh?