XSF Discussion - 2014-01-16

  1. Steffen Larsen

    hey Guys. Just want to hear if its ok to book a hotel room for one of my friends though the discount?.. Do we have enough for everybody then?

  2. Kev

    If they're attending the summit I don't see why not.

  3. Kev

    If they're not, it seems more dodgy.

  4. Steffen Larsen

    he is not XSF.. and cant make it to the summit. He'll be there for FOSDEM

  5. Steffen Larsen

    Kev: thats alright

  6. Steffen Larsen

    Kev: No problem

  7. Kev

    I didn't give an answer.

  8. Steffen Larsen

    Ohh I thought you said it was dodgy

  9. Kev

    I'd see what Dave/Ralph say :)

  10. Steffen Larsen

    what that ever means

  11. Kev


  12. Steffen Larsen


  13. Steffen Larsen


  14. Steffen Larsen

    just wanted to hear your oppion

  15. Kev

    I think there are people going just for the summit, so in practical terms if he's going just for FOSDEM, it sounds like there should be rooms.

  16. Steffen Larsen

    Kev: so its ok to give him them link?

  17. Kev

    See what Dave/Ralph think.

  18. Kev

    I have no authority here :)

  19. Steffen Larsen

    Kev: Thanks!

  20. dwd

    Steffen Larsen, I'm not against using our discount for people not attending the summit, if they're XMPP related folk. If they aren't at all, then I don't mind them using the discount *later* - after most people are booked.

  21. Steffen Larsen

    dwd: ok thats all fair.

  22. dwd

    http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-encrypt-your-im/ anyone?

  23. Steffen Larsen

    dwd: The guys is a sysadm. - one of my friends.. not directly XMPP related. So I guess I wait untill all have booked

  24. Steffen Larsen

    dwd: Dave, how do we/I know when all people have booked?

  25. dwd

    Steffen Larsen, We don't. :-) Florian can watch the numbers though.

  26. Steffen Larsen

    dwd: ohhh..

  27. dwd

    Steffen Larsen, Using the entire block is actually a good thing; gives us more bargaining power next year.

  28. Steffen Larsen

    dwd: true true

  29. dwd

    Steffen Larsen, And of course it doesn't cost the XSF anything.

  30. Steffen Larsen

    dwd: even better

  31. Steffen Larsen

    dwd: BTW what did we agree about the dinner? was it saturday or?

  32. dwd

    Saturday, usual place and rules.

  33. ralphm

    Steffen Larsen: you mean you don't read the logs here?

  34. dwd

    So XSF Members and XSF Dinner sponsors only.

  35. Steffen Larsen


  36. Steffen Larsen

    ralphm: sorry no

  37. Steffen Larsen

    dwd: yes i know

  38. simon


  39. simon


  40. intosi

    dwd: keep calm and order those shirts ;)

  41. ralphm

    keep calm and federate?

  42. ralphm


  43. dwd

    ralphm, Yeah, it's not quite right, I agree.

  44. ralphm


  45. ralphm

    (I'm spending too much time in inkscape these days, it seems)

  46. dwd

    Keep Calm and Use XMPP might work better with the lightbulb. (Or Use Jabber, mind)

  47. dwd


  48. Kev

    Just to check, we don't feel that Keep Calm And... has been overdone as a meme, do we?

  49. dwd

    I want to play the security card a lot, because this seems to be the right bandwagon to jump on (and we have a legitimate claim to a seat on this bandwagon)

  50. Kev

    I keep having ideas like "Let's chat about trusting servers" pop into my head, but I don't think they really tell the story.

  51. dwd

    "Trust your provider. Host IM yourself." or something?

  52. Kev

    I'm thinking along those lines.

  53. Kev

    Or "Keep Jabbering with those you trust" or ... something.

  54. dwd

    Kev, I think, BTW, that the meme has been so overdone it's almost meta.

  55. Steffen Larsen

    "Talk about federated security"..

  56. intosi

    In TLS we trust

  57. Steffen Larsen

    ha ha

  58. ralphm

    dwd: I do think that ... and encrypt your IM works for FOSDEM

  59. dwd

    I'm reminded about that quote of Woddy Allen's quote about masturbation - "Don't knock it, it's sex with someone you really love."

  60. Kev


  61. Kev

    "We trust in the Federation"

  62. Kev

    I've made myself giggle :)

  63. ralphm

    but people might think that we mean e2e

  64. intosi

    dwd: classic Woody

  65. Kev

    Why does no-one like my Star Trek joke? I don't believe for a moment that you're not sufficiently nerdy :p

  66. dwd

    Kev, Other than I did "Federation: Not just for Star Trek" a year or two back?

  67. ralphm


  68. Kev

    dwd: I don't remember that at all.

  69. ralphm

    I do

  70. dwd

    My wife is suggesting singing "I'm XMPPY, I'm XMPPY, I know I am - I'm sure I am - I'm XMPPY!"

  71. ralphm

    I'd be happy to reserve a slot for her at the Lounge.

  72. ralphm

    Live entertainment is something we didn't do much about, still

  73. dwd

    (She also suggests a school choir singing it. Obviously well in-tune with current tech thinking)

  74. Steffen Larsen

    wow that could be cool

  75. ralphm

    Perfect. Let me know which day/time.

  76. Ash

    Just thinking about the encryption stuff - I think we need to be a little careful with the message as there may be a number of people (especially hardcore techies) in the 'you mean you weren't already?' camp.

  77. MattJ


  78. MattJ

    That has crossed my mind a few times, but actually I haven't seen anyone react that way yet

  79. Ash

    I think it's just something to be sensitive to

  80. MattJ

    After all, the web is far less encrypted than XMPP is

  81. Ash


  82. intosi

    As is email.

  83. Ash

    We just need to make sure the message is positive

  84. simon

    and in the background get our house in order.

  85. dwd

    Ash, I think we need to ensure we're being honest, open, and seeking improvement.

  86. winfried

    And the message is: "we are raising the bar even further and making sure it works" ;-)

  87. simon

    basically it comes down to good configuration (not lazy about certs / DNS etc) rather than something inherently wrong with XMPP's core design.

  88. Ash

    dwd: I'm not saying we shouldn't be honest, but we just need to make sure the message has the right spin on it.

  89. simon

    and keep pointing people to xmpp.net to test their sit.

  90. simon


  91. Ash

    simon and winfried: definitely :)

  92. dwd

    simon, RIght. We can discuss how we've held strong-auth interop tests (including CRLs etc) several years back; it's now a case of ensuring deployment, not even implementation.

  93. dwd makes mental note to ensure the XSF's interop work a couple of years back gets noted in PSA's STRINT draft.

  94. Ash

    Definitely. I was just worried that people might hear the message as 'we're starting to encrypt communications' rather than 'we're phasing out unencrypted communications'.

  95. winfried

    @Ash: it more like: "We are phasing out all but the most secure configurations" ;-)

  96. Ash

    even better!

  97. fippo

    winfried: well, we're not able to enforce authentication... so i don't think saying this is a good idea

  98. simon

    Geez - winifried is an excellent marketer. I'm nominating him to write xmpp.org content.

  99. ralphm

    simon: who are you?

  100. simon

    ralphm - I believe we've met at the odd XMPP event before.

  101. ralphm

    How can I be sure it's you?

  102. intosi

    Because Simon says… he's Simon.

  103. intosi

    That's how you play the game.

  104. simon

    until xmpp.org does cert verification or DANE, you can't.

  105. dwd

    simon, That won't help.

  106. ralphm

    simon: using anonymous.jabbix.com is the other extreme, though

  107. simon

    short of using corkscrew and some socks5 tunneling, I'm behind a crappy corp fw.

  108. dwd

    simon, That's what 3G is for. :-)

  109. simon

    what's the preferred XMPP client on android these days?

  110. dwd

    xabber doesn't work on newish Prosody, but jTalk might be OK.

  111. ralphm

    I want to say Xabber, but I can't use it

  112. MattJ

    Yaxim, but it doesn't do MUC yet

  113. MattJ

    dwd, it doesn't? Why?

  114. dwd

    MattJ, Because it breaks.

  115. ralphm

    (because it has some issues and development seems stalled or at least invisible)

  116. MattJ

    Yaxim is actively developed, supports XEP-0198 and Carbons

  117. ralphm


  118. MattJ

    Completely open-source, and MUC is coming soon

  119. MattJ

    ralphm, nice

  120. MattJ

    it doesn't work on "newish Prosody"? I don't think we've ever had a release that would accept unescaped ampersands...

  121. ralphm

    MattJ: I don't think this particular bug is something related to Prosody at all

  122. ralphm

    MattJ: I did a c2s tcpdump for it, and decoded it with my server's key

  123. MattJ


  124. winfried

    fippo, you are right, we can't centrally 'phase out' anything in the XMPP network, but the current campaign is as close as we can get

  125. ralphm

    I suppose in the future you can't do that anymore, right?

  126. ralphm

    In any case, I would not go as far as calling XMPP secure, as it has many facets

  127. winfried

    :-) temporally disable FS

  128. ralphm

    winfried: I assume in the future, clients will require that?

  129. winfried

    point taken

  130. Ash

    I though the idea was to create a 'jabber' network of public xmpp servers which enforced encryption. i.e. you can run an xmpp server and do whatever you like, but to interface with the 'jabber' network you need to enforce encryption rules. Although I may have missed a whole bunch of discussion somewhere.

  131. simon

    phasing out is perhaps the wrong way to view it. But being able to connect to some servers will mean you need to get your own server configured correctly.

  132. ralphm

    so anyway, besides heckling simon a bit, I agree with Ash' earlier point

  133. simon

    buddycloud.org /com already reject servers with invalid certs.

  134. ralphm

    simon: and without encryption, too?

  135. simon

    :) no - all s2s is encrypted.

  136. ralphm

    so you can't use your imaginator.com address

  137. simon

    that's still google :) but the new buddycloud server uses DNS discovery so you can run one alongside a google apps domain #thanks-lloyd.

  138. ralphm

    simon: yeah, I knew that the domain was with Google

  139. ralphm

    simon: what, you mean you have two different servers listening for the same domain and you use some DNS trickery to make buddycloud choose the non-google one?

  140. Ash

    Buddycloud is magic!

  141. ralphm

    magic is cool, but I hope I misunderstood

  142. fippo

    there is a difference between encryption and authenticated encryption in terms a what attacks it protects you against

  143. dwd

    To be fair, BTNS mitigates a set of attacks that are a proper subset of those mitigated by authenticated encryption.

  144. Lloyd

    ralphm: buddycloud server still does disco lookups, but if there's a specific SRV record it'll use the result of that to direct it to the other server. No magic - magic sucks.

  145. ralphm

    It still seems a bad idea to have two different servers at the same address

  146. ralphm

    I.e. if this is a special case for servers that are not up-to-spec (like Google's), I don't like it at all

  147. ralphm

    If I misunderstood, please elaborate, though.

  148. dwd

    It suggests there's no commonality between a buddycloud server and an XMPP server, at least.

  149. Lloyd

    Its a special case for people who can't install a buddycloud component on their xmpp setup

  150. Lloyd

    so we run another xmpp server with the buddycloud component connected and use that

  151. ralphm

    Lloyd: While I admire that stand point, it seems to me that this solution breaks the network.

  152. simon

    how does it break the network?

  153. ralphm

    By connecting to other servers based on something outside of the XMPP realm itself

  154. dwd

    simon, You're offering XMPP based services using a protocol that's no longer interoperable with XMPP?

  155. simon

    Using XMPP to exchange data between components is breaking network? I must have misread a XEP somewhere.

  156. dwd

    simon, Well, it sort of depends on whether you're thinking that introducing a new SRV records etc is actually still XMPP. An unmodified XMPP server wouldn't connect, right?

  157. Lloyd

    The server isn't modified at all. I think maybe something has been lost in the text description.

  158. MattJ

    What does the SRV lookup?

  159. MattJ

    (for the buddycloud discovery)

  160. Lloyd

    the buddycloud component. It still uses DISCO however.

  161. Lloyd

    Yes exactly

  162. ralphm

    So when is the SRV thing happening and why?

  163. intosi

    And what will it actually try to resolve?

  164. Lloyd

    If I do disco against imaginator.com and see there's no buddycloud component I do an SRV record check which tells me that there's a buddycloud component sitting at channels.imaginator.com and to talk to that.

  165. simon

    buddycloud runs as a component and components talk to eachother using XMPP. buddycloud components can optionally fall back to using a SRV lookup in the case of a domain not running their own XMPP server.

  166. ralphm

    As I said, I want to be wrong about this and would be happy if buddycloud is pure XMPP

  167. Lloyd

    channels.imaginator.com is still running as a component on an xmpp server.

  168. Kev

    Lloyd: So what you're actually saying isn't anything about SRV. Just that even if there's no advertised service, it'll try to connect on a default domain as if it had been advertised?

  169. ralphm

    So it is really a fallback on channels.domain

  170. simon

    IMHO, the notion that I have to do everything to do with one domain through one server is a wrong assumption. Far better to use DNS delegate services for domains than bottleneck everything through a single server (or cluster).

  171. Lloyd

    ralphm yes, disco+ so to speak (probably a *really* bad term)

  172. Kev

    simon: There's nothing that suggests that you should be using one server for everything.

  173. Lloyd

    kev it'll try and connect on domain anyway, if no advertised service will see if there's a DNS hint.

  174. ralphm

    simon: you may disagree and actually implement things in the background, but just doing something else entirely protocol-wise doesn't seem proper

  175. Lloyd

    if there's no dns hint, well other service doesn't run buddycloud :)

  176. simon

    Kev: my understanding too.

  177. Kev

    blah.doomsong.co.uk could be on the moon, and have no link to doomsong.co.uk other than S2S.

  178. ralphm

    I understand that you have to work around servers (like Google's) that you can insert disco records on

  179. simon

    Ralphm: not sure I really understand your concern.

  180. Kev

    simon: Because you're making something simple sound like you're re-inventing the wheel.

  181. ralphm

    simon: well, the description of what was happening initially sounded really horrible

  182. Kev

    If you said "If there isn't a service in disco for the domain, we'll try channels.domain anyway" it would be much less scary.

  183. ralphm

    simon: now I understand better I'm milder in my judgement

  184. Kev

    Misleading is the enemy of good, and all that.

  185. simon

    Don't think I claimed that this was rocket science. Just a nice way to host instances outside of their XMPP domain.

  186. Lloyd

    *ahem* "maybe something has been lost in the text description" …. or gained as the case may be :)

  187. ralphm

    simon: arguably, nothing in XMPP is rocket science. But I dread having incompatible systems referred to as XMPP

  188. ralphm

    like, say, whatsapp

  189. MattJ

    ralphm, I think by your definition, if you haven't been following Buddycloud, it took that route long ago

  190. MattJ

    It uses XMPP purely as a transport mechanism nowadays

  191. ralphm

    MattJ: I haven't followed it closely, true, and I knew there was a mechanism for finding servers if you're on a hosted service, but the description of doing something else because of a special SRV record sounded really bad

  192. ralphm

    MattJ: turns out it has nothing to do with SRV in principle

  193. simon

    ralphm: bc is designed to run as a component on any XMPP server that understands 114. Finding other servers can be done using disco for the corresponding remote component. This DNS discovery is used in the situation that there isn't a buddycloud component discovered.

  194. ralphm

    isn't that what I said?

  195. ralphm

    the initial explanation was worse

  196. ralphm

    and also, what if there is no SRV record for channels.domain but there's a server listening on port 5269? Does that work?

  197. intosi

    You mean on the A or AAAA record listed for channel.domain?

  198. ralphm


  199. Lloyd

    ralphm: yes, standard disco is the preference, DNS is the fallback

  200. ralphm

    see this is the confusing bit

  201. intosi

    So, normal 6120 §3.2 behaviour?

  202. ralphm

    if you say 'channels.' is the fallback, *then* it is clear

  203. ralphm

    You don't need to talk about DNS in the case, even though it is involved

  204. simon

    it falls back to looking for a SRV record - if that isn't there then it gives up.

  205. ralphm

    so that's unlike normal lookup for s2s

  206. simon

    who said it was s2s.

  207. intosi

    Well, that's what you were implying earlier, as I understood it.

  208. Kev

    You did, implicitly, when you said you were doing standard XMPP.

  209. simon

    component to component if you want to name it.

  210. Kev

    There is no XMPP component to component protocol.

  211. MattJ


  212. Kev

    So, S2S, then.

  213. simon

    thanks MattJ.

  214. simon

    So if there's a XEP that says how components should be delegated, I'd love to see it.

  215. ralphm

    XEP-0114 is a server side protocol, totally irrelevant for inter server communication in any sense

  216. simon

    but since there isn't I don't think applying the entire s2s stack to discovery makes sense.

  217. ralphm

    the entire s2s stack isn't much is it

  218. ralphm

    it is setting up streams between servers

  219. ralphm

    Note that I am trying to be very exact here

  220. Kev

    simon: A component is, to the outside world, just another server.

  221. ralphm

    while Google is one big distributed beast posing as many servers

  222. simon

    why would a buddycloud component need care about s2s if it knows what remote component to talk to? All it cares about is discovering the remote component and connecting to the right XMPP server.

  223. ralphm

    s2s-wise you can't tell the diff

  224. Kev

    simon: It doesn't talk to a component. It talks to a server.

  225. ralphm

    simon: I don't care how buddycloud's organised internally

  226. ralphm

    I only care about the edges, in this case s2s

  227. ralphm

    Similarly, protocol-wise, there's nothing to prevent having MUC rooms and user accounts at the same domain

  228. ralphm

    (say, ralphm@jabber.org and jdev@jabber.org)

  229. MattJ

    Prosody allows it :)

  230. simon

    ralphm:so if a domain doesn't have a buddycloud server (perhaps it's hosted on bc-hosting-cloud.org - how should the lookup work?

  231. ralphm

    apparently 'try channels.bc-hosting-cloud.org' instead

  232. ralphm

    without any additional changes

  233. simon


  234. ralphm

    I assume you know how it works

  235. simon

    that seems to do away with a lot of the correctness of using SRV to say this is the service that runs X.

  236. ralphm


  237. ralphm

    once you are ready to try channels.domain, you try dns srv, if missing dns a and aaaa and [ort 5269

  238. ralphm

    like s2s always does?

  239. simon

    you are assuming that you know the name of the remote component running buddycloud. If I want to follow ralphm-on-buddycloud@ik.nu, (and ik.nu doesn't run a buddycloud server) my buddycloud component now has to assume that all buddycloud servers are channels.ik.nu.

  240. intosi


  241. simon

    correction that the remote server is channels.ik.nu

  242. intosi

    Then try the hosts and ports for s2s as per 6120 §§ 3.2.1 – 3.2.2.

  243. simon

    why would it try channels.ik.nu and not other-service-name.ik.nu?

  244. simon

    remember if you user@domain.com on buddycloud not user@buddycloud-component.domain.com

  245. simon


  246. simon

    (XEPign now)

  247. intosi

    simon: because you just defined it would, if no other service was disco'd on ik.nu

  248. simon

    fair enough. I just don't think it's a great idea to hardcode expected hostnames into code.

  249. simon

    it's not like we expect to connect to XMPP.domain.com as a fallback for discovery.

  250. intosi

    simon, you misunderstood. You're defining a fallback for your BC disco.

  251. intosi

    As far as I understand, you defined this as channels.domain

  252. simon

    I explained that you don't know the component on the remote server that offers buddycloud services.

  253. simon

    Does this help http://imgur.com/4y2BTvd ?

  254. intosi

    Exactly how does DNS lookup say it should talk to channels.capulet.lit in this case, and which part of this diagram is resolving it? Meaning: what DNS query is made? Is this happening in the buddycloud component, and will that component use the found name in a regular fashion, that is: ask montague.lit to route it to whatever is discovered?

  255. simon

    _buddycloud-server._tcp.imaginator.com. (code for the curious: https://github.com/buddycloud/buddycloud-server-java/pull/114)

  256. ralphm

    simon: now it is clear. Thanks.

  257. simon

    ralphm: :)

  258. ralphm

    simon: I'm not sure why it took this long to get to this :-(

  259. intosi

    You should've pointed to this commit immediately. Would've saved a lot of discussion.

  260. ralphm

    simon: I also think this was the feared answer

  261. ralphm

    I do like some parts of this solution (the indirection), but not the fact that it is done as a SRV record pointing to a server that talks (some form of) XMPP

  262. Zash

    How does that work with IDNA?

  263. intosi

    A PTR would be better suited, a la DNS-SD

  264. waqas

    Without DNSSEC (and we'll be without DNSSEC for a while), isn't relying on DNS for this insecure?

  265. ralphm

    intosi: agreed. DNS-SD is great for this

  266. ralphm

    waqas: I wanted to leave DNSSEC out of this particular discussion

  267. ralphm

    it is rather orthogonal

  268. MattJ

    (but it is insecure ;) )

  269. ralphm

    MattJ: what ever, man

  270. waqas

    Well, there is no trust here if there's a third-party able to send DNS responses to the client

  271. intosi

    MattJ: live a litte. On the edge, man!

  272. ralphm

    waqas: the same thing happens with normal s2s or c2s traffic. We're talking about how buddycloud solves a particular discovery mechanism for servers that you don't control, but you do 'control' the DNS

  273. waqas

    ralphm: That's not true, in normal s2s or c2s traffic, assuming TLS is in effect and certs are verified, you can't pretend to be someone you are not. In this case, the entire trust model is only DNS, nothing else.

  274. waqas

    ralphm: So if I as an attacker can hack DNS, should I be able to pretend to be the buddycloud server of any arbitrary user?

  275. simon

    ralphm: "SRV record pointing to a server that talks (some form of) XMPP": once you have discovered the remote bc component, you are using the s2s connection between the two xmpp servers. We can debate the inscurity of the DNS system if you want but it seems that the road to solving that is well defined with DNSSEC deployment.

  276. ralphm

    waqas: in this implementation, yes. If he used PTR records, it would be better

  277. ralphm

    simon: no, because the discovery doesn't do fallback on A/AAAA records

  278. simon

    how is fallback magically secure?

  279. ralphm

    simon: intosi is right in saying you should have used PTR here. Then, you'd point to the domain where a service is hosted, and then do the *normal* s2s stuff

  280. ralphm

    (the key here is *domain* v.s. server)

  281. waqas

    My point is that at no point is the original server asked over a secure channel whether the buddycloud server is valid for that host. I'd much prefer e.g., a POSH like approach where the discovery is over https, not insecure DNS

  282. ralphm

    waqas: yes, that can't happen for something like Google Talk

  283. Zash

    waqas: Because in this scenario that server does not support that

  284. ralphm

    waqas: that's why it is there to begin with

  285. intosi

    For sane servers, this isn't needed at all.

  286. ralphm

    POSH is an alternative, sure

  287. waqas

    So.. is there a server which gets to be /the/ gtalk buddycloud server?

  288. waqas

    I don't see how this solves the gtalk issue, gtalk isn't going to change their DNS

  289. ralphm

    waqas: if you host your domain at google

  290. ralphm

    waqas: you control your own DNS, but not the server implementation

  291. ralphm

    waqas: so you can't rely on disco

  292. waqas

    Ah, I see, in which case you can do POSH too, no?

  293. ralphm

    waqas: yes

  294. waqas

    And POSH in that case would be secure, as opposed to DNS? :)

  295. waqas

    Anyway, I'm dragging this on, ignore me

  296. simon

    waqas: imho the correct solution is for the XMPP community to make a concerted effort on getting good DNSSEC support in all servers (I like Proosdy's progress on this).

  297. waqas

    POSH will remain much easier for quite a few years I think

  298. ralphm

    simon: that still makes your solution suboptimal

  299. ralphm

    waqas: I think that it would be good enough if you did PTR records and have proper certs at the server being pointed too

  300. ralphm


  301. simon

    If your DNS is poisoned, how does PTR help over SRV?

  302. waqas

    Indeed, I don't see how PTR is any more secure

  303. ralphm

    I am not talking about DNS poisoning. It is orthogonal to SRV being a bad choice for pointing buddycloud to another domain

  304. ralphm

    which was the discussion originally

  305. intosi

    waqas: it's not about being more secure, it's about using the appropriate record the the job.

  306. waqas

    Ah, k

  307. ralphm

    Yes, POSH or DNSSEC would make the whole thing more trusted. But just for this particular problem, having an DNS PTR (even if the DNS might be compromised) with proper certs at the endpoint is good enough, I think.

  308. waqas

    ralphm: From a security perspective, or without considering security?

  309. ralphm

    from a security perspective

  310. waqas

    Certs being proper does nothing to establish that serverA trusts serverB with this service

  311. simon

    Side note: by using PTR, the local buddycloud component must go through a bunch more roundtrips for disco-ing the right component.

  312. intosi

    simon: no. The component will just use the name returned and use that as the remote component domain.

  313. dwd

    I'm confused still. So the SRV is looked up, and returns IN SRV 5 0 5269 buddycloud.imaginator.com, right?

  314. intosi

    The XMPP server the component is connected to will route it.

  315. dwd

    What does the local component route to here?

  316. ralphm

    dwd: no the actual machine

  317. ralphm

    dwd: so, say, 'spock.imaginator.com'

  318. ralphm

    I'm not sure which domain is used within XMPP at that point, by the way

  319. dwd

    ralphm, I'm using the example on the pull request.

  320. dwd

    ralphm, Exactly. Does the component use "buddycloud.imaginator.com", and therefore that *too* has SRV records, this time for xmpp-server?

  321. intosi

    If you want to use it as an alternative to disco, that's the only way it should work.

  322. dwd

    OK, but what do the port numbers mean? ANd what's the handling for multiple SRV?

  323. intosi

    dwd: that's why I suggested SRV was the wrong record, and PTR should be used instead.

  324. Zash

    There's also a URI records somewhere

  325. dwd

    Zash, NAPTR? Yay!

  326. dwd

    Zash, Actually the URI variant is U-NAPTR, pronounced "Unapointer", a bit like the Unabomber, and almost as scary.

  327. intosi


  328. intosi

    And again introduces priority and weight.

  329. intosi

    Although it's probably more appropriate than using SRV.

  330. dwd

    intosi, Anything other than CNAME will have some case of multiple records.

  331. dwd

    intosi, CNAME, mind, seems like a reasonable option.

  332. Zash

    dwd: I was thinking of https://tools.ietf.org/html/draft-faltstrom-uri-06

  333. intosi

    Could be.

  334. intosi

    CNAME or PTR are both more appropriate for this than SRV.

  335. ralphm

    I also assume that 'buddycloud' is not a registered service at IANA. I don't recall if PTR has that restriction.

  336. ralphm

    but SRV does

  337. intosi

    Although resolvers might try to get the A or AAAA of a CNAME automatically.

  338. intosi

    ^resolvers^resolver libraries

  339. simon

    buddycloud-api is registered with IANA. If needed, a SRV could be. (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=buddycloud)

  340. ralphm

    ah, cool

  341. ralphm

    simon: but I would definitely switch to something based on PTR

  342. ralphm

    or at least not using SRV like it is now

  343. simon

    (buddycloud-api is used by mobile clients needing to find the HTTP endpoint for API calls)

  344. ralphm

    does *that* use PTR?

  345. dwd

    TXT by the looks of things.

  346. intosi

    I'd say a U-NAPTR would be more appropriate ;)

  347. simon

    ralphm: TXT as defined in the DNS-SD RFC https://groups.google.com/d/msg/buddycloud-dev/ww0yjdwRuNY/Qf7930KxG7MJ

  348. dwd

    Ah, the iPod RFC.

  349. ralphm

    dwd: hah!

  350. simon

    The format actually makes a lot of sense for describing how to connect to remote services.

  351. dwd

    You've read it too, huh?

  352. dwd

    simon, Yes, it's a sane protocol. Just a real shame that it didn't go through the IETF standards process, and most of the edits seemed to be updating Apple product names.

  353. simon

    They had working implementations before writing the spec. Shocker!

  354. dwd

    Yes... So?

  355. simon

    dwd: looks like it is going through ietf https://tools.ietf.org/html/rfc6763

  356. dwd

    simon, Oh, so it did eventually go through standards track. It was originally going to be Informational. But the Appendix G, "All Apple product names I can think of" is still there.

  357. ralphm

    simon: I like implementations before writing specs. I don't like reinventing stuff that already has established solutions. Apple is notorious for just doing whatever pleases them.

  358. simon

    IMHO it's a good spec. Don't know why we're talking about Apple here.

  359. dwd

    simon, The IETF developed Zeroconf and a slew of supporting tech, and Apple developed DNS-SD instead. And eventually specified it with Appendix G.

  360. dwd

    simon, Most of the edits to the spec for the past few years were to update various Apple product names in Appendix G, and not to do anything else with the protocol.

  361. dwd

    simon, Any changes were rejected because they'd already deployed, of course.

  362. dwd

    simon, I agree that DNS-SD is a good spec. So was Zeroconf, but Apple effectively destroyed that one.

  363. ralphm

    dwd: hm? I thought DNS-SD built on Zeroconf, I don't know the history much

  364. dwd

    No, parallel development. Apple was involved in both IIRC.

  365. dwd

    They're *very* similar.

  366. ralphm


  367. simon

    dwd: you mean the old link local name resolution drafts?

  368. ralphm

    I can't make out the difference from the wikipedia page

  369. simon

    "local link multicast name resolution"

  370. dwd

    The differences are small but incompatible, according to Appendix G.

  371. ralphm

    oh, but that's Microsoft's stuff, right?

  372. Zash

    Yeah, isn't there a Microsoft one too

  373. ralphm

    LLMNR, what simon mentioned

  374. Zash

    Which one is mDNSSD then?

  375. ralphm

    mDNS an DNS-SD are two things

  376. ralphm

    mDNS is for doing DNS on lans

  377. ralphm

    with .local

  378. Zash

    and multicast

  379. Zash


  380. ralphm

    hence the m

  381. simon

    seems like there was a lot of unhappiness about the Link Local Multicast Name stuff: http://www.ietf.org/mail-archive/web/ietf/current/msg37393.html

  382. ralphm

    I so wish that more things supported mDNS and DNS-SD

  383. ralphm

    So happy that my Ubuntu laptop can find my printer at officejet.local

  384. ralphm

    Unfortunately, support in Android is non-existant

  385. ralphm

    I SSH between my boxes at home with .local addresses exclusively

  386. simon

    Android music strategy is currently "send everything over bluetooth" which seems rather daft.

  387. ralphm

    wait huh?

  388. simon

    unless I missed a new app that lets me stream to my raspberryPi via wifi.

  389. ralphm

    I use ChromeCast, but yes, that space is still a bit of a mess

  390. simon

    (ralphm: one thing that Zeroconf solved nicely on the Apple side was announcing music recivers via Bonjour/Zeroconf/mDNS)

  391. ralphm

    although UPnP also builds on stuff like zeroconf/mDNS/DNS-SD

  392. Zash

    UPnP, the SOAP-over-HTTP-over-UDP thing?

  393. ralphm

    simon: indeed, my Rhythmbox announces itself as Ralphonics and Apple devices can play from it

  394. ralphm

    visa versa is horrible because of Digital Restrictions

  395. ralphm

    Zash: soon over XMPP

  396. ralphm

    Zash: you are going to liason, right?

  397. Zash

    Yes, let me control port forwarding in my router with XMPP please!

  398. simon

    port forwarding is so ipv4 :)

  399. intosi

    Simon: open ports in your IPv6 firewall. Same stuff, different proto.

  400. Zash

    My router has Port Forwarding → Basic IPv6 → bunch of forwarding stuff

  401. simon

    my router has openwrt. Job done.

  402. ralphm

    simon: how is that relevant?

  403. ralphm

    simon: the idea is that there is a standard protocol for modifying firewall settings

  404. ralphm

    While UPnP might be horrible in some respects, at least there's something

  405. simon

    Ralphm: I totally get that.

  406. ralphm

    Zash: I was being serious about the liason thing

  407. Zash

    ralphm: There's a Port Control Protocol being developed, with less SOAP iirc

  408. intosi

    PCP, really?

  409. Zash

    ralphm: Huh, to who where?

  410. ralphm

    Zash: http://mail.jabber.org/pipermail/members/2013-December/007496.html

  411. Zash

    Did that involve NDAs?

  412. Zash

    intosi: https://datatracker.ietf.org/wg/pcp/

  413. Zash

    Oh, there's an {rfc 6887} already

  414. Bunneh

    Zash: Port Control Protocol (PCP). D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk. April 2013. (Status: PROPOSED STANDARD) http://tools.ietf.org/html/rfc6887

  415. intosi

    I was chuckling about the acronym.

  416. intosi

    Naming protocols after drugs and all.

  417. ralphm

    Zash: there's still some discussion on the extend of NDAs here