XSF Discussion - 2017-10-30


  1. thomas_

    Hi guys, while reading the MIX spec, I'm wondering how the roster item for the MIX channel is added to the user joining the channel if it's an external MIX server? Is the user's server supposed to scan the MIX join/leave stanzas in order to determine if the user successfully joined the channel?

  2. jonasw

    thomas_, yes

  3. jonasw

    the server needs MIX support

  4. jonasw

    (that is, the users server)

  5. jonasw

    you may note that the join is a command sent to the users account, not to the channel the user wants to join

  6. jonasw

    see Example 22

  7. thomas_

    jonasw, oh okay, I missed that bit of information

  8. thomas_

    jonasw, thanks for clarifying this!

  9. jonasw

    you’re welcome!

  10. moparisthebest

    Is there a xep for, probably wording this wrong, a client sending messages to itself and other resources (mam/carbons) from other domains?

  11. moparisthebest

    Basically spoofing from, but only to itself

  12. Zash

    Forwarding?

  13. jonasw

    moparisthebest, why would you do that?

  14. moparisthebest

    Ok so jmp.chat gives you a phone number for sending/receiving sms with xmpp

  15. moparisthebest

    Basically thinking the same thing as a conversations plugin

  16. jonasw

    i.e. a local transport for SMS <-> XMPP?

  17. jonasw

    I don’t think there’s a XEP for that, but I think that’s not the worst idea.

  18. Zash

    Why not treat it as another account?

  19. jonasw

    Zash, replication to other devices

  20. jonasw

    moparisthebest, question though: how would you intercept messages sent to those SMS JIDs?

  21. jonasw

    essentially you want a component, but only for the account.

  22. moparisthebest

    Ie my phone gets SMS from 5555, I see it in conversations and all my other xmpp clients as from 5555@some.specific.fake.domain

  23. moparisthebest

    If I respond in conversations it sends it over sms, if I respond in other clients conversations sends sms when it gets the carbon?

  24. Zash

    Oh dear, is this leading to an argument for uploading into your archive?

  25. Zash

    ... like 136 hasq

  26. Zash

    ... like 136 has?

  27. moparisthebest

    So this would need a server plugin too

  28. jonasw

    moparisthebest, that carbons trick there would kindof work, but it would also create some strain on the server for error handling of stanzas it doesn’t even need to s2s-route

  29. moparisthebest

    Basically to allow a client to spoof from for a certain domain but only for that account

  30. Zash

    But, there's the forwarding xep (used for encapsulation by carbons and mam)

  31. moparisthebest

    That might work have a xep number handy?

  32. Zash

    297 maybe? (wild guess)

  33. jonasw

    297

  34. jonasw

    https://xmpp.org/extensions/xep-0297.html

  35. Zash

    Bunneh: xep forwarding

  36. Bunneh

    Zash: XEP-0297: Stanza Forwarding (Standards Track, Draft, 2013-10-02) See: https://xmpp.org/extensions/xep-0297.html

  37. jonasw

    it doesn’t magically give you the kind of handling you want though

  38. moparisthebest

    Because yea I'd want carbons and mam etc

  39. jonasw

    it only defines an encapsulation protocol (as re-used by carbons etc.)

  40. moparisthebest

    This would work as a separate component of course but that had issues like this

  41. moparisthebest

    Not encrypted, different connection, separate component for each account etc etc

  42. Zash

    The architecture with transports as server components kinda breaks down when clients are also transports

  43. jonasw

    to have things well defined, you have to use this on one account only anyways

  44. moparisthebest

    Yes

  45. jonasw

    so user components are an interesting concept

  46. jonasw

    like a component, but the domain is only visible to the user

  47. jonasw

    (and other users may have the same domain)

  48. moparisthebest

    Yes that

  49. jonasw

    but that’s not specified yet

  50. moparisthebest

    Forwarding wouldn't work I think

  51. moparisthebest

    No real great way to respond and such I think

  52. moparisthebest

    Can clients send carbons to other resources?

  53. jonasw

    yes, but those must ignore them

  54. moparisthebest

    Bunneh: xep carbons

  55. Bunneh

    moparisthebest: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html

  56. Zash

    You probably want to invent some new protocol

  57. Zash

    There /was/ that {xep remote control}

  58. Bunneh

    Zash: XEP-0146: Remote Controlling Clients (Informational, Active, 2006-03-23) See: https://xmpp.org/extensions/xep-0146.html

  59. moparisthebest

    I'll have to abuse gajims XML console later and play around

  60. moparisthebest

    I feel like maybe carbons from other resources would be safe right?

  61. Zash

    Broadcast is the kind of thing you want your server to help you with

  62. moparisthebest

    I think jonasw 's description is closest to what I'm looking for, user or client components

  63. moparisthebest

    True Zash

  64. moparisthebest

    Hmm then you could use the phone's dialer to jingle call through it too...

  65. moparisthebest

    Leave your cell at home and sms/call through it wherever you have an xmpp client and internet

  66. moparisthebest

    Anyone interested in working with me on something like that? :)

  67. thomas_

    moparisthebest, maybe I didn't get your idea but why not using a transport with <phonenumber>@transport for each phone contact?

  68. moparisthebest

    I think it could be as simple as the server advertising that the client can send messages to itself from *@*.somedomain then the server not doing s2s for *. somedomain and allowing that

  69. moparisthebest

    thomas_: the transport is per user account and runs on one of their clients is why

  70. thomas_

    moparisthebest, why does the transport run on a client?

  71. Zash

    It's a phone?

  72. moparisthebest

    thomas_: conversations on your phone is the only thing with access to send/recieve sms

  73. Zash

    You wanna pretend that the native SMS functionality is a component

  74. thomas_

    Oh, I though you have a device with your SIM card somewhere and want to connect via XMPP

  75. jonasw

    thomas_, the component protocol is insecure

  76. jonasw

    that’s one reason why you don’t want to run that $somewhere

  77. jonasw

    second, if you don’t run your own server / the server is shared with multiple entities, you don’t want them to access your transport

  78. moparisthebest

    Plus it's per server not per account

  79. jonasw

    that’s what I mean, essentially

  80. thomas_

    ah okay

  81. moparisthebest

    Hmm you could run a component that you register with and send arbitrary messages to your own account through...

  82. moparisthebest

    Then no server changes needed

  83. jonasw

    simj

  84. jonasw

    kind of an echo component?

  85. jonasw

    that would work.

  86. moparisthebest

    Essentially yes

  87. jonasw

    a meta-component

  88. moparisthebest

    Done extra rules but yea

  89. jonasw

    a component to create per-user components :D

  90. moparisthebest

    Some*

  91. jonasw

    that’s quite fancy, actually, because you get stream management etc. "for free"

  92. moparisthebest

    Yep I like simple

  93. Zash

    You could also register a normal account and send yourself messages via that

  94. jonasw

    Zash, you’d need one account for each phone number you text?

  95. moparisthebest

    Zash: no you need from to be multiple accounts based on phone number

  96. moparisthebest

    Yes

  97. Zash

    Abuse resources! :D

  98. jonasw

    resource abuse will wreak havoc with message routing 2.0

  99. moparisthebest

    Can't add them to your contacts though

  100. jonasw

    (also, one connection per peer, really? ;-))

  101. moparisthebest

    With jmp.chat it's phonenumber@cheogram.com

  102. jonasw

    moparisthebest, you should write a XEP for this echo component with the given use-case.

  103. moparisthebest

    This component could even be public and require no local server support

  104. jonasw

    the only thing I don’t like about it is that you can only have N components per user, where N is the number of server-side components :/

  105. jonasw

    it doesn’t even need to be a component

  106. jonasw

    you should probably not reference any component-specific protocol

  107. jonasw

    only that it is a domain-JID entity which implements that protocol

  108. jonasw

    which means that servers could also offer you *@*.local for example.

  109. moparisthebest

    I'll give it a try jonasw , I'm the type to code/test first and write specs later :)

  110. jonasw

    right

  111. jonasw

    happy to proof-read if you want to before submission.

  112. Zash

    <message to=self><forwarding><message from="number@actually.sms.invalid" to="self"><body>hi</body><////>

  113. Zash

    Thing gets wrapped in seven layers of carbons and forwarded to all your clients.

  114. jonasw

    Zash, that’s the easy part -- the tricky part is to be able to send messages to number@actually.sms.invalid

  115. Zash

    jonasw: <message to="me@self/phone"><forward><message to="number@sms"><body>HELLO<///>

  116. moparisthebest

    But being able to do component and avoid lua or erlang makes it something I can do myself at least (sorry server devs...)

  117. Zash

    Add some caps and call it a day!

  118. moparisthebest

    jonasw: does your Python lib do components?

  119. moparisthebest

    I've only ever used the ancient first Python lib for components

  120. jonasw

    no

  121. jonasw

    Zash, right

  122. jonasw

    that’d work but ...

  123. jonasw

    but it would also require client support on the clients which are not the component

  124. Zash

    Yes

  125. jonasw

    simple clients!

  126. jonasw

    (also, I’m not entirely sure how serious your proposals are)

  127. Zash

    I don't think clients are simple anymore

  128. Zash

    jonasw: On a scale from dead serious to trolling? Usually somewhere in the middle.

  129. zinid

    > But being able to do component and avoid lua or erlang makes it something I can do myself at least pussy detected

  130. Zash

    jonasw: "That's my secret. I'm always joking." :D

  131. moparisthebest

    zinid: I prefer the word 'sane' :)

  132. zinid

    moparisthebest: writing in python is sane?

  133. Zash

    not writing everything in Lua is sane???

  134. moparisthebest

    Hoping to use rust if there are component libs, but yea point taken about Python :)

  135. jonasw

    moparisthebest, there is xmpprs or so

  136. jonasw

    not sure if it can do components

  137. moparisthebest

    Yea I've used it for a client

  138. zinid

    yeah, rust...

  139. moparisthebest

    the component will be dead simple in any language

  140. moparisthebest

    the client will have to decide whether or not to send new SMS on carbon/mam etc, ew

  141. moparisthebest

    next ridiculous question, is there anything defined in jingle for one resource to make a call through another resource?

  142. moparisthebest

    same account, resource A is connected to a phone line, resource B is not

  143. moparisthebest

    B wants to make a phone call, any current way to do that?

  144. Zash

    I don't think there's anything special about that

  145. Zash

    The problem with Jingle is that it works exactly like that

  146. Zash

    One arbitrary JID calls another arbitrary JID.

  147. Zash

    As opposed to one account calling another account.

  148. moparisthebest

    that's not exactly what I mean though

  149. Zash

    So I don't think anything in the Jingle spec prevents two resources of the same account from establishing calls

  150. moparisthebest

    not a call between A and B, a call between B and +1-555-555-5555 THROUGH A

  151. moparisthebest

    so the jingle session would be between A and B, but A would be, uh, forwarding through the PSTN

  152. Zash

    There's a thing, hold on

  153. Zash

    -xep dtmf

  154. Bunneh

    Zash: XEP-0181: Jingle DTMF (Standards Track, Deferred, 2009-10-02) See: https://xmpp.org/extensions/xep-0181.html

  155. jonasw

    lovely

  156. jonasw

    so you’d start a jingle call through A and send DTMF to actually dial a number

  157. moparisthebest

    ha you could I guess, maybe, not sure what android phone API looks like

  158. Zash

    Like, whatever it's called when you call somewhere and go into an answering machine that you type more numbers into to get passed on

  159. jonasw

    moparisthebest, but I don’t think you need special protocol for that. you’d contact the gateway client at its pseudo-JID at the component and it would re-write the jingle connection negotiation messages accordingly so that the call is routed through it

  160. Zash

    Maybe you need to find/invent some way to tell the other end to proxy you

  161. Zash

    But, isn't that basically how PSTN works (or used to, way back in the analog era)?

  162. jonasw

    don’t need to, it’s already proxied through the pseudo-JID magic

  163. moparisthebest

    hmm not sure I kind of imagined them seperately

  164. moparisthebest

    that would probably be best, have to think about it

  165. Zash

    -xep rayo

  166. Bunneh

    Zash: Multiple matches: Rayo https://xmpp.org/extensions/xep-0327.html Rayo Fax https://xmpp.org/extensions/xep-0342.html Rayo CPA https://xmpp.org/extensions/xep-0341.html Rayo Clustering https://xmpp.org/extensions/xep-0349.html

  167. Zash

    Uh, maybe anything in those have anything usable?

  168. jonasw

    I’m not sure if I was understood

  169. moparisthebest

    hmm possibly

  170. moparisthebest

    jmp.chat neatly bypasses all this by 'if you want voice, connect to this SIP account:'

  171. Zash

    Neatly solve this problem by putting your phone next to your server and writing a component that connects over USB or somesuch :)

  172. moparisthebest

    anyway one step at a time, SMS is much simpler

  173. moparisthebest

    if I'm sending a message to a JID but need to encode 1 seperate piece of info, what's the best way to do that?

  174. jonasw

    <foo/>?

  175. moparisthebest

    a new element inside <message> or inside <body> or a new attribute on something?

  176. jonasw

    NOT INSIDE BODY

  177. jonasw

    ahem

  178. jonasw

    never ever mix elements and text

  179. moparisthebest

    yea but where and what should I do about namespaces?

  180. jonasw

    (unless you’re doing XHTML or something)

  181. jonasw

    "choose" a namespace

  182. jonasw

    don’t add attributes to any existing elements, make your own element and put it an <message/>

  183. moparisthebest

    but inside message is fine?

  184. jonasw

    think about what happens if your peer doesn’t understand it

  185. moparisthebest

    great thanks

  186. moparisthebest

    what's the precedent for naming these things with multiple words, for example, <echo-from xmlns="urn:xmpp:echo-self">+15555555555</echo-from> ?

  187. Zash

    Metadata in attributes and content in text nodes :)

  188. Zash

    Most things are just one word afik

  189. moparisthebest

    ah so I could go

  190. moparisthebest

    <echo xmlns="urn:xmpp:echo-self" from="+15555555555" />

  191. moparisthebest

    looks cleaner anyhow probably

  192. Zash

    and urn:xmpp is technically not something anyone can just use without going through the XSF

  193. moparisthebest

    yea I'll make something else for testing

  194. jonasw

    Zash, sure you can, it just breaks things.

  195. jonasw

    (or may break due to conflict etc.)

  196. Zash

    Do we have any recommendations for these things, or do they exist anywhere?

  197. moparisthebest

    yea that's what I was asking about

  198. moparisthebest

    doesn't matter at this point but would be nice to see

  199. Zash

    Stuff like {urn:example:foo}foo usually annoy me slightly

  200. Zash

    *ahem* {http://jabber.org/protocol/pubsub}pubsub/action *hrr*

  201. jonasw

    moparisthebest, I’m not entirely sure what you need that element for, but I suggest that you orient your wire-format on what XEP-0280 (Message Carbons) does

  202. jonasw

    at least for the communication between the component and the user component implementation

  203. jonasw

    (not for component<->normal resources)

  204. moparisthebest

    I think this might be the only thing the server component needs

  205. moparisthebest

    basically that would mean 'send me this message from that JID'

  206. moparisthebest

    the component ignores everything else, carbons handles that

  207. jonasw

    so the user component implementation on the phone client would send <message to=component><body>...</body><echo xmlns="..." ...>...</echo></message>?

  208. moparisthebest

    yes

  209. jonasw

    please wrap the message once

  210. moparisthebest

    I was going to include the no-copy and no-carbons stuff

  211. jonasw

    no

  212. moparisthebest

    why wrap it so I wouldn't have to do that?

  213. jonasw

    because it makes things explicit

  214. jonasw

    something like <message><echo send-from="..."><forwarded><message ...>...</message></forwarded></echo></message>

  215. jonasw

    re-uses XEP-0297 even though the naming is a bit off

  216. jonasw

    has the advantage that this won’t be picked up by MAM or carbons

  217. jonasw

    (because of type="normal" on the outer and no <body/>)

  218. moparisthebest

    jonasw, that seems harder

  219. moparisthebest

    right now the entire logic of the component is this:

  220. moparisthebest

    if msg.find('{urn:moparisthebest:echo-self}echo') is not None: to = msg['to'] msg['to'] = msg['from'] msg['from'] = to msg.send()

  221. moparisthebest

    done

  222. jonasw

    moparisthebest, given that <no-store/> and <no-copy/> are from XEP-0334 which is in limbo since Council rejected its advancement, it seems like the more future-proof approach

  223. moparisthebest

    ignores everything without <echo>, if it has echo, swaps to/from and sends it back?

  224. jonasw

    that’s not what you want though

  225. jonasw

    what you’re doing requires all involved clients to know the echo protocol

  226. jonasw

    I’d avoid that

  227. moparisthebest

    no it's working exactly right without any clients knowing it

  228. moparisthebest

    except the one sending it that is

  229. moparisthebest

    (currently gajim xml console)

  230. jonasw

    how would I reply to a message from somenumber@thatcomponent.domain?

  231. dwd

    moparisthebest, You're not an SDO - don't use "urn:...". Just use an http scheme URI to your domain. Or an xmpp scheme one, like your jid.

  232. jonasw

    what is an SDO?

  233. dwd

    moparisthebest, For example, I could use xmlns="xmpp:dwd@dave.cridland.net/some-proto"

  234. dwd

    jonasw, In this context, a Standards Development Organisation

  235. jonasw

    ah

  236. moparisthebest

    before today I've happily lived completely ignoring xmlns

  237. moparisthebest

    oh how I yearn for 10 minutes ago

  238. dwd

    jonasw, You're an XSF Editor, right? I noticed some of "my" XEPs are using old contact info - what's the best way to update that?

  239. dwd

    moparisthebest, They're strings. Mostly without meaning, except the ones that do have meaning. But we're supposed to know how to use them properly.

  240. jonasw

    dwd, which ones exactly?

  241. jonasw

    or rather: have you checked whether your info in xep.ent is up-to-date? if it isn’t, that’d be a great way to start.

  242. moparisthebest

    also, how dare dwd assume I'm not a Standards Development Organization :)

  243. dwd

    jonasw, I happened to notice XEP-0286, but there might be others.

  244. dwd

    moparisthebest, Actually the best definition I have for an SDO is whether they can register a urn prefix.

  245. jonasw

    dwd, https://github.com/xsf/xeps/blob/master/xep.ent#L924 is this up-to-date?

  246. moparisthebest

    :'(

  247. dwd

    jonasw, Yes.

  248. jonasw

    dwd, okay, will update the XEPs not using that entity definition.

  249. dwd

    jonasw, Thanks. Much appreciated.

  250. jonasw

    (there are two)

  251. jonasw

    (XEP-0376 is the other one)

  252. jonasw

    moparisthebest, I was thinking something like this: <!-- User component to Component --> <message to="component.domain" from="account@domain/user-component-client"> <echo xmlns="foo"> <forwarded> <message from="phonenumber@component.domain" to="account@domain" id="xyz"> <body>Hi there!</body> </message> </forwarded> </echo> </message> <!-- Component to account --> <message from="phonenumber@component.domain" to="account@domain" id="xyz"> <body>Hi there!</body> </message> <!-- Some client from the account replies --> <message from="account@domain/resource" to="phonenumber@component.domain" id="abc"> <body>Hi yourself!</body> </message> <!-- Component to User component --> <message from="component.domain" to="account@domain/user-component-client"> <echo xmlns="foo"> <forwarded> <message from="account@domain/resource" to="phonenumber@component.domain" id="abc"> <body>Hi yourself!</body> </message> </forwarded> </echo> </message>

  253. jonasw

    this has the advantage that the protocol between user component and the server-side component is explicit

  254. jonasw

    the interaction between the component and other clients is like with any other domain

  255. jonasw

    which is nice

  256. jonasw

    wrapping the actual payload saves it from being archived etc.

  257. moparisthebest

    then the component has a state

  258. jonasw

    moparisthebest, why would it need state for that?

  259. moparisthebest

    and there is, registering stuff involved

  260. moparisthebest

    <!-- Component to User component -->

  261. jonasw

    right, it needs to know that anyways?

  262. moparisthebest

    I don't think so

  263. jonasw

    how would it not need that?

  264. jonasw

    it does have to know where to deliver messages sent by other clients to the component?

  265. moparisthebest

    the user's server handles it for them, with carbons

  266. moparisthebest

    and/or mam etc

  267. jonasw

    ugh, you’ll simply ignore them and rely on carbons? :/

  268. jonasw

    I see

  269. moparisthebest

    exactly :)

  270. jonasw

    I don’t like that approach :)

  271. jonasw

    it relies on carbon rules which are super-foggy

  272. moparisthebest

    it has the advantage of the component being potentially the simplest xmpp component of all time

  273. jonasw

    I can also see the use-case of <iq/> and other stanza types for user components.

  274. jonasw

    but it’s not really re-usable

  275. moparisthebest

    true it only works for carbon'd things

  276. moparisthebest

    still that seems like an additional xep for non-message things that don't get carboned, might as well keep this super simple

  277. jonasw

    but consistency.

  278. moparisthebest

    does message have to have a body ?

  279. jonasw

    no

  280. jonasw

    carbons for example do not have bodies

  281. moparisthebest

    I don't know if it's sleekxmpp or prosody, but one is refusing to deliver it

  282. jonasw

    care to show some XML traces?

  283. moparisthebest

    no errors, just doesn't go through until I add a body

  284. jonasw

    I suspect that might not be the only difference. there are a lot of use-cases for non-body messages.

  285. jonasw

    (chat state notifications for example)

  286. moparisthebest

    no I'm pasting into the gajim xml console and that's the only difference :)

  287. jonasw

    how are you trying to receive the message?

  288. moparisthebest

    it's sleekxmpp

  289. moparisthebest

    if I turn on COMM level logging it logs it, but doesn't send it to my app

  290. moparisthebest

    well that's a bug I'm not dealing with now

  291. moparisthebest

    will mess with <forwarded> later meh