XSF Discussion - 2019-02-05

  1. pep.

    How bad would it be to s/http:\/\/xmpp\.org/https:\/\/xmpp\.org/ in the xeps repo? Do I have any chance of breaking normative language

  2. Zash

    You'll find that one place where someone used http://xmpp.org in a xmlns

  3. pep.

    I feel http://jabber.org is used most often (when not urn:xmpp), but yeah I guess

  4. Zash


  5. Zash

    xeps$ ack http://xmpp.org/protocol inbox/sxe.xml 262: <query xmlns='http://xmpp.org/protocol/disco#info'/> 268: <query xmlns='http://xmpp.org/protocol/disco#info'> xep-0284.xml 268: <query xmlns='http://xmpp.org/protocol/disco#info'/> 274: <query xmlns='http://xmpp.org/protocol/disco#info'>

  6. pep.


  7. pep.


  8. pep.


  9. Zash

    That's gotta be a typo for jabber.org/protocol tho?

  10. pep.

    Ok I'll be careful then

  11. pep.

    Probably in examples?

  12. pep.

    let's see

  13. Zash

    xep-0397.xml has a bunch of xmlns="https://xmpp.org/....

  14. pep.

    that's fine, I won't change this one :P

  15. pep.

    But yeah that should be fixed

  16. Zash

    https://xmpp.org/extensions/xep-0284.html#host this points to xep 30, so looks like a mistake

  17. pep.

    With a bit less effort we should probably add HSTS first

  18. pep.

    The 301 is already there

  19. pep.

    What about: "<p>The &REGISTRAR; shall add 'urn:xmpp:idle:1' to its registry at <link url='https://xmpp.org/registrar/namespaces.html'>https://xmpp.org/registrar/namespaces.html</link>.</p>" ? Is that normative? the registrar uri

  20. Zash


  21. pep.

    (I changed to https in this quote)

  22. Zash

    It is technically a completely different URL, that doesn't have to have the same content as the http: URL

  23. pep.

    err, I don't have access to the nginx that should do HSTS, do I

  24. pep.

    This docker thing only serves 80

  25. Zash

    <meta name='horrible-hack-no-372' http-equiv='strict-transport-security' value='max-age=infinity'>

  26. pep.


  27. pep.

    Technically I can already do that with the nginx inside, but that will send it on both http and https, and it's invalid on http (or just useless?)

  28. Zash

    wasn't 80 just serving a redirect?

  29. pep.

    I should be able to check for x-forwarded-proto maybe

  30. pep.

    Zash, 80, as seen from the outside, yes

  31. pep.

    Not from the container

  32. Zash


  33. Zash

    the outside won't see hsts on port 80?

  34. pep.


  35. pep.

    HSTS SHOULD(MUST?) only be on https

  36. Zash

    so if the container spits it out on port 80, which is reverse-proxied to port 443 with tls

  37. Zash

    then it should all be in order

  38. moparisthebest

    Browsers will ignore it over http

  39. pep.

    It will also spit it on http. But then maybe as I said I can check for X-Fowarded-For

  40. pep.

    moparisthebest, sure

  41. moparisthebest

    So it's fine to send it either way

  42. pep.

    browsers are as compatible as one can be, because the web if full of crap

  43. moparisthebest

    The point is they never visit http again anyhow?

  44. pep.

    I just like to do things properly :x

  45. moparisthebest

    Don't forget to set up a redirect to https from http, and put it in the preload list :)

  46. pep.

    it's already there

  47. Zash

    pep.: if the public port 80 is configured to only s/http/https/ then I don't see how anyone can get hsts via http

  48. moparisthebest

    Do things properly, the web, bahaha :)

  49. pep.

    So I might as well ask iteam directly

  50. pep.

    And not put this hack in the xeps repo

  51. pep.

    Zash, true.

  52. pep.

    Still that's probably not something for the xeps repo

  53. pep.

    Maybe the website, but I feel that should go in the host's conf

  54. Zash

    Is there a container that contains the conainer-container that holds the 7th proxy?

  55. pep.

    Anyway, I should stop procrastinating the procrastination

  56. pep.

    Anyway, I should stop procrastinating procrastination

  57. Neustradamus

    It will be nice to have same base for all without www. etc

  58. edhelas

    I'm really tired of refusing OMEMO requests

  59. edhelas

    I'm thinking of hardcoding the body detection and starting to reply automatically

  60. Ge0rG

    edhelas: just blacklist the OMEMO node on your PEP

  61. lovetox

    whats a OMEMO request?

  62. edhelas

    > I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

  63. lovetox

    tell your contacts to disable omemo?!

  64. edhelas

    yes, one by one :) if at one moment they move to conversations

  65. Ge0rG

    lovetox: that's O(N*M)

  66. Ge0rG

    with N=number of contacts and M=number of devices each contact has

  67. edhelas

    I'm not there to do "remote xmpp client configuration over human written messages"

  68. lovetox

    hm in Gajim you can deactivate publishing keys to the node

  69. lovetox

    but yes this problem exists because you use a client that supports omemo ..

  70. Ge0rG

    because you once used such a client

  71. Ge0rG

    if you are on prosody < 0.11, you can restart your server to "fix" it

  72. edhelas

    yes I do use Conversations sometimes, and Movim 95% of the rest of the time

  73. ralphm

    pep.: there are some, mostly deferred/retracted, XEPs that use http://xmpp.org/ as the start of their namespace. I'd leave them be. If we ever resurrect them, they'd have to go with a urn one anyway.

  74. lovetox

    fastest way would probably to set the devicelist node to whitelist

  75. Ge0rG

    edhelas: write a Movim plugin that subscribes to the siacs namespace and removes all devices

  76. Ge0rG

    or what lovetox said

  77. lovetox

    Ge0rG that does not help

  78. lovetox

    as devices are instantly republished

  79. lovetox

    you can configure nodes in Gajim 🙂

  80. ralphm

    pep.: and probably everything that still has shtml in a link should get looked at.

  81. vanitasvitae

    edhelas: does movim support Explicit Message Encryption?

  82. edhelas

    vanitasvitae I as looking into that

  83. vanitasvitae

    You could use that to determine, if a message is omemo encrypted or not

  84. vanitasvitae

    Might be better than to check the body

  85. edhelas

    conversations is adding the tag ?

  86. vanitasvitae

    Pretty sure it does

  87. edhelas


  88. Ge0rG

    lovetox: how do you configure PEP in Gajim? I've opened the "Configure services.." menu on my server, but there are no items listed and the buttons are greyed out, except for "Close"

  89. lovetox

    because your server does not support configuring nodes

  90. Ge0rG

    lovetox: would be awesome to have that displayed in that box

  91. lovetox

    yes once i rework the dialog, its still from ancient times

  92. Ge0rG

    Ah, the Good Old Times!

  93. pep.

    What happened about the LC on 345 BTW, did I miss any decision made about it?

  94. Ge0rG

    pep.: I suppose the Board needs to vote on advancing it next.

  95. Ge0rG

    Or maybe somebody can make a PR incorporating LC feedback

  96. Ge0rG

    dwd: I would kindly ask you to put https://github.com/xsf/xeps/pull/752 and XEP-0410 advancement on the next Council agenda. cc jonas’

  97. ralphm

    Ge0rG: with the Summit happening, we haven't had a meeting to discuss the LC feedback on XEP-0345 yet. Thursday is the first opportunity.

  98. Ge0rG

    pep.: ^

  99. Ge0rG

    There was also a Board PR that Council was asked to look into.

  100. goffi

    hey there. I was thinking this morning, it would be nice to have a QR code with my jid in it on my website, so people could get it easily from phone, and it would be nice to have a way to make it easy to recognise. It's possible to put an image inside QR codes, so would not it be nice to agree on something (e.g. putting XMPP logo inside) so we could know immediatly "OK this is a XMPP identifier"? Would it make sense to have an informational XEP on this?

  101. Ge0rG

    goffi: yes, you can increase the FEC on QR codes and then just bump some picture over the middle

  102. Guus

    sounds like a fun little shareable service.

  103. goffi

    Ge0rG: FEC?

  104. jonas’

    (forward error correction)

  105. pep.

    Wasn't it "the image isn't part of the standard, it's just ignored with error correction"

  106. Ge0rG

    goffi: forward error correction. Also related: https://github.com/ge0rg/easy-xmpp-invitation

  107. jonas’

    although I’% not entirely sure that’s the correct term for QR codes

  108. pep.

    hah, right

  109. jonas’

    although I’m not entirely sure that’s the correct term for QR codes

  110. goffi

    I know it's possible, that why I'm proposing it, we don't need much characters for a jid.

  111. Ge0rG

    jonas’: but it still is FEC.

  112. jonas’


  113. Ge0rG

    just because people invent new fancy names... 🤷

  114. pep.

    goffi, what do you want to do with "a JID"?

  115. pep.

    Add as contact?

  116. goffi

    pep.: yes

  117. goffi

    not only on website, on visit card too

  118. Ge0rG

    goffi: what if the person scanning the code doesn't have a Jabber client yet?

  119. goffi

    I just want a way to recognise immediately "oh this is a jid"

  120. pep.

    goffi, have a look at what Ge0rG pasted

  121. Ge0rG

    I'd put a Jabber lightbulb in it.

  122. pep.

    We can probably just put a QR code there

  123. goffi

    Ge0rG: it's the same issue with a xmpp:myjid@example.net link.

  124. pep.


  125. goffi

    my point is just to have a way to recognise the QR code as XMPP related.

  126. Ge0rG

    goffi: I've heard you are good at webdev.

  127. goffi

    using http or xmpp is an other thing. There are issues with http (you have to keep a service, and it won't be catched by registered client). But that's not the point of my idea, I just wonder if it would make sense to agree on a way to recognise XMPP QR Code (image inside is one thing, we could also play with colors).

  128. Ge0rG

    > it won't be catched by registered client yaxim will catch both yax.im and conversations.im landing pages

  129. goffi

    Ge0rG: what do you mean ? I'm working with web sometimes yes, and on a XMPP web framework.

  130. pep.

    I'd have a QR code with the XMPP logo (to add to the bikeshed discussions)

  131. Ge0rG

    goffi: the easy-xmpp-invitation project is looking for volunteers 😁

  132. goffi

    Ge0rG: and what I have gajim ?

  133. Ge0rG

    goffi: how do you scan images in Gajim?

  134. goffi

    Ge0rG: I would love to help on that, but I'm already close to burn out with my paid job + work on SàT + all side stuff (like preparing FOSDEM)

  135. Ge0rG

    goffi: alright, thanks anyway :)

  136. goffi

    Ge0rG: I was mentioning gajim for the contact link, a xmpp:toto@example.net will work there, https://yax.im/i/#vladimir@xmpp.example wont

  137. Ge0rG

    goffi: on my OS, Gajim doesn't handle xmpp: URIs

  138. goffi

    is it possible with QR code to have 2 links ? A http: one and a xmpp: one ?

  139. Ge0rG

    nope. But the landing page contains an xmpp: link ;)

  140. goffi

    what if the size is down ?

  141. goffi


  142. pep.

    Then it's down I guess

  143. goffi

    xmpp: will still work. I mean I get the point with https: link, and I agree on most of them, but the xmpp: is the standard way of doing, it's not linked to an entity, in short it has many advantages too.

  144. goffi

    it's not linked to a client or service*

  145. pep.

    goffi, what if your xmpp server is down

  146. Ge0rG

    goffi: it's got many advantages, but it doesn't work for normal people.

  147. pep.

    Will the other server resend the subscription request(?)

  148. goffi

    pep.: it won't prevent you to add the contact, after the subscription will happen when it will be up again.

  149. pep.

    goffi, ok. I wouldn't mind having the xmpp: uri in there, but then you only target people already present on xmpp

  150. goffi

    best way would be to find a way to have both in a easy way, but doesn't looks like possible.

  151. pep.

    (I agree we're mixing two issues, but I don't know how to entangle them)

  152. mtavares

    have two qr codes...

  153. mtavares

    just to make it more complicated.

  154. pep.

    mtavares, I think that's be even more confusing

  155. mtavares

    using a http link works well enough, me thinks.

  156. pep.

    "So which one is it??" "It's the same" "Why do you have two then?" -- my mom

  157. goffi


  158. goffi

    it seems possible

  159. mtavares

    ahh.. interesting.

  160. pep.

    goffi, it's just text right, you put whatever format you want in there

  161. jonas’

    pep., QR codes have multiple subformats for different payloads

  162. pep.

    I see

  163. jonas’

    partly because they use different codes for different payloads to save bits

  164. pep.

    And of course this website only accepts URLs

  165. pep.

    not XMPP URIs

  166. goffi

    ah it's just redirecting and shows the 2 links

  167. goffi

    pep.: yes I know, but the QR code readed need to know how to handle both.

  168. mtavares

    it's just a https link to qr-creator.

  169. goffi

    mtavares: yes, so not good :(

  170. Ge0rG


  171. Ge0rG


  172. goffi

    I like more the second one

  173. goffi

    it's neat :)

  174. pep.

    yeah me too

  175. Ge0rG

    This is the moment to complain about our well-known marketing name being absolutely burned, and our official protocol name being too technical for regular people.

  176. pep.

    Maybe just remove the "XMPP" from there

  177. pep.

    So you don't have to pronounce it.

  178. goffi

    yeah the logo only is fine I think

  179. goffi

    also I think the text could be used for something else.

  180. goffi

    for instance, would it make sense to distinguish QR Code depending on their use: for instance a contact to add, or an ad-hoc command to execute, or a pubsub service ?

  181. goffi

    so you would but the XMPP logo, and "contact" under it instead of "xmpp"

  182. Ge0rG

    did I mention that normal people in our region consider QR codes as something awkward?

  183. goffi

    why ?

  184. Ge0rG


  185. goffi

    nearly everybody is getting use to it, it's a nice techno

  186. Ge0rG


  187. ta

    I have it on my applications as vCard. I still hope some technical employer finds it nerdy.

  188. Ge0rG

    ta: do you have a utm tag in it?

  189. ta

    well, i don't have a link in it, so no...

  190. ta

    I mean application as in paper/pdf. QR-code being just contact information as vcard.

  191. ta

    But i should consider tracking when applying at some online shops. they like everything i try to block ;-)

  192. lovetox

    woever wrote me a pm here, i cant answer because converse does not support pm 😃

  193. ta

    <-- is just asking about the gajim muc not beeing reachable from some servers.

  194. lovetox

    ta, would be interested what the error is

  195. lovetox

    im joined and im on jabber.at currently

  196. ta

    if you guide me. gajim and xml console didn't give me much feedback.

  197. ta

    you can guess my JID, so we don't spam here. I am using trashserver.net (no comments on that name ;-)

  198. lovetox

    but it should, restart gajim open xml console, join the muc and maybe wait for 1 minute, whatever the servers timeout is, at one point your server should inform you why its not possible to connect

  199. lovetox

    otherwise ask the admin

  200. Zash

    lovetox: Looks like a IPv6 problem, please try to fix it.

  201. lovetox

    can you be more specific

  202. lovetox

    im not the server admin, but i can tell him

  203. Ge0rG

    If only XMPP servers could gracefully support both IPv4 and IPv6

  204. Ge0rG looking at Zash

  205. Ge0rG

    lovetox: traceroute to conference.gajim.org (2001:bc8:342f:101::1), 30 hops max, 80 byte packets ... 5 * * * 6 2001:bc8:400:1::8e (2001:bc8:400:1::8e) 27.964 ms 28.068 ms 28.263 ms 7 2001:bc8:400💯:26 (2001:bc8:400💯:26) 25.912 ms 26.035 ms 26.204 ms 8 * * * ...

  206. Zash

    Ha. Blame Link Mauve

  207. Ge0rG

    Zash: is he behind gajim.org?

  208. Link Mauve

    No I’m not.

  209. Zash

    No, why I bumped a timeout back up to the point where it gives up completely before trying the next IP

  210. Ge0rG

    Zash: you bumped Link Mauve?

  211. Ge0rG

    can't you unbump him?

  212. Zash

    Link Mauves toaster was too slow for the low timeout

  213. ta

    Well is this the cause already? I restarted gajim, have a very spammy xml console...

  214. Ge0rG

    Zash: can't you also increase the *other* timeout then?

  215. Ge0rG

    Zash: it's a bit shortsighted to break connectivity for all users of prosody just because of Link Mauve

  216. lovetox

    ta i reported it to asterix but will not be fixed immediatly

  217. Zash

    Actually, this specific configuration still works because the write timeout here is 60s and the "give up completely" timeout is 90s

  218. Zash

    But ... this varies

  219. dwd

    Hi all. Do we have an incremental update for disco#items and things? I've a feeling that Sem Whited documented something that HipChat did a while back but I can't find it.

  220. jonas’

    what do you mean by incremental update?

  221. ta

    lovetox, thanks. No hurry. I was just surprised that nobody "cared" in all the other XMPP-centric MUCs ;-)

  222. dwd

    So if I have cached, for example, all the disco#items, and I now want to find what's changed instead of downloading the entire list again.

  223. dwd

    Sorta like XEP-0237 for Disco.

  224. Zash

    lovetox: The prosody module mod_bidi might help a bit, since it reduces the number of connections that can fail

  225. Zash

    dwd: Isn't that caps?

  226. Zash

    Or you want caps on ... things?

  227. Zash

    Or disco-sub or whatsitcalled?

  228. dwd

    Not caps. Though caps on ... things would be nice, actually - good plan.

  229. dwd

    But caps doesn't do disco#items.

  230. Zash


  231. Zash

    Did caps2 do that?

  232. Zash

    I'm sure we discussed some semi-recursive caps thingy recently

  233. dwd

    But yeah, if I have 1.2 quadzillion MUCs, I'd like to just fetch the three new ones and not the 1.2 quadzillion over again.

  234. jonas’

    caps isn’t really incremental, either

  235. Zash

    Yeah. Figuring that out would be nice.

  236. dwd

    jonas’, Yes, indeed.

  237. jonas’

    disco#items versioning essentially

  238. dwd

    I can't recall if we decided that Sam's proposal should be a XEP or even if he submitted it.

  239. Zash

    I was leaning towards not returning complete results in disco#items at all and defering to some search interface

  240. jonas’

    I don’t recall anything in that direction

  241. Ge0rG


  242. Zash

    I only recall that there was "disco-(pub)sub"

  243. dwd

    But otherwise, I'll do a ProtoXEP based around '237's design if there's interest.

  244. dwd

    Ge0rG, RSM is good for paging, less good for incremental update.

  245. Zash

    RSM is also weird if items can be removed

  246. Guus

    dwd hipchat has a couple of features documented here https://docs.atlassian.com/hipchat.xmpp/latest/xmpp/rooms.html

  247. Guus

    the room push comes closest to what you describe

  248. dwd

    Or... I could do it based on pubsub, and then list disco#items things in a pubsub node... somewhere.

  249. Guus

    (it also does something with service discovery - but that does not seem to match your description)

  250. Zash

    dwd: But if you have 1.2 quadzillion MUCs, having a cache of them locally is probably not fun anyways

  251. Ge0rG

    dwd: did we solve the multiple-items-per-node pubsub problem yet?

  252. Zash

    Ge0rG: What problem is that?

  253. dwd

    Zash, True, but I have a way of having a set of MUCs I'm interested in anyway. The problem is that I have a lot of them.

  254. dwd

    Zash, Also, caching 1.2 quadzillion items is not fun, but fetching them anew every time is even less fun.

  255. jonas’

    dwd, wouldn’t some type of search interface make more sense then?

  256. dwd

    Perhaps, but I do have a few cases where I want all the disco#items.

  257. flow

    dwd: I am not sure, but you are maybe looking for https://xmpp.org/extensions/xep-0366.html

  258. flow

    But I guess for a delta sync of disco#items you probably want something like disco#items versioning…

  259. Zash

    How many implement the incemental roster versioning thing?

  260. ralphm

    dwd: having a pubsub node to represent available channels would definitely be interesting.

  261. ralphm

    dwd: with RSM, it would be much easier to keep lists on the client side in sync.

  262. ralphm

    We kind of already have a specification for this with `pubsub#subscription_type` with the value of `nodes`, and using that in subscription options towards the root node.

  263. Ge0rG

    dwd: did you receive my message further above regarding Council Agenda additions for tomorrow?

  264. ralphm

    https://xmpp.org/extensions/xep-0248.html#notify-items suggests there's a `<create/>` element in pubsub#event to be used for notifications, but the schema in XEP-0060 doesn't current have that.

  265. goffi

    I have no time to check it now, but is not this RELOAD protoxep doing something similar to jingle?

  266. Zash

    Based on what dwd wrote, I wonder if it's rather something for the IETF?

  267. ralphm

    Too bad the date on the inbox entries are all from yesterday.

  268. debacle

    goffi, to me XOR looks more like 0174 (Serverless), but with NAT traversal

  269. jonas’

    XOR depends on '174 AFAICT

  270. goffi

    OK, I've just overlooked and it looked like a way to establish a stream.

  271. goffi

    interesting then, I'll check that later.

  272. dwd

    Ge0rG, I've not noticed it, and would welcome an email. Travelling tonight at short notice, and I'll try to do the agenda stuff on the train.

  273. Ge0rG

    dwd: sure thing

  274. dwd

    So, XEP-0366 is more or less what I was after. I think including caps, though, is probably interesting too.

  275. Zash

    "I have stuff with caps hash xxxx, what's changed since?"

  276. Zash


  277. MattJ

    oh no

  278. MattJ

    > Appendix A. Changes from Unicode 6.3.0 to Unicode 7.0.0 > Changes from derived property value UNASSIGNED to either PVALID or DISALLOWED.

  279. Ge0rG

    In the context of RELOAD, I'd suggest defining an XMPP wire-format to exchange X.509 CSRs and CRTs, which could be immediately plugged into a XMPP JID-identity CA

  280. dwd

    Zash, No, caps can be an all-or-nothing for disco#info. But it'd save me a huge amount in this particular instance. I think an entityver thing would help with disco#items, though.

  281. ralphm

    MattJ: so RFC 7622 will need an update?

  282. pep.

    ralphm, thinking about <gone/> again for <moved/>, and MUC affiliations/PubSub subscriptions. I can't just return <gone/> for everything that comes pinging my account for privacy reasons. And my server doesn't know (could know, but allegedly doesn't track) these subscriptions, so..

  283. ralphm

    Well, if you want to leave some kind of tombstone, but only to selected people, you kinda have to keep the former relationships, whichever way.

  284. pep.

    It will work for contacts, because we have the roster

  285. pep.

    But that's about the extent of what the server keeps track of, in the general case

  286. ralphm

    I suppose for pubsub subscriptions it might be harder indeed.

  287. jonas’

    and MUC affiliations

  288. pep.

    Not even talking about server shutting down etc. yet

  289. ralphm

    But this is one of the reasons why dwd suggested PAM, so that your server keeps track for you. When you move, you could take that with you.

  290. pep.

    (I'm thinking about not considering this use-case for a first rewrite of <moved/>)

  291. pep.


  292. ralphm


  293. Ge0rG

    pep.: the hard question with roster is how to tell multiple clients of your friend, if the first client will replace unsubscribe your old JID.

  294. pep.

    Ge0rG, yes I got that, you don't have to repeat it over and over, that wasn't the question

  295. pep.

    I know we need a tombstone of some sort, and that was discussed

  296. Zash

    pep.: This came up at summit, about needing to keep the roster, or maybe some magic hash of it

  297. pep.

    Zash, "this"?

  298. Ge0rG

    you could create a PEP node with a whitelist populated with your roster when moving.

  299. Ge0rG

    pep.: what's the question then? Who is allowed to see your tombstone? Either everyone or old-roster-only, I suppose

  300. pep.

    Ge0rG, no that wasn't the question

  301. pep.

    Ah well, yes sorry

  302. pep.

    But not for the roster

  303. pep.

    I'm asking for muc affiliations and pubsub subscriptions (read the question)

  304. Ge0rG


  305. ralphm

    so couldn't you whitelist the muc services on your bookmark list (private storage or PEP) and the pubsub nodes you have received notifications from?

  306. Ge0rG

    there is no way to enumerate all your MUCs and PubSub subscriptions, unless your PAM keeps track of them all, from day 1

  307. pep.

    Using bookmarks for MUC seems interesting

  308. pep.

    But yeah for PubSub we'd need PAM or sth

  309. Ge0rG

    bookmarks probably contain the relevant subset (what do you care if you are affiliated with a MUC you never joined)

  310. ralphm

    *also*, besides leaving a tombstone, there's no reason why you couldn't send a presence with forwarding address

  311. pep.

    presence is ephemeral

  312. ralphm

    not for muc rooms

  313. Ge0rG

    it might suffice to let PubSub and MUCs know.

  314. ralphm

    i.e. you only need to have it received once

  315. Ge0rG

    but you don't know where to send, in the first place

  316. pep.

    Technically the server can know

  317. pep.

    But yes that has to be done from day1

  318. ralphm

    wouldn't you likely cover this by the list of muc servers that you frequent rooms of?

  319. ralphm

    unless 100% is your goal, in which case good luck

  320. jonas’

    gateways & transports are another topic

  321. pep.

    I would hope services GC after some time being unresponsive

  322. jonas’

    a tricky one, actually

  323. jonas’

    I wouldn’t want to loose my biboumi MAM because I moved accounts

  324. pep.


  325. pep.

    We're really trying to sort all the problems in the world at the same time :/

  326. pep.

    This thing is never going to progress

  327. jonas’

    I’m calling it "enumerating"

  328. jonas’

    I don’t expect your proposal to solve all of them

  329. pep.

    jonas’, I guess it's time for a client-side MAM? :/

  330. jonas’

    but it should enumerate them all, and clearly distinguish between those which are solvable and solved, those which are likely solvable and deferred and those which are not likely solvable

  331. jonas’

    client side MAM?

  332. pep.

    So that you can just ditch the server archive once you've fetched it, and then have your mobile ask your desktop client for archives

  333. jonas’

    yea, no

  334. pep.

    Why not

  335. jonas’

    I don’t want to implement the server side of MAM things in a client

  336. jonas’

    huge complexity, especially with Smart MAM ahead

  337. pep.


  338. jonas’

    (and how about the clients which have the "I don’t want to store everything locally anyways" philosophy)

  339. pep.

    It's really not the first time I hear about it though

  340. jonas’

    yeah, you hear from it mostly from crypto fashionistas

  341. pep.


  342. jonas’

    who want to solve the PFS problem with a huge pile of complexity

  343. Ge0rG

    ...and then end up talking with people who just dump everything into sqlite

  344. pep.

    Anyway, this is not a crypto party, the topic is different

  345. Ge0rG

    but you can't just just expose your new JID to every entity that claims to be a pubsub node.

  346. jonas’

    in any case, client side MAM won’t solve the biboumi case

  347. jonas’

    you don’t want to have that all stored on your phone anyways

  348. pep.

    jonas’, it would yes? I think

  349. ralphm

    I see this problem as moving house. You let your friends know. In the Netherlands you have a service that informs (selected) entities of your new address so they can update their records. Also, the occupant typically temporarily forwards stuff to you.

  350. ralphm

    (new occupant)

  351. ralphm

    You never reach 100%, and that's fine.

  352. pep.

    Right. So we're inevitably going to drop mail, but yeah it's fine

  353. pep.

    They'll recontact us, (or not)

  354. ralphm

    And the rest of it is usually a thing you solve socially, out of band, not technically.

  355. pep.

    Ge0rG, would you be ready to compromise on that <moved/> thing, or do you want to get all the use-cases into the one XEP

  356. pep.

    If so, I'll split efforts because I'd like to have something ready by 2025 not 2030

  357. pep.

    (I'm being generous)

  358. Ge0rG

    pep.: you know, I was like you, back then in 2018. I thought "how hard can it be". But then I started work. And I realized...

  359. Ge0rG

    So, what exactly do you want to compromise?

  360. Zash

    pep.: privacy problem of gone, needing to keep the roster

  361. Ge0rG

    Also persistent PEP with a configurable access model.

  362. pep.

    I want to drop the "My server is offline" use-case. I am not sure I'll be able to support "My server is scheduled for shutdown" entirely either, because we need tombstones

  363. pep.

    But I guess if your server shutdown is planned in 6 months time, that's already quite enough time to migrate most of your contacts

  364. Ge0rG

    pep.: do you want to drop muc affiliation and pubsub?

  365. pep.

    I don't know. At the moment I see it as something the server will have to keep track of for us, unless you have a client-side solutions

  366. Ge0rG

    Do you want to support users migrating from prosody < 0.11?

  367. pep.

    non-persistent PEP?

  368. pep.

    No I don't care

  369. pep.

    People please update.

  370. pep.

    Well, there is MAM, I can do with that if you really want

  371. Ge0rG

    A cryptographic identity overlay network that works over XMPP as the routing layer

  372. pep.

    yeah no thanks

  373. pep.

    I wouldn't mind trying to make it future proof, as in, compatible with a possible crypto thingy that would come on top, if that's possible. But I'd like to have something out soon

  374. pep.

    Actually PEP/MAM are not necessary if we do <gone/>, on the old server.

  375. Ge0rG

    The old server must support it then.

  376. Ge0rG

    Also access permissions

  377. pep.

    The old server must support RFC 6120?

  378. pep.

    I hope it does

  379. pep.

    Ah ok I see

  380. pep.

    hmm, we can prompt for support, and if not fallback(?) how is that

  381. Ge0rG

    > Also access permissions

  382. Ge0rG

    Is there a protocol to *configure* gone on your account?

  383. pep.

    Yes, we can prompt for support on the old server, and if not PEP/MAM?

  384. pep.

    We talked about adding that to IBR, so that'd be a new thing indeed

  385. MattJ

    The problem with PEP is that it needs to be explicitly checked or subscribed to, and works on a client level

  386. Ge0rG

    So you'd say the default access permissions for <gone/> will be the user's last roster?

  387. MattJ

    <gone> errors in response to probes are much nicer

  388. MattJ

    But do require support from the migrating server

  389. pep.

    MattJ, sure, they all require support on different level..

  390. pep.

    *Somebody* has to support *something* :(

  391. Ge0rG

    pep.: sending messages to all your contacts doesn't.

  392. pep.

    Ge0rG, yes, clients need to understand MAM, and the moved payload

  393. Ge0rG

    pep.: I wanted to make a protocol that gracefully degrades if it's only supported by clients on both sides.

  394. pep.

    How far did you get

  395. Ge0rG

    pep.: messages with a moved payload from the old and from the new account. MAM / Carbons on the receiving side as faux persistence.

  396. pep.

    (all these french words)

  397. Ge0rG

    pep.: maybe a private PEP node on the receiving side where the first client can store the Moved from-to pair

  398. pep.

    yeah I remember these discussions, and I'm fine with that

  399. pep.

    I thought that was dealt with already

  400. Ge0rG

    But then there is a nice race condition on populating that PEP node.

  401. Ge0rG

    pep.: not written down yet.

  402. pep.

    Ok, let's do it then

  403. Ge0rG

    pep.: you want to continue the work? I can commit and push my last sad state.

  404. Ge0rG

    A compliant server could process a Moved PEP node on your account, and send a gone error to entities that are allowed to read that pep node

  405. Ge0rG

    Or maybe always send the gone, but only fill the JID if permitted.

  406. pep.

    yeah that's details to me at this stage

  407. pep.


  408. Ge0rG

    pep.: https://github.com/ge0rg/xeps/tree/xep-0283

  409. Ge0rG

    that's the code behind the rendered version I forgot to tell you before Summit.

  410. pep.


  411. pep.

    I wouldn't actually mind only including compliant servers or clients in my assumptions, tbh

  412. pep.

    Deployment is an issue, and we all know that. My goal is not to solve this. (/me eyes non-rolling release distributions)

  413. moparisthebest

    but a feature that only requires clients to upgrade will be adopted faster, especially if users want it, because it's fully under their control

  414. pep.

    But their contacts also need to support it

  415. pep.

    So maybe not that fast

  416. moparisthebest

    not if they can fall back

  417. moparisthebest

    like 'oh you don't support automatic roster migration? ok send message "hi I was x@x now I'm y@y"

  418. Ge0rG

    with the main reason for this being "abandonden servers" I'd pull the line at modern client support

  419. pep.

    Ge0rG, it's not my main reason fwiw

  420. pep.

    My main reason is services like quicksy, or any other public services, which are great for adoption, but then users might want to move away from that

  421. Ge0rG

    I've heard there are ~250 users on Quicksy.

  422. pep.


  423. pep.

    "or any other public services"

  424. moparisthebest

    then it has to be a client-only feature

  425. pep.

    moparisthebest, why does it have to

  426. moparisthebest

    public services that don't want people to move away would just never enable it?

  427. moparisthebest

    especially if they get $ from users, directly or data mining (google)

  428. pep.

    Yeah I'm not considering evil services tbh, that's another can of worms

  429. moparisthebest

    I'm not talking about evil

  430. pep.

    Why would they block then

  431. moparisthebest

    client-only doesn't work with actively evil either, they can block stanzas etc

  432. pep.


  433. pep.

    Any server can just block the PEP node

  434. moparisthebest

    I'm talking about "should I download and install/configure this plugin that makes it easier for users to leave?"

  435. moparisthebest

    why would they do extra work for that?

  436. pep.

    moparisthebest, if it's a PEP node it's no extra work

  437. moparisthebest

    so that's client-only?

  438. pep.

    PEP is not client-only no

  439. pep.

    Neither is MAM. They all require server support

  440. moparisthebest

    yea but it doesn't require specific server support is all I meant

  441. pep.

    Yes it does

  442. moparisthebest

    not for this specific thing

  443. moparisthebest

    just PEP in general that's used for lots of other things?

  444. pep.

    Yes yes

  445. pep.

    So here's your reason why they would set it up

  446. pep.

    So the feature can require server support

  447. moparisthebest

    yea that all sounds fine then

  448. moparisthebest

    I just meant if it required all servers to upgrade before it was useable, it'd be worthless and never adopted

  449. moparisthebest

    think MIX

  450. pep.

    Well there are still prosody < 0.11 out there, and it's going to be the case for a while

  451. moparisthebest

    so you are, vaguely, publishing a pep node as old@old.com saying you've moved to new@new.com ?

  452. pep.

    Yeah. And that tombstone should stay up for your contacts' devices to see.

  453. moparisthebest

    I tended to like what Ge0rG called a 'cryptographic overlay' better, it's maybe a bit more complicated, but not too much

  454. pep.

    I don't mind having that as a goal for later, in a different XEPs, with different goals (including moar uses-cases)

  455. moparisthebest

    vaguely, you publish a public key, your contacts save this (public key for old@old.com), then if a new account sends a subscription request with a message "I was old@old.com but now am new@new.com" signed by old@old.com's key, you know to update it

  456. moparisthebest

    not that much more complicated, supports everything that does plus the (I would think) common usecase of a server disappearing

  457. pep.

    You don't actually need crypto fwiw

  458. pep.

    Except if your old server is _already_ offline

  459. pep.

    But then you're probably not in a good position anyway

  460. moparisthebest

    that seems like a valuable usecase to support though

  461. pep.

    Yeah, I'm not worried about it for now, but you're welcome to

  462. moparisthebest

    so is yours, uh, lazy

  463. pep.

    And you should have preemptively declared your key if that's the case

  464. moparisthebest

    it relies on all your contacts checking your old PEP node every time?

  465. pep.

    They can check it once and be done

  466. moparisthebest

    once every time the client connects or?

  467. pep.

    Once they've acked it

  468. moparisthebest

    it doesn't react to being sent a message though?

  469. pep.

    I don't understand

  470. moparisthebest

    it checks pre-emptively for all roster contacts?

  471. pep.


  472. moparisthebest

    your client

  473. pep.

    Yeah, you +notify on the node

  474. moparisthebest

    so when a client logs in it has to check them all too I guess

  475. pep.


  476. moparisthebest

    xep-27 already announces a key even, 'moved' could just define a signed payload for "I've moved"

  477. moparisthebest

    seems far simpler

  478. moparisthebest

    > so when a client logs in it has to check all pep nodes for all roster contacts all too I guess

  479. pep.

    A client doesn't "Check", notifications gets pushed to it, but sure

  480. moparisthebest

    even notifications sent before the client logs in?

  481. pep.

    Sure, you say add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event

  482. pep.

    Sure, you add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event

  483. moparisthebest

    if I understand it's just adding a bunch more login traffic, at least one extra outgoing stanza and an ack per contact?

  484. moparisthebest

    vs the key thing, which supports all the same use-cases, plus missing server, with no extra login traffic?

  485. pep.

    There's no extra login traffic if there's no event. And once you've seen the event on contactX, you can unsubscribe from it.

  486. pep.

    what key thing

  487. moparisthebest

    crypto signed "i've moved" roster subscription messages from the contact that moved

  488. pep.

    But then in my use-case you'd need an extra PEP node on your own account mapping old-jid -> new-jid of your contacts, so that all your devices can ACK.

  489. pep.

    Then you do that from MAM?

  490. pep.

    You can also use MAM without crypto. And that's how Ge0rG implements it for now in his draft

  491. moparisthebest

    isn't the roster stored on the server? can't only 1 client change it then?

  492. moparisthebest

    technically the server could change it and not involve clients

  493. pep.

    So what's your use-case then, do you want the server to be involved or not

  494. moparisthebest

    that server involvement would be optional, on the non-moving client's end?

  495. moparisthebest

    wouldn't need to be mentioned in the XEP, the server could just optionally do it instead of the client

  496. pep.

    That can be mentioned in the XEP yes, and we already had something like that in mind.

  497. moparisthebest

    I tend to think moved that doesn't support a server going away in the future wouldn't be very useful

  498. pep.

    I think it is

  499. pep.

    And that'd be my main use-case

  500. moparisthebest

    my point is that if you do it a slightly different way, it supports both use cases

  501. pep.

    "slightly" meaning crypto?

  502. pep.


  503. moparisthebest


  504. moparisthebest

    you aren't inventing primitives or anything scary, just signing a message and verifying a signature?

  505. pep.

    You don't need crypto for most of what you just said

  506. pep.

    If your use-case if "server going away in the future", you don't need crypto

  507. pep.

    As your identity provider is still alive

  508. moparisthebest

    ok let me clarify, I mean "I'm gonna go ahead and publish this now, and still want to be able to use it to move if my server goes away in the future"

  509. pep.

    publish where

  510. moparisthebest

    either signed presence like xep-27 or a PEP node?

  511. pep.

    Ok so what about non-supporting contact clients (which is a concerned that's been raised), at the time you published it, until you server went down

  512. pep.

    Also presence won't work, it's ephemeral

  513. moparisthebest

    but you could save the key from the first presence you see or something, in your client

  514. pep.

    If you support it, sure

  515. moparisthebest

    non-supporting clients I think is the same regardless of method, if they don't advertise support, your client sends them a manual message?

  516. pep.

    And if you see it, in the first place

  517. moparisthebest

    (after it moves I mean)

  518. pep.

    Which is why I just don't want to worry about this use-case. With the current changes we have in moved, nothing prevents you to also publish your signed payload