-
moparisthebest
qrpnxz: yes
-
qrpnxz
I am severly confused by s2s comm. After a lot of reading, I think I'm close to understanding. RFC-6120 states that "foregoing considerations imply" that while completing STARTTLS and SASL negotiation two servers would use one TCP connection. Good. Therefore, bidi (XEP-0288) can be agreed upon during this period. The question is then how to do two connections. After negotiating the first connection, am I supposed to end the receiving server's stream, dial the initiator (with the same `id`?? seems illegal), and negotiate that connection, after which the initiator ends their stream on the second connection, and then we can talk to each other?
-
qrpnxz
Because that kind of seems insane.
-
qrpnxz
or i guess that the two streams are supposed to have different IDs and the second stream can reply to <iq/> from the first on the other connection without any problem just by having the id of that request?
-
qrpnxz
ok so it looks like after SASL streams must be restarted. I suppose what you do is that the initiator starts a new stream, but the receiver instead goes and creates the second TCP conn?
-
Zash
When you said bidi I thought of https://xmpp.org/extensions/xep-0288.html where there's no second connection.
-
Zash
In standard xmpp without that, the other server creates their connection back whenever they want, usually when there's a reply or something to deliver. it's completely independent of any prior connection.
-
Zash
Unless you use Dialback, then there's a bunch of connections in every direction and everything is confusing and backwards.
-
qrpnxz
Ok i think it should be as i now understand it then. Good.
-
qrpnxz
Thx
-
Zash
Dialback being https://xmpp.org/extensions/xep-0220.html
-
qrpnxz
dialback looks like something i never wanna implement
-
Sam
We should consider obsoleting dialback again.
-
moparisthebest
Why? DNSSEC adoption keeps going up
-
moparisthebest
And does anyone validate TLS certificates when doing dialback? That seems to work fine
-
qrpnxz
it's the other way around mate, who'd wanna do dialback after validating TLS
-
moparisthebest
I mean when you connect to bob.com's server, you validate it has a valid cert for bob.com before sending anything
-
qrpnxz
Right, with TLS
-
moparisthebest
Yes, dialback is still needed for validation the other direction, to prove to bob.com who you are
-
qrpnxz
That's also with TLS
-
moparisthebest
With sasl external it is, but dialback also works fine in the absence of that I guess
-
qrpnxz
TLS and SASL support is required, and SASL EXTERNAL is also required for servers. So there's just about zero reason to do dialback afaict
-
Zash
There's some servers that run with self-signed certs, some with expired certs...
-
qrpnxz
cron to the rescue
-
MattJ
I would strongly urge anyone implementing s2s today to just not implement dialback
-
mdosch
> There's some servers that run with self-signed certs, some with expired certs... Expired certs are probably just caused by mistakes, but why would you use self signed certs nowadays?
-
qrpnxz
In case the domain is irrelevant.
-
qrpnxz
and you don't need hierarchy
-
mdosch
What do you mean by irrelevant?
-
qrpnxz
not applicable or pertinent
-
mdosch
If you want to do s2s with others I think it's relevant.
-
qrpnxz
yes for s2s it's very relevant
-
qrpnxz
thought you were asking in general
-
qrpnxz
for things using tls
-
mdosch
It was about s2s afaiu.
-
Kev
Dialback’s pretty convenient for testing, mind.
-
qrpnxz
for testing what
-
Kev
For quickly running up a bunch of servers without having to generate a root, trust it in all the configs, issue certs etc.
-
Kev
For testing the server.
-
qrpnxz
sounds like you can also just whitelist these
-
Zash
I found it easier to get certs for my testing servers.
-
flow
plus, at some point you may want to test the code involving certs anyway :)
-
Kev
You *can* do it by generating a CA, committing configs with that trusted and issued certs in etc., but...
-
Kev
flow: Are you genuinely going to suggest that we don’t test our EXTERNAL paths?
-
flow
hehe
-
flow
anyhow, all that talk about dialback being so complex actually makes me want to implement it
-
flow
of course, I first would need to implement an XMPP server
-
flow
not sure if I am up to that challenge, I like my life as client library dev very much
-
Kev
But tests involving TLS are desperately slow, so being able to test with dialback is quite desirable (or you can use null cyphers in TLS or something, but we compile with those disabled).
-
qrpnxz
i want to implement a server and client rn. So far I've not been discouraged. XMPP is rather straightforward for the most part.
-
flow
rn?
-
qrpnxz
right now
-
Kev
So our S2S tests don’t do TLS except those that test TLS.
-
Kev
(Well, our in-process tests. Our integration test suite uses TLS)
-
flow
qrpnxz, implementing client *and* server is a huge task, fwiw
-
qrpnxz
i'm starting with server
-
flow
I was suggesting to start with the client side of things✎ -
flow
I was about to suggest to start with the client side of things ✏
-
flow
but go for it, you can only learn from it
-
qrpnxz
so XMPP: Core AND XMPP: IM AND i have to learn GUI? no way lol
-
qrpnxz
how about just XMPP: Core server and done
-
flow
sure, that's the nice thing about XMPP, you can implement a very basic server
-
qrpnxz
Clients not even required really. You can just make the server if you don't plan on having other users LOL✎ -
qrpnxz
Client's not even required really. You can just make the server if you don't plan on having other users LOL ✏
-
qrpnxz
hmm, i don't see a way to make TLS optional without having a dummy feature...
-
Kev
In what sense?
-
Kev
You just don’t mark it as required.
-
Kev
Or if you mean optional to have configured, rather than optional to negotiate, you don’t advertise when it’s not configured.
-
MattJ
Basic messaging between clients in Prosody was working in just a few days. It's everything after that that's the difficult part :)
-
qrpnxz
> You just don’t mark it as required. Kev: Core says that if it's by itself then it's mandatory by default
-
dwd
flow, I've implemented dialback from scratch once, and fixed it at least twice. Don't recommend... it's simple enough to start with, then gets horrendously complex as you add in TLS, BiDi, etc.
-
MattJ
I also think I discovered a bug in the XEP the other day
-
MattJ
But I haven't reported it because I can't even be sure it's a bug in the XEP, or my understanding of it
-
qrpnxz
dwd, basically anything that touches DNS makes me sad
-
dwd
qrpnxz, Yes, you have to implement, and negotiate, TLS to be standards compliant. But you can deliberately choose not to.
-
dwd
qrpnxz, Actually DNS is the easy bit. Unless you're talking DNSSEC, which then becomes complicated again.
-
qrpnxz
MattJ, i'm writing something about a problem in XEP-0288 as well, but first i'm making sure it's actually a problem and/or proposing solution ;)
-
qrpnxz
dwd, i see, ew
-
dwd
qrpnxz, Especially when deriving candidate subject names.
-
dwd
qrpnxz, And most interested in fixes for XEP-0288, of course.
-
qrpnxz
> implement, and negotiate, TLS to be standards compliant serveral places in the standard hint at situation in which you get to, for example SASL, and tls is not negotiated yet. And indeed if you you have both tls feature and something else, tls is optional.
-
qrpnxz
but i don't see a way to only have tls feature, and have it be optional, yet you have to show tls feature, so... a pickle
-
qrpnxz
well, i do see a way: a dummy feature. But kind of ugly
-
MattJ
If you don't have any other features how is it optional?
-
MattJ
The stream wouldn't be able to proceed
-
dwd
qrpnxz, You just don't advertise TLS, and do advertise SASL.
-
qrpnxz
i just specifically said that if it's the only one std says that it's mandatory by default so idk where you are getting i said that
-
qrpnxz
not advertising tls is not the same as optional tls, also you cannot NOT advertise tls
-
qrpnxz
you must advertize tls if you support it, which you must support because of the std as well
-
MattJ
You're saying you want a scenario where you advertise only TLS, but you want it to be optional
-
dwd
qrpnxz, You really can. You're no longer standards compliant, because we think you should do TLS. But if you have a compelling reason not to be standards compliant, then go for it.
-
qrpnxz
mattj, it's not necessary that i want such a scenario, but that it's kind of ugly the way you have to do it (dummy feature)
-
dwd
qrpnxz, I don't get where you're coming from with this "dummy feature".
-
Kev
It’s not a dummy feature.
-
qrpnxz
if i have tls feature, and another feature that is not tls, and tls does not have <require/>, then tls is optional
-
Kev
It’s an alternative mechanism.
-
qrpnxz
hence if i wanted to make tls optional, and i didn't have a legitimate feature to advertize alongside tls, then i'd have to create a dummy feature that doesn't exist to put along with tls, and then not mask tls as <require/>
-
dwd
qrpnxz, If a server doesn't advertise TLS at all - and structurally, it need not - then a compliant client might refuse to continue. But a client that *also* doesn't mandate TLS (which is most of them with non-default configuration) will happily continue without. If you have an alternate stream encryption (or similar), then a client which understands that might negotiate it in preference to TLS.
-
qrpnxz
A server that doesn't advertize tls is not compliant, to start. A client that does mandate tls simply doesn't use the feature *if it's voluntary-to-negotiate*.✎ -
qrpnxz
A server that doesn't advertize tls is not compliant, to start. A client that doesn't mandate tls simply doesn't use the feature *if it's voluntary-to-negotiate*. ✏
-
dwd
qrpnxz, Have you noted the last bit of https://datatracker.ietf.org/doc/html/rfc6120#section-5.4.1
-
dwd
qrpnxz, So if the server doesn't consider TLS to be mandatory but does support it, just don't include <required/> in the stream feature.
-
qrpnxz
right, that adds to the brainfuck. That means that there should never be the case that TLS is the only feature and it doesn't have <require/>
-
dwd
qrpnxz, I don't understand why this is confusing. And yes, you're right (though <required/> would be redudant in that case).
-
qrpnxz
it's redundant, but it's required. They should have just writ it so that without required it's optional to be consistent
-
dwd
qrpnxz, Well, sure, and it is. But if the only thing the stream is offering is to negotiate TLS, and you choose not to, then you can't do anything else.
-
qrpnxz
it's not optional in that case.
-
dwd
qrpnxz, What difference does it make?
-
flow
MattJ> But I haven't reported it because I can't even be sure it's a bug in the XEP, or my understanding of it
-
flow
standards@ it maybe?
-
dwd
qrpnxz, I mean, sure, if TLS is the only thing offered, it follows that it *is* mandatory to negotiate, and therefore the server MUST include <required/>. But in practice, what cases fail to interoperate if it's not included?
-
Kev
required only really matters so you know why you can’t continue, rather than aiding interop.
-
qrpnxz
none, yet the server is not compliant ;) And if you want to make it optional you have to add a dummy. Not a helpful special case.
-
Zash
I don't understand where you got 'dummy' from?
-
qrpnxz
do you know what a dummy is
-
Zash
Yes.
-
Kev
Because no-one who wants to do tls is going to decide they’re not going to do it because it’s not marked as required. And similarly if it’s required you’re not going to be able to continue without it. It’s just useful for debug when things don’t work.
-
Zash
Maybe the missing piece is that if you are only offered TLS, the only way to not do TLS would be to do Dialback, which is advertised differently because hysterical raisins.
-
qrpnxz
perhaps you missed my message where i explain i copy here: ``` hence if i wanted to make tls optional, and i didn't have a legitimate feature to advertize alongside tls, then i'd have to create a dummy feature that doesn't exist to put along with tls, and then not mark tls as <require/> ```
-
dwd
qrpnxz, Why do you think you need this dummy feature?
-
qrpnxz
you need it to mark tls as optional if tls is the only legitimate feature
-
dwd
qrpnxz, Why do you think that?
-
qrpnxz
because that's what the standard says. If it's on it's own, it's required. Period. So if it's gonna be optional, there needs to be another feature.
-
dwd
qrpnxz, Ah, I see. So you want a client to go straight to SASL?
-
Zash
But how would you SASL without TLS?
-
dwd
qrpnxz, If so... advertise SASL.
-
Zash
And that's where in practice you'd do Dialback.
-
qrpnxz
Not personally, but i'm just saying that's what you'd have to do. You can't advertize SASL before TLS, and you have to advertise TLS
-
dwd
qrpnxz, And why do you think you can't advertise SASL alongside TLS?
-
flow
Why can't I advertize SASL before TLS?
-
qrpnxz
standard says so
-
flow
ref or it didn't say so ;)
-
qrpnxz
i will look :)
-
flow
we should take notes how different people interpret the standard text and see if we can clarify this in a future revision of the text
-
qrpnxz
you are right you can do them at the same time, thought if you didn't do SASL either then you'd need a dummy again✎ -
dwd
qrpnxz, So you want to not do SASL *or* Dialback *or* TLS? What is it that you *do* want to do?
-
qrpnxz
you are right you can do them at the same time, though if you didn't do SASL either then you'd need a dummy again ✏
-
dwd
qrpnxz, And shouldn't you advertise *that*?
-
qrpnxz
I don't want to do anything like I said. Just commenting on the standard.
-
Zash
And then?
-
qrpnxz
one min
-
qrpnxz
and nothing
-
Zash
I'm lost.
-
qrpnxz
how can i help
-
dwd
qrpnxz, So you're saying that a thing you don't want to do can't be done? And this annoys you because?
-
qrpnxz
no, it can be done. Just you have to use a dummy maybe.
-
qrpnxz
the annoying part is that there's an unnecessary special case of tls being required if it's the only thing.
-
qrpnxz
whereas it could just be required if you put <required/>, which you must do if you consider it required anyway
-
flow
I think you maybe reading to much into "TLS required" in the standards text
-
flow
it basically says that an implementation can only claim standards compliance if it implements TLS
-
flow
not that you have to jump through loops in the protocol, not offering TLS is perfectly fine from a protocol perspective
-
qrpnxz
it says a lot of things
-
dwd
qrpnxz, OK. So you want the client to negotiate something which is unadvertised?
-
qrpnxz
no
-
dwd
qrpnxz, So what do you want the client to do?
-
qrpnxz
> not offering TLS is perfectly fine from a protocol perspective no, std requires you offer tls
-
qrpnxz
i don't want the client to do anything dwd
-
dwd
qrpnxz, Then what on earth is the problem?
-
qrpnxz
i've already said to you multiple times idk what you want from me
-
dwd
qrpnxz, Give me an example of the thing you don't want to do but think is impossible.
-
qrpnxz
i already told you multiple times there is no impossible thing
-
dwd
qrpnxz, So why do you thinka dummy feature is needed?
-
flow
maybe slow down a bit and see if we can steer this into a productive and helpful direction
-
qrpnxz
i will tell you one more time: because if it's by itself and it doesn't say required it is still required, if you want to make it not required and there's no other legitimate feature, you must have a dummy feature
-
dwd
qrpnxz, OK. And what would the client do at this point?
-
qrpnxz
if it were optional? idk, w/e the client wanna do, or negotiate a mandatory feature.
-
flow
that would be SASL or dialback at this point, right?
-
qrpnxz
sure, if that were a feature
-
flow
so why not, instead of a dummy feature, announce SASL and/or dialback?
-
dwd
qrpnxz, OK, so there'd be another, non-dummy, feature for it to negotiate then. Where does the dummy feature come in?
-
qrpnxz
yes we already established this is also an option. That's why i said "if there's no other legitimate feature"✎ -
qrpnxz
yes we already established this is also an option. That's why i said *"if there's no other legitimate feature"* ✏
-
flow
ok, we are going circles :)
-
qrpnxz
If there is another feature, then TLS feature comes back to the world of mortals and behaves normally. Only if it would otherwise be the only feature, do you need a dummy to make it optional.✎ -
qrpnxz
If there is another feature, then TLS feature comes back to the world of mortals and behaves normally. Only if it would otherwise be the only feature, then you need a dummy to make it optional. ✏
-
dwd
Why would it be the only feature?
-
dwd
Because if you want the client to do "something else", then the server needs to advertise the feature is available at that point.
-
qrpnxz
it's almost always the only feature. I don't know all the XEPs though.
-
qrpnxz
the dummy is not for when you want to do something else, it's for when you want to do nothing.
-
MattJ
If you want to do nothing the stream can't proceed, that's the point
-
qrpnxz
it can if it's optional
-
MattJ
It can't, there's nothing else to do
-
qrpnxz
there is, if they are optional it's stanza time
-
dwd
MattJ, Maybe it's the equivalent of just holding hands.
-
MattJ
It's not stanza time until it's authenticated, which requires SASL
-
MattJ
(let's put dialback aside...)
-
qrpnxz
sasl is not required afaict
-
MattJ
You can't send stanzas without authentication
-
qrpnxz
but if it is then you put sasl next to tls, which like i said, is ofc not a situation in which you need the dummy
-
dwd
qrpnxz, RFC 6120 says SASL is both required and mandatory-to-negotiate.
-
qrpnxz
required to support, and mandatory-to-negotiate when advertized
-
Zash
It is a bit awkward that there's no explicit "you're done, feel free to send stanzas now"
-
Zash
Also awkward that an empty `<stream:features/>` means exactly that...
-
dwd
Zash, Well, for C2S you could advertise <bind/>.
-
qrpnxz
if all features are optional and there's nothing you want to negotiate, you just go ahead. I think it's for the best. Saves a message
-
Zash
dwd, thought we were mostly discussing s2s
-
Zash
but yeah
-
dwd
But there *is* XEP-0361 for the oddball cases where you need that.
-
qrpnxz
nice
-
qrpnxz
it's def expensive to start xmpp conn with all those stream restarts and feature lists
-
qrpnxz
for contrained environments. Desktops no problem ofc
-
flow
that negotiation ping-pong is also old-fashioned when it comes to protocol design. these days you want to just send all the stuff you want to do in a single step, e.g. bind2
-
flow
but I guess the negotation ping-pong is less of an issue in s2s
-
Kev
Depends on the environment. But yes, generally.
-
qrpnxz
On a related note, I may have found a problem in XEP-0288. XMPP: Core states: ``` A <features/> element that contains both mandatory-to-negotiate and voluntary-to-negotiate features indicates that the negotiation is not complete but that the initiating entity MAY complete the voluntary- to-negotiate feature(s) before it attempts to negotiate the mandatory-to-negotiate feature(s). ``` However, XEP-0288 states: ``` If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). [...] If the initiating entity chooses to use TLS, STARTTLS negotiation MUST be completed before enabling bidirectionality. ``` Now consider I serve the following: ``` <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <required/> </starttls> <bidi xmlns='urn:xmpp:features:bidi'/> </stream:features> ``` Core says that I MAY negotiate bidi first, but 0288 says that I MUST do STARTTLS first. 0288 should allow you to enable bidi before TLS to defuse this situation. I can't think of why that should be disallowed.
-
Kev
Central to a lot of how XEPs work is that any behaviour can be overriden by negotiation.✎ -
Kev
Central to a lot of how XEPs work is that any behaviour can be overridden by negotiation. ✏
-
Kev
So if core says something and 288 says “But when doing 288 you should do this instead”, that is fine.
-
Kev
E.g. core says “There’s just <message/> <presence/> and <iq/>” and 198 says “but if you’re doing 198 there’s <a/> and <r/> too”, and that’s fine.
-
dwd
What Kev says, but also bidi is predicated on mutual authentication, so it'd be a bit weird to negotiate that before you decide if the other side is who it says it is.
-
qrpnxz
I see yeah cool np
-
dwd
But maybe weird is OK.
-
qrpnxz
i don't see how bidi is predicated on authentication, it just means says "dont' bother with another conn"
-
qrpnxz
in fact, it's perfectly ok to do bidi but not TLS in the XEP
-
dwd
Sending stanzas in general is predicated on mutual authentication. Even XEP-0361 uses out of band authentication.
-
Kev
And if you do TLS, pre-TLS state is tainted.
-
Kev
So you couldn’t negotiate bidi before doing TLS and continue using it afterwards.
-
dwd
Kev, That's a good point.
-
qrpnxz
i don't see such predicate in 0361, it merely recommends it
-
Kev
361 definitely only works bilaterally :)
-
qrpnxz
oh i think ik what you are talking about kev, gonna look up the quote in the std
-
qrpnxz
here: ``` The initiating entity MUST discard any information transmitted in layers above TCP that it obtained from the receiving entity in an insecure manner before TLS took effect (e.g., the receiving entity's 'from' address or the stream ID and stream features received from the receiving entity). ```
-
qrpnxz
bidi would be such an information
-
qrpnxz
therefore if you do bidi first, no more tls
-
Zash
You'd get another set of stream features after TLS and the stream restart
-
qrpnxz
and contraversly, if you do tls, it must be first
-
qrpnxz
right
-
qrpnxz
*contrapositively lol
-
dwd
However, you may have a point - it's useful for the receiving entity to know if bidi is intended as early as possible, ebcause otherwise it'll start to open connections. (Or might do; Metre certainly will).
-
Zash
I think in Prosody bidi is not even advertised until after TLS and certificates have been verified and such
-
qrpnxz
0288 doesn't require it do advertise before tls, only recommends it
-
Kev
dwd: But if you’re making such decisions, they have to be reversible, right?
-
Kev
Because the bidi before TLS is tainted.
-
dwd
Kev, Yes, but you could at least hold off on opening return sessions.
-
Kev
Although I’m not sure what decision you’d make based on an *outbound* session having bidi advertised.
-
qrpnxz
but you really gotta do it before sasl, because after sasl it's assumed you aren't gonna send anything else on that conn
-
Kev
As on an outgoing session it’s the other end that can elide the second stream because of bidi, not you.
-
Zash
What's all this about opening return sessions early?
-
Zash
That sounds like a Dialback thing
-
qrpnxz
uhh, not sure
-
dwd
Zash, It's a non-bidi-thing.
-
Zash
Hm, without dialback, something to verify that bidirectional connectivity is possible would be good...
-
qrpnxz
that's what XEP-0288 does
-
Zash
One-way s2s is a bit annoying when it happens
-
dwd
Kev, Yes. So, you're a server. You get an inbound session claiming to be from example.org. You're advertising bidi. Until the inbound session has negotiated bidi, then you can save some time by initiating an outbound session to example,org. This is safe (in terms of auth, etc) even if the inbound session cannot authenticate.
-
Zash
XEP-0288 isn't all that widely deployed
-
dwd
Kev, But, if the inbound session then negotiates bidi, it was a waste of effort.
-
qrpnxz
no way i personally waste time on outbound connection before auth, and bidi has to happen before auth, so problem solved for me lol
-
Kev
dwd: Yes, but I don’t know what advertising bidi does here. Because it’s you that’s advertising it on the inbound session, so you don’t know if the other end is going to use it later to determine whether to open the return session or not.
-
dwd
Kev, Right, because we don't negotiate until later. If, as qrpnxz says, we negotiate early, then this changes.
-
dwd
Kev, Even if we'd *later* have to renegotiate...
-
dwd
qrpnxz, It's very rarely a waste of time, and often makes things significantly faster to get to stanza exchange.
-
qrpnxz
if you advertise bidi with tls, you can do bidi and no tls (unless TLS is required, then you must do TLS first). If you advertise bidi with SASL, then you can enable bidi, and after SASL you will have a bidi connection. Or if you don't enable it and then do SASL, then it's one way
-
qrpnxz
dwd, yeah it's a tradeoff of waste of resources on non-auth and time save for successful auth. I choose not letting people waste my time without auth every time tho
-
moparisthebest
.onion domains are a widely deployed reason to still support dialback I think
-
MattJ
Prosody's mod_onions just accepts any *.onion certificate
-
qrpnxz
onion does touch dns though, and i cant think of you you wouldmt trust that conn
-
qrpnxz
*doesn't
-
qrpnxz
jesus i rly messed up that msg
-
qrpnxz
h8 typing on phone
-
qrpnxz
ok on computer now. Onion addr is based on pub key crypto iirc, so if you connected to it, I think you are fine, but not sure tbh will have to look into it.
-
qrpnxz
rly need to go to bed rn tho
-
moparisthebest
qrpnxz, right, but then how do you validate the connection coming *from* something claiming to be a .onion ?
-
moparisthebest
MattJ, wait for incoming SASL auth too? or how do you validate incoming .onion streams ?
-
Zash
It accepts any certificate, in that it doesn't reject them. But it doesn't use certs for authentication either. Still need to do Dialback.
-
moparisthebest
ah ok, good
-
moparisthebest
I suppose the dreaded "raw IP" requires dialback too
-
Zash
You can get certs for IP addresses actually...
-
Zash
Prosody can't federate with bare IPs tho, so glhf
-
Zash
(depending on version and whether it's the future yet)
-
Kev
It wasn’t then, but it is now.
-
Zash
IP address SAN is newer than XMPP?
-
dwd
The SAN existed, it's part of X.509v3, IIRC. But whether any CA would sign such a cert is another matter.
-
Zash
Will any now?
-
Zash
https://1.1.1.1 has one
-
dwd
I have this vision of you deciding to work through all the IP addresses and being lucky the first one hit.
-
eta
please federate with 2a0d:1a40:7553:beef:5054:ff:fe62:dd16, kthxbai
-
Zash
Next up, can haz raw public keys?
-
Zash
Raw all the things
-
Zash
And like ... in-addr.arpa DANE something something
-
dwd
I'd never suggest "raw public keys", because the logistics are a pain, but Metre does allow preconfigured self-signed certs.
-
eta
also see https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/JFwqZx7RLL0
-
Zash
DANE + raw public keys would be nice tho
-
Chan Shen
is it possible to add voice chat to xmpp ??
-
Zash
Yes, commonly called Jingle
-
Zash
https://xmpp.org/uses/webrtc.html might be enlightening
-
Zash
or https://xmpp.org/about/technology-overview.html#jingle
-
Zash
or both
-
Chan Shen
>Yes, commonly called Jingle is it something like group chat of telegram ??✎ -
Chan Shen
>Yes, commonly called Jingle is it something like group voice chat of telegram ?? ✏
-
Zash
Never used Telegram, can't answer that.
-
Chan Shen
>Never used Telegram, can't answer that. i mean is it possible to have a voice chat (up to 100 person) with group members in xmpp ?
-
Zash
Daniel, distinct lack of mention of calls on https://conversations.im/ 🙂
-
Zash
Mostly 1-to-1 calls at this time, altho things like Jitsi Meet does video conferencing with some XMPP behind the scenes.
-
Chan Shen
i think it is called multiparty jingle (muji). https://xmpp.org/extensions/xep-0272.html
-
jonas’
https://github.com/xsf/xeps/pull/1059 flow, don’t you think this has privacy implications?
-
flow
jonas’, well yes, I still would recommend that. that said, if someoe would write a disclaimer, then this would be fine by me
-
dwd
Chan Shen, Unfortunately the Jitsi Meet people haven't put their solution through standardisation, which is a shame. I should have a chat with Emil and co about that. But there are a number of solutions for video conferencing based on XMPP as the signalling layer, including Jitsi Meet, and also Zoom and possibly still Google Meet.
-
Chan Shen
> dwd wrote: > Chan Shen, Unfortunately the Jitsi Meet people haven't put their solution through standardisation, which is a shame. I should have a chat with Emil and co about that. But there are a number of solutions for video conferencing based on XMPP as the signalling layer, including Jitsi Meet, and also Zoom and possibly still Google Meet. Jitsi is the best choice for me right now , i dont like Telegram nor Google Meet.
-
dwd
Chan Shen, There is also Openfire Meetings and Padmé as well, on the open source front, but I don't know how well those scale.
-
dwd
Chan Shen, You did stipulate voice only - most recent work has been around video, which may or may not mean some interesting large-scale voice stuff has gone unnoticed by me.
-
Zash
Does anyone know any details about how Mumble works?
-
moparisthebest
also https://bigbluebutton.org/ which I don't think is XMPP but at least open source and supposedly works pretty well
-
dwd
Zash, Oh, yeah, Mumble.
-
jonas’
Zash, barely
-
dwd
Zash, Voice go in one end. Voice come out the other.
-
jonas’
with mixing on the server
-
jonas’
I think anyway
-
Chan Shen
I just dont like facebook , whatsapp , telegram. I tried to invite my friends to xmpp & matrix , but they say telegram is 100% secure and its features are not implemented in other IM apps.
-
emus
Hello everyone, as I just wrote an email to members@ - I would also point you from here to the work I am doing here: https://github.com/xsf/xmpp.org/issues/920 It is an overview of the XSF, its organization and resources, as a organizational chart or organigram. I am convinced this can be a really helpful tool for overview purposes, especially to newcomers or people who are interested in the XSF and XMPP. Let me know you feedback and if you think something is missing! @board, @council (just imaging I ping you guys 😛)
-
wgreenhouse
what is the software behind logs.xmpp.org?
-
menel
I think this: https://modules.prosody.im/mod_http_muc_log.html
-
wgreenhouse
menel: looks like it, thank you