XSF Discussion - 2018-12-28

Do you really need to encode the protocol in the user part, or would it suffice to have a domain per protocol (making it something like @jid:xmpp.matrix.org)

note that : is not valid in the domain part... i think i complained in 2004.

fippo: this is about the matrix side of things. Not that I knew anything about that...

if matrix has not learned the lesson to include a protocol prefix then...

fippo: My advice to you is to close your eyes and back away

which lesson

?

That URLs/URIs are good

And namespaces in general

fippo, are you takling about XMPP? : is valid in the JID domain part

doh. i meant the node part -- which means you can't have scheme:user@host

that’s a good thing if you want to use it for something else though

> <@_xmpp_xmpp-js_xsf=40muc.xmpp.org=2fGe0rG:matrix.org> Do you really need to encode the protocol in the user part, or would it suffice to have a domain per protocol (making it something like @jid:xmpp.matrix.org) yeah, @jid:xmpp.matrix.org would work better (but mean we’d have to run a seperate vhost per bridge, but that’s not a bad thing)

that looks great

Also that quoting format... 😱

Oh yes, the fallback reply format on Matrix isn't great. The bridge is quite young, and doesn't really do formatting just yet.

35c3.de.half-shot: are you aware of the xmpp assembly? I'm sure you can find some folks glad to help out. I've even heard that iNPUTmice from conversations committed to work on a bridge to matrix (under the condition that the protocol stabilizes), so it might be good to bundle efforts

I went to help a bit already with the setup

I'll go say hi again today probably

pep.: awesome!

Yep :) can have a chat.

And actually pep. got the bridge going in the first place :D

(well, pointed us in the right direction for prosody)

I'd love to have a first class bridge running, with support for all the nice xmpp features.

So yes, Matthew is probably your guy to talk to on protocol stabilization although we are commited to getting a 1.0 out the door within the next couple of months iirc.

And our full intention is to make a 100% feature compatible bridge where possible.

Most modern features should be covered by XEPs already, but we probably need Carbons from the component domain for the parallel use of native clients ✏

Tbh I am not really fond of xmpp.js and manual xml writing, but I we'll see where that leads the bridge

-I

pep.: I think the important thing is to have somebody with a long term commitment to maintain it

Also, yes I'd like to have a chat about carbons and resources because it's a bit alien from my pov.

35c3.de.half-shot: I'm not there, and my time is unfortunately very limited, but feel free to ask here

35c3.de.half-shot: think of a resource as a semi stable client Identifier. They are mostly opaque, but sometimes contain a client name. Ideally, each client installation should have a unique one that's persistent, but some implementations have other ideas

35c3.de.half-shot: for message routing, you should always send to the bare JID (no resource), and have the server figure out everything

Ah okay, like "half-shot@half-shot.uk/MyPhone". I know that gajim tends to make one like "gajim.sdjgjw" unless you force it :/

(except for MUCs, there everything is different)

35c3.de.half-shot: exactly. The problem with "MyPhone" is when you get a second phone and both try to use the same

I see :)

This sounds analogous to matrix device ids. Interesting.

I have a feeling that matrix ends up reinventing most of the things xmpp handled a decade ago 😉

Great to see a colaboration!

> Great to see a colaboration! Exactly!

the bridged users are gone.

yeah, membership syncing isn’t hooked up yet