XSF Discussion - 2019-09-09


  1. Guus

    > any of our france friends here in contact with the person? Flow, the person that took over the project got in touch with us, to get it listed at the website again.

  2. Guus

    https://github.com/xsf/xmpp.org/pull/592

  3. Ge0rG

    This is frightening.

  4. Ge0rG

    Admittedly, the README is not the first place to change when resurrecting a new project.

  5. Daniel

    What is that the left overs of that Google thing?

  6. Daniel

    Wave

  7. Daniel can't be bothered to follow the link

  8. jonas’

    Daniel, it’s an xmppd

  9. ralphm

    https://ralphm.net/blog/2019/09/09/fastening

  10. ralphm

    Discuss.

  11. jonas’

    fasten your seatbelts

  12. ralphm

    Indeed

  13. ralphm

    It is a long piece based on recent discussions and took me more time than I anticipated. Plenty examples!

  14. flow

    +1 for examples

  15. ralphm

    :parrot:

  16. wurstsalat

    ralphm: thank you for taking the time to write this up (also +1 for :parrot:)

  17. ralphm

    wurstsalat: you're welcome!

  18. pep.

    It's funny because I was taking part in a discussion this morning about XMPP in general on a Japanese channel, and they were saying it's not easy to get people off LINE (which is the defacto whatsapp-like app there), whereas here in our european (XSF?) circles, most of the time I hear about Slack, twitter etc.

  19. pep.

    Reading your article made me think of that

  20. ralphm

    Sure. Another example is WeChat, but I think most of my audience is from the so-called Western world.

  21. ralphm

    I also forgot to mention Facebook Templates.

  22. pep.

    <mention jid="room@muc.this.example/ralphm"/> btw, what about occupant-id?

  23. ralphm

    You mean making it more explicit what kind of jid is referred to?

  24. pep.

    no I mean https://xmpp.org/extensions/xep-0421.html

  25. pep.

    It'd be nice if that was also allowed in there

  26. pep.

    Not especially mandated

  27. pep.

    I know some people will oppose the de-pseudonymisation

  28. pep.

    Also what do people have with this "@" :x

  29. pep.

    Quite annoying to see this on the wire everywhere

  30. ralphm

    I'm not sure, I haven't read that in detail.

  31. ralphm

    Also curious how it'd be different in MIX

  32. MattJ

    pep., that's why the "proxy JIDs for MUC" idea would be slightly better, since it's a drop-in replacement for a real JID

  33. ralphm

    pep.: I don't see a problem with @. It would be something people type and a client could choose to strip it with references.

  34. pep.

    MattJ, yeah.. I see that

  35. MattJ

    Nobody (generally) has to know what kind of JID it is, it's just a JID

  36. ralphm

    MattJ: right, and for the rest there is disco

  37. pep.

    ralphm, I see a problem with @, why would we even bother to have a <reference/><mention/> tag otherwise? Why not just put @ralphm in there and let the receiving client deal with it

  38. pep.

    Client SHOULD NOT include any marker in the body for this

  39. pep.

    There is no point

  40. pep.

    On the wire, that is

  41. ralphm

    It could, but the thing prefixed by @ can be interpreted by a server. Maybe it has a nick registration service and allows for referencing non-accupants.

  42. pep.

    Maybe then the service can also read <reference/> instead

  43. pep.

    I'm going to start including @s everywhere just to make fun of that service

  44. ralphm

    My examples show that the original didn't have a reference

  45. pep.

    It's about the same crap idea as 393.

  46. ralphm

    Let's agree to disagree on this point.

  47. pep.

    You agree that this is a character that carries meaning, no?

  48. pep.

    I mean essentially that's the goal

  49. ralphm

    By the way, the @ might also serve as an explicit marker to notify whoever is mentioned, as apposed to unprefixed strings that happen to also be a nick. Like someone having a nick 'nick'.

  50. pep.

    That can be done in the input format yes

  51. pep.

    Doesn't have to be on the wire, again.

  52. ralphm

    My vantage point is a thin(ner) client

  53. ralphm

    And not touching what the user typed

  54. pep.

    What about them? They shouldn't have to care about semantics and throw everything in body because?

  55. pep.

    Why do we even bother with <reference>, somebody remind me please

  56. ralphm

    Or XMPP

  57. pep.

    Or XMPP

  58. pep.

    Let's not take Slack as an exemple, it's an implementation not a protocol, and it doesn't try to be compatible with anything else

  59. ralphm

    I think it is useful, you may disagree, and the post shoes how it could be done.

  60. pep.

    Of course references are useful. I was saying that because of your loose use of "@"

  61. ralphm

    I do take Slack as an example, as it is done well and we can learn from it.

  62. ralphm

    So @pep. if you don't like @'s, I am not sure what to do about it.

  63. pep.

    .

  64. pep.

    I don't like the meaning you attach to it

  65. pep.

    On the wire

  66. ralphm

    I didn't. It is something somebody typed and the MUC service then interpreted it as a mention. Has nothing to do with the wire protocol.

  67. pep.

    "Here the MUC service marks up the original messages with an explicit link reference." wait

  68. pep.

    Yes I just read that

  69. pep.

    That's even more awful than I thought

  70. pep.

    So yes you did

  71. pep.

    ugh

  72. ralphm

    I'm sorry I broke your world. I'm a terrible person.

  73. pep.

    I'm actually amazed you are seriously considering this

  74. pep.

    To put it as an exemple

  75. ralphm

    Seriously, this is exactly how existing services do things. It is not something*I* invented.

  76. pep.

    services like? Slack?

  77. Kev

    It's not even an example ralphm wrote, it came from my gist. I think getting caught up on what hypothetical service the example shows isn't the right thing here.

  78. pep.

    Kev, it's just that I see this coming back often

  79. jonas’

    ralphm, I’ll dump a bunch of random thoughts on your article on-list

  80. jonas’

    I can’t follow xsf@ right now

  81. Kev

    @pep: Because it's something easy to understand for examples.

  82. ralphm

    Also Twitter, as mentioned at the top of my post.

  83. ralphm

    I think WeChat, as well. WhatsApp, Facebook, etc.

  84. pep.

    ralphm, yes and as I said, they're not interoperable protocols, they don't care. they don't especially have to account for let's say, offline users that the MUC doesn't know about anymore (how would it know it has to have a reference there?) etc.

  85. pep.

    Or for me using @ in a totally different way

  86. pep.

    The UX in these product is particularly annoying when you just want to use @ and not highlight anybody

  87. pep.

    The UX in these products is particularly annoying when you just want to use @ and not highlight anybody

  88. pep.

    But I guess that's a UI issue anyway, for this last message

  89. pep.

    They still could do that and not include it on the wire

  90. pep.

    Kev, also my nick is "pep." :)

  91. pep.

    But I guess you can't autocomplete anymore with the @ in front :p

  92. ralphm

    Well, MUC's model is rather dated, and I think we need to move on from it. I think MIX solves a bunch of that, and I always try to look ahead, while learning from others. For this I don't care about how Evil those other entities or solutions are. Something like an @-mention is near ubiquitous outside our little bubble and I think the least-surprise angle works in its favour.

  93. pep.

    I'm going to repeat myself: That doesn't mean it has to be on the wire.

  94. pep.

    That's my only concern

  95. ralphm

    Really, it is just something somebody typed.

  96. Kev

    IT'S AN EXAMPLE IN A BLOG POST.

  97. pep.

    With an associated meaning to it

  98. pep.

    No it's not just an example.

  99. pep.

    It's definitely not the first time I see it. I even mentioned it last time when there was this references discussion.

  100. ralphm

    If you don't want your service to interpret @ signs, hack it to oblivion.

  101. pep.

    Of course I don't, why would I. My service could interpret <references> very well though

  102. ralphm

    Great

  103. ralphm

    Do you have any other insights?

  104. pep.

    .

  105. pep.

    whatever

  106. jonas’

    sent my feedback on the list

  107. ralphm

    Cool. Thanks!

  108. ralphm

    Also, I am a bit done with negative attitudes.

  109. ralphm

    So, sorry if I was a bit harsh, pep.

  110. jonas’

    I’m gonna re-state it publicly: Thanks for taking the time for the blog post, I think it’s very valuable. My mail on-list is concise and short to save everyones time, but there needs to be time for praise for work done, ralphm.

  111. ralphm

    ☺️

  112. Ge0rG

    ralphm: thanks for taking the time and moving things forward!

  113. pep.

    fwiw I have not much to say about references in the article, that looks good.

  114. ralphm

    👍

  115. pep.

    I know some people were not particularly fond of the mandatory <reference> for SIMS, but in this case it makes sense to me. I guess having SIMS being used instead of oob as it currently is could not require it, though?

  116. ralphm

    Yeah, my thing with oob is that it is very unspecific.

  117. pep.

    Sure. I'm talking about SIMS specifically, I'm not fond of the current practice

  118. pep.

    (with oob)

  119. ralphm

    Using a jingle file allows for thumbnails and hash references and titles and descriptions, etc.

  120. ralphm

    I suppose you could also have a naked one, without body and without the references wrapper

  121. ralphm

    If you just wanted to send a picture

  122. pep.

    Yeah, that's a concern I've heard multiple times

  123. Ge0rG

    ralphm: this is a major use case

  124. pep.

    Re Jingle, there's no URI format atm right?

  125. pep.

    Or is there?

  126. Zash

    ralphm, do you by any chance have a source format for that post publicly anywhere?

  127. ralphm

    Zash: not automatically, no. But I uploaded the source for this post here: https://ralphm.net/~ralphm/tmp/2019-09.xml. I hope you can appreciate it.

  128. Ge0rG

    let's bikeshed about the use of XML as a source format!

  129. ralphm

    Not just any XML format. It is actually very much derived from DocBook XML

  130. Zash

    In this case it doesn't reduce the effort in turning it into epub

  131. Zash

    DocBook enough that pandoc can read it?

  132. ralphm

    It does. You can use pandoc with docbook as input format

  133. ralphm

    But you'd have to fix the custom additions

  134. Ge0rG recently successfully converted a PDF ebook into epub, and even was able to remove the nasty-watermark-on-each-pdf-page with sed.

  135. ؜

    ralphm, hi, someone friendly has linked me your post on @mentions. i remember a certain discussion in the gajim chatroom >10 years ago. gajim at the time was highlighting the user if any part of a message contained the user's nickname (iirc). so if someone had a nickname of "kate", someone typing "skateboarding" would trip the highlight. gajim changed that to match a fixed word (iirc it was '\bkate\b'), and then people started complaining that declension happens (e.g. "kate's"). do you think you could make @mentions somehow work with that?

  136. jonas’

    what the

  137. ؜

    oh, hi jonas!

  138. pep.

    jonas’, indeed

  139. ralphm

    jonas’: you scared from my log source?

  140. Ge0rG

    what are you, a RTL modifier?

  141. jonas’

    ؜, noone will read what you wrote. your nickname is empty, that baffles everyone

  142. ؜

    that would be impolite… 😛

  143. Ge0rG

    jonas’: looks like it's actually http://www.fileformat.info/info/unicode/char/00061C/index.htm

  144. ralphm

    I don't see anything, nor do our logs? http://logs.xmpp.org/xsf/2019-09-09

  145. pep.

    Yeah, conversations also seem to ignore it :)

  146. jonas’

    ralphm, https://sotecware.net/images/dont-puush-me/NUWuPgMbAgbvAn1d8N7yi2ohr4zvDuzpIFANrw5I8_I.png

  147. jonas’

    ؜, look at this, they can’t even read what you’re writing

  148. pep.

    jonas’, I'd want to say "our tools are broken"? :x

  149. ؜

    oh. i should have seen that coming

  150. Ge0rG

    https://upload.yax.im/upload/y7oYvc1Z5wrQX5tg/Screenshot_20190909-181529_yaxim.jpg

  151. pep.

    They should be refused by the muc

  152. jonas’

    they should

  153. jonas’

    if only we had our stuff pinned to a single version of Unicode

  154. Ge0rG

    jonas’: nice how your text is RTL formatted :P

  155. jonas’

    if only we had our stuff pinned to a single version of Unicode everyone agrees on

  156. jonas’

    nice

  157. Ge0rG

    pasting cropped yaxim screenshots into yaxim makes my head spin

  158. Zash

    hah

  159. ralphm

    Yup, Conversations gives up on this. Nameless RTL person, I read your message through the screenshot above, but your unique setup triggers bugs in several clients and will make discussion very hard. If you can it might be good to write a reply on the standards@xmpp.org mailing list.

  160. Ge0rG

    ralphm: triggering bugs in implementations is actually a Good Thing™

  161. pep.

    Zash, so logs ignore it but MUC lets it pass?

  162. pep.

    how come

  163. Zash

    ?

  164. ralphm

    Well yes, it is surely a nice test case

  165. Ge0rG

    pep.: I've actually copy&pasted it from the http log

  166. MattJ

    pep., it's in the logs

  167. pep.

    oh

  168. Ge0rG

    pep.: it's just.... _invisible_!

  169. pep.

    Sorry I was reading ralphm above who said it wasn't

  170. pep.

    I see

  171. MattJ

    Though it might not look that way, since there is no nick rendered

  172. ralphm

    Ah, I see now

  173. linkmauve

    I can read it in the logs just fine.

  174. Ge0rG

    linkmauve: you can read it?

  175. MattJ

    Nice way to make the logs look like someone said something they didn't

  176. pep.

    \o/

  177. Nameless RTL person

    my job here is done, i guess

  178. ralphm

    Nameless RTL person: haha

  179. Ge0rG

    Nameless RTL person: please meet my friend, 🤖

  180. linkmauve

    Ge0rG, yes, it’s present in the logs.

  181. Ge0rG

    linkmauve: that's not what you said

  182. linkmauve

    I can read it there.

  183. Nameless RTL person

    i remember pasting 4MB of text into a status message and crashing all the psi clients out there. that was fun

  184. Ge0rG

    linkmauve: how can you read it if it's invisible?

  185. linkmauve

    Ge0rG, it isn’t though.

  186. Ge0rG

    linkmauve: I'm speechless.

  187. ralphm

    xmpp:xlwj4vdisilfdp2r@anon.xmpp.org nice

  188. linkmauve

    https://upload.jabberfr.org/Oy8Ag6u4EJUndIbG/wayland-screenshot-2019-09-09_18-24-24.png

  189. linkmauve

    Ge0rG, ↑

  190. Ge0rG

    linkmauve: so you can read *them*, not *it*.

  191. ralphm

    Nameless RTL person: in any case, there's differing opinions on whether a MUC service should do such interpretation. I do think that an explicit marker in front of the mention, whether processed at the client or by a service, helps disambiguation.

  192. Nameless RTL person

    i assume it's not an important matter whether the @marker works for some unusual nicknames, either?

  193. Zash

    Why doesn't resourceprep normalize eat it, whatever it is?

  194. Ge0rG

    yeah

  195. ralphm

    Nameless RTL person: like RTL markers?

  196. Nameless RTL person

    yep.

  197. Nameless RTL person

    or, let's make it simpler, spaces in nicknames

  198. Nameless RTL person

    or one of my favorites: combining characters vs. precombined characters, typed by different people in different way

  199. Zash

    Pretty sure those are normalized at least

  200. Nameless RTL person

    within message bodies too?

  201. Daniel

    Zash: not if you let the muc server do the mention

  202. Daniel

    Which is the point Nameless RTL person is trying to make I guess

  203. Zash

    Myeah I don't believe in that

  204. Daniel

    However I see ralphm blog post only as an example for references

  205. ralphm

    I assume existing implementationa just do prefix matching as main heuristic. And give up with"weird" stuff like RTL markers.

  206. Daniel

    Not as a general recommendation that all mentions should be server side

  207. ralphm

    No, indeed

  208. ralphm

    Having followed Slack for quite a while, I believe they initially did server side mentions (only) and then added client side support.

  209. Zash

    Converse.js does something

  210. pep.

    Indeed. It uses <references type='mention'/> and strips the "@"

  211. ralphm

    My mail to standards@ shows the alternative (for links, but would work for mentions just as well).

  212. ralphm

    I still think that typing an @, v.s. not, has an implicit request for notifying the mentioned individual. I wonder if that should trigger explicit server side notification, rather than client side highlighting, esp. with offline mobile clients and Push.

  213. pep.

    ralphm, note that I never disagreed on this ^

  214. Daniel

    ralphm: your muc push could also parse the reference (instead of jumping on the @)

  215. Nameless RTL person

    tbh, i'd feel uneasy if someone used my nickname and i wasn't highlighed, whether there was an @ character before my nickname or not

  216. Nameless RTL person

    it would feel as if someone talked behind my back

  217. Zash

    Nickname registration in MUC is a thing

  218. Zash

    Oh, nm

  219. ralphm

    Daniel: I mean that if you have a client side generated mention, the server could explicitly notify / wake up the recipient. Maybe with a special out-of-band message.

  220. ralphm

    By the way, example 2019-09-02-3 shows client side mention.

  221. ralphm

    Nameless RTL person: services like Slack let you get notified for user defined keywords.

  222. ralphm

    I usually set that up with my nick, name, and 'xmpp'.

  223. pep.

    Nameless RTL person, your client could very well get over this and _also_ highlight you if you so chose, by parsing body. But that's a choice of the receiving client, and I'm fine with that

  224. Nameless RTL person

    so do xmpp clients. but in the xmpp world you may have different nicknames in different chatrooms, etc.

  225. Nameless RTL person

    so the client must be smart enough to allow different hl words for different chatrooms

  226. Nameless RTL person

    and then the pain is on user to manually configure it

  227. Daniel

    And that's why we can't have nice things

  228. ralphm

    Mwoh

  229. ralphm

    I like that in MIX, much like Slack, is decoupled from the (proxy) JID.

  230. Nameless RTL person

    is this place using mix?

  231. ralphm

    I think that especially for group services like those hosted by the XSF, service wide nick registration would be a good thing.

  232. ralphm

    Nameless RTL person: no

  233. Nameless RTL person

    still, thanks to federation, even with registration, the nicknames can be different within a single client's opened chat windows

  234. ralphm

    Yes, for sure

  235. ralphm

    But highlighting $current_nick should be easy.

  236. ralphm

    And separate from that server-assisted notification would be a thing that could be implemented.

  237. Nameless RTL person

    yeah. so if the receiver client's already implementing it, why bother with the server doing it too?

  238. ralphm

    Your client might be offline (Doze mode or iOS equivalent). Having server support for this allows for waking up such clients.

  239. Nameless RTL person

    but if it's a custom highlight word, it won't

  240. Nameless RTL person

    inconsistency

  241. ralphm

    Especially in the context of MIX, where you are always in the room, even though you have no active resources.

  242. ralphm

    Nameless RTL person: you could register custom highlights with your server.

  243. ralphm

    And finally, if you get mentioned in rooms you're not in.

  244. Nameless RTL person

    ok, that would be nice if there was a subprotocol for that

  245. ralphm

    Nameless RTL person: let's say I've thought about this stuff for a while

  246. Nameless RTL person

    i guessed so, this blog post is quite thoughtful

  247. Nameless RTL person

    in essence, you'd like to move more of muc complexity onto the server. that's something i can empathize with

  248. Nameless RTL person

    however, having the api between the thin client and the server be a plaintext api, as opposed to xml, feels wrong in the context of xmpp…

  249. ralphm

    Well, not just for MUCs. In fact, I think we've come to a point where we need a lot more server involvement to match functionally in other services. That's why I believe something like MIX is better equipped for that world. Another topic is voice/video calls.

  250. Nameless RTL person

    moreover, a plaintext api which the user types themselves, making it more difficult to provide a different type of ux than just a text field, if it's desirable within the client's requirements

  251. ralphm

    Nameless RTL person: sure, having clients mark up stuff is very useful

  252. ralphm

    But the example of link references shows the two extremes. When mentioning a URL, do you want your client to go and fetch the page, scan for meta tags, craft a format for representaion, and only then send it (or maybe later as self-fastening) or let the server do that for you?

  253. Nameless RTL person

    even more, a plaintext api which is not discoverable by the client. or are you going to make it discoverable whether mix/muc adds annotations automatically or not?

  254. ralphm

    I would definitely, yes. With opt-in/out for your own messages.

  255. Nameless RTL person

    maybe. if i know that the mix/muc itself can't access the site i link, and my thick client can, then i would do so

  256. ralphm

    Nameless RTL person: yes, you could still, or course. It is not an exclusive choice.

  257. Ge0rG

    Configurability everywhere!

  258. ralphm

    But having worked on a (closed) XMPP platform, putting it in the server makes it a lot easier.

  259. ralphm

    If you then have thick clients, you see them already having marked up things and leave it alone.

  260. Ge0rG

    If your options don't have options, you're doing it wrong!

  261. Nameless RTL person

    to me it slowly starts looking like privacy lists, but i'm fine with that

  262. ralphm

    Nameless RTL person: privacy lists were hard because it made routing expensive. I think this kind of thing is different.

  263. Nameless RTL person

    so, let say, my thick client, when connecting to a mix/muc, could say "i can do references alone, please don't mess with my messages", and my thin client could say "help me, mix/muc, you're my only hope". a per-session setting would look nice, i guess

  264. ralphm

    I'd probably use a disco feature for it.

  265. Nameless RTL person

    who'd disco whom?

  266. ralphm

    The room/service would disco you

  267. ralphm

    It does so anyway

  268. Nameless RTL person

    the only worry at this point would be the observable inconsistencies in behavior between messages from different clients. but xmpp users should all be used to that anyway, i guess

  269. Nameless RTL person

    i see

  270. ralphm

    I switch between desktop and mobile all the time

  271. Nameless RTL person

    ok. would that work in 1-1 chats too?

  272. Nameless RTL person

    the job of implementing the annotations would have to be shared between the mix/muc implementation and the, i don't know how it's called… core server?

  273. ralphm

    I don't see why your own server couldn't mark up stuff for you

  274. Nameless RTL person

    would the recipient's server mark things up if the sender's server didn't?

  275. ralphm

    (if you want that)

  276. ralphm

    I'm not sure. In MUC, there is a separate entity in the conversation, from which annotations could come.

  277. ralphm

    In 1-on-1, you don't have that, so I'd expect only my own server touching my messages and sending them from my bare JID.

  278. pep.

    Validations the source jid for references won't be a requirement?

  279. pep.

    (btw)

  280. pep.

    Though MUCs can also impersonate you if they want to..

  281. Nameless RTL person

    right, this third-party annotator service would have to be trusted

  282. ralphm

    pep.: access control is definitely a thing, and feature dependent

  283. pep.

    *validating

  284. ralphm

    E.g. reactions can come from anyone. Edits not so much.

  285. ralphm

    An alternative is not actually having one-on-ones, but all your conversations as rooms. I think BuddyCloud did this, as does Slack.

  286. ralphm

    This also allows for smart bots that suggest movie times when you mention The Lion King.

  287. ralphm

    And yes this is invasive, but there's a value proposition there.

  288. Nameless RTL person

    i guess i wouldn't mind. my primary client does that anyway, mostly

  289. ralphm

    Sure. I think there's a limit to what you want to stuff in your server, though.

  290. ralphm

    But maybe a model where everyone runs their own server is compelling in the long run.

  291. Nameless RTL person

    serverless messaging isn't used anyway, i think

  292. Nameless RTL person

    the last time i tried doing so, i got enough spam to leave the xmpp world for close to ten years

  293. ralphm

    Heh

  294. ralphm

    The thing is, if you don't trust your server, there are suddenly a lot of things you can't do.

  295. Nameless RTL person

    i want to trust the server in the capacity of routing messages correctly, not much more than that

  296. Zash

    U+061C ARABIC LETTER MARK wha

  297. Nameless RTL person

    hi Zash!

  298. ralphm

    Take those emoji reactions. If all the exchanges have e2ee, you can't do summaries efficiently.

  299. ralphm

    (in MAM)

  300. Nameless RTL person

    my perfect setup would be a server whose only job is to route messages within a federated network, a thick "xmpp client" set up on my private always-on account somewhere, and a thin non-xmpp client connecting to that thick client and only do UX

  301. ralphm

    Hm. I'd probably shift the thick bits to the server and just use thin clients.

  302. Nameless RTL person

    a bit like irc server/irc bouncer/irc client setup used to be popular

  303. ralphm

    Even for annotations, by server could intercept outgoing messages and send extra stanzas.

  304. Nameless RTL person

    the bouncer part would implement the hard bits of the client, like maybe encryption, annotation, etc. and would run either on my local machine, or somewhere in the cloud under my control.

  305. ralphm

    I have at some played with the idea of bare-account-jid-components

  306. ralphm

    Which is mostly that

  307. Nameless RTL person

    and if we could deal away with JIDs used as personalities, that'd be perfect. they're good for routing, but not much more than that in my opinion

  308. ralphm

    A special client connection that doesn't bind a resource and can manipulate traffic.

  309. Nameless RTL person

    but at that point it wouldn't be xmpp anymore

  310. ralphm

    Why?

  311. ralphm

    I don't have a very strict concept of what can be called XMPP.

  312. Nameless RTL person

    not interoperable enough with clients implementing 3920/3921

  313. ralphm

    In fact, you can totally do XMPP Core only.

  314. ralphm

    There are situations where you'd only do s2s, not c2s, e.g. to federate an existing system with XMPP.

  315. ralphm

    From the other side, you wouldn't be able to tell.

  316. Nameless RTL person

    oh. then i'm happy to be informed that icq was an xmpp client thanks to transports

  317. ralphm

    I've implemented and run services with an XMPP PubSub interface that didn't support the publishing and node creation bits of the protocol. Nodes magically existed as a function of business logic.

  318. Nameless RTL person

    i see.

  319. ralphm

    Nameless RTL person: well sure, the transports were basically IRC etc. clients that magically made other IRC users have a JID.

  320. Nameless RTL person

    then i used wrong name.

  321. ralphm

    I am a strong believer in the protocols. I don't care much about the things behind the scenes.

  322. Nameless RTL person

    "then it wouldn't be xmpp instant messaging anymore"

  323. Ge0rG

    Nameless RTL person: if you create an identity model that's not based on xmpp JIDs, suddenly many xmpp features stop making sense.

  324. Nameless RTL person

    Ge0rG, exactly what i meant by that sentence

  325. Ge0rG

    If you want decentralized identities, you end up with public keys being user identifiers, and then every message must be a signed (+ encrypted) blob and routing follows some overlay structure.

  326. Ge0rG

    And then xmpp is only a hindrance

  327. ralphm

    Ge0rG: yup, I agree with that. But there's no reason why you couldn't have a thing that sits with the bare JID and manipulate incoming and outgoing traffic to assist regular clients.

  328. Ge0rG

    You could of course use the xmpp message format inside the encrypted blob, so that you can have all the client side XEPs

  329. Ge0rG

    ralphm: but the bare JID is owned by your server, not by you!

  330. Ge0rG

    And the server is mostly trusted

  331. ralphm

    If my server allows for a special API, e.g. with a kind of client-component, to act on behalf of my bare JID, why not?

  332. Nameless RTL person

    i'd be fine with user-visible JIDs, as long as there was a metaprotocol stating that those several JIDs are all me, other people can discover these other JIDs easily, and normal users could be made oblivious to their existence

  333. Ge0rG

    ralphm: what would that give you that can't be given by the server directly?

  334. ralphm

    Always on scriptability, and other stuff you want to have, your server might not provide, and offloads clients.

  335. ralphm

    But annotations could be one example.

  336. Ge0rG

    Nameless RTL person: so you want to use xmpp as the routing layer for a p2p protocol based on a cryptographic identity?

  337. Nameless RTL person

    a simplest solution would be a simple discovery protocol of "how can i contact you in other ways" + crypto signing of auth requests

  338. Nameless RTL person

    and keep all the rest of xmpp intact

  339. Ge0rG

    Nameless RTL person: then it's just a very sophisticated mechanism to exchange encrypted blobs.

  340. Ge0rG

    No benefit on top of protobuf over DTLS with TURN

  341. pep.

    not reinventing all the things? If you can use client XEPs for example

  342. Nameless RTL person

    in this sense, xmpp itself is just a very sophisticated mechanism to exchange xml on top of tcp

  343. ralphm

    Oh, if you want Jingle-negotiated p2p XML Streams, why not?

  344. Nameless RTL person

    i've never written anywhere i want p2p or jingle

  345. ralphm

    Much like Local Link Messaging

  346. ralphm

    Nameless RTL person: true

  347. Ge0rG

    pep.: yes, but you need to map your cryptographic identity scheme to faux JIDs to make most client XEPs work

  348. pep.

    Ge0rG, something like <fp>@domain? That you could change at will

  349. Ge0rG

    Nameless RTL person: p2p is just the consequence of decoupling your identity from your JID

  350. Ge0rG

    pep.: `0xdeadbeef@onion/yaxim`

  351. Nameless RTL person

    except by having actual xmpp servers, i don't need to do routing, offline storage, etc.

  352. pep.

    Ge0rG, that :)

  353. Ge0rG

    With onion being the verbatim name of the used cryptographic identity protocol

  354. Ge0rG

    Nameless RTL person: which server would keep your offline messages if you have three different JIDs?

  355. Nameless RTL person

    all of them.

  356. Nameless RTL person

    depending on which on received a given message

  357. Nameless RTL person

    depending on which one received a given message

  358. Ge0rG

    As if deduplication wasn't hard enough already

  359. Ge0rG

    Nameless RTL person: so if one of them fails, you only receive two thirds of your backlog?

  360. Nameless RTL person

    yep.

  361. pep.

    (which is already the case anyway)

  362. pep.

    (I mean, if your server fails, you receive 0/1 of your backlog)

  363. Nameless RTL person

    ⅔ > 0

  364. Ge0rG

    Congratulations! You've created a protocol that combines the drawbacks of xmpp with the drawbacks of p2p!

  365. Nameless RTL person

    thank you, i'm very happy

  366. Nameless RTL person

    it's still better than not having any means to move accounts between servers in case of problems, or in case of, let say, just being disappointed with the server operator

  367. Ge0rG

    Nameless RTL person: ask pep. about Moved.

  368. pep.

    True, that helps with <moved/>. And that's kind of where changes on that XEP are leading anyway..

  369. ralphm

    Well for what it is worth, running my own server, e2ee is overrated at best and a pain at worst.

  370. pep.

    ralphm, lots of people in this room specifically agree with you. Not so many outside of it :)

  371. Ge0rG

    ralphm: welcome to the club of OMEMO rejects.

  372. Nameless RTL person

    i talked to pep. about it, yes. i don't find it a good solution

  373. Nameless RTL person

    besides, what's wrong with just stating my other JIDs? i can make a contact in my smartphone having multiple phone numbers and it works

  374. ralphm

    pep.: Is moved more than https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-gone with forwarding address?

  375. ralphm

    pep.: yes I am aware

  376. Ge0rG

    Nameless RTL person: your contacts are managed by you. Your "friend's" alternative JIDs are managed by them

  377. ralphm

    pep.: I also have issues with crypto-currencies.

  378. Nameless RTL person

    yeah, and we're in an era where computers are supposed to help managing things up

  379. pep.

    ralphm, yes it's more than <gone/>. We discussed it a few times, I could grep through the logs, I don't remember much off-hand

  380. Ge0rG

    ralphm: the biggest issue with Moved is that all mechanisms it provides are ephemeral

  381. ralphm

    pep.: yeah, I vaguely remember. Happy to pick that back up at some point.

  382. pep.

    What Ge0rG says

  383. pep.

    You can very well make it so the current <moved/> is changed minimally and serves some part of the requirements

  384. pep.

    But there's a demand for more and that would likely require crypto identities

  385. ralphm

    Ge0rG: I added node delete + forwarding address notification, to cover that case with nodes-as-things, and implement moving 'things' between websites, habing all subscribers rewrite their references

  386. Ge0rG

    But you'd need pep to persist the tombstone

  387. Ge0rG

    ralphm: yes

  388. pep.

    Ah yes the tombstone. That you should keep on the old server and that your contacts should keep on their servers as well..

  389. ؜

    see ya!

  390. pep.

    Anyway. "Not today!"

  391. Ge0rG

    ralphm: when I first looked at Moved, I was under the impression that all it needs are two or three minor changes to work in today's environment. But it turned out to be a bottomless pit

  392. Daniel

    Do I have to send presence to a muc before I create/configure it over iq?

  393. pep.

    "has left the room due to an error (Kicked: jid malformed)" oops?

  394. flow

    another testcase for the jid corpus \o/

  395. pep.

    Zash, which ones of your clients got kicked btw?

  396. Zash

    Huh?

  397. pep.

    Zash has left the room due to an error (Kicked: jid malformed)

  398. Zash

    Got an exact timestamp?

  399. Zash

    Or aproximate

  400. pep.

    03:39:29+09:00

  401. Zash

    ... got it in UTC+2?

  402. ralphm

    Dude

  403. pep.

    21:39

  404. pep.

    what, my vps is in Japan, still..

  405. Zash

    That's in the future :|

  406. ralphm

    If Zash can't do substractions, why are we letting him write code?

  407. pep.

    wait, 20:39

  408. ralphm

    Or pep.

  409. Zash

    It's late and I'm tired

  410. pep.

    I got confused by tmux showing me the current datetime

  411. pep.

    *time

  412. Zash

    ralphm, you know how brains are really terrible at basic math, while pretty good at extremely complicated tasks like walking without falling over?

  413. pep.

    https://ppjet.bouah.net/tmux-time.png

  414. pep.

    (Yes that's a nested tmux)

  415. ralphm

    Zash: I'm not sure if that's true at all.

  416. ralphm

    It is likely dependent on how often you it.

  417. Zash

    Hush, I read it on the Internet, it must be true. And then it's totally sensible that I'd be terrible at math while being good at telling computers to do math.

  418. Zash

    Also, I'm lazy and tired.

  419. Zash

    And it's late.

  420. ralphm

    Zash: no worries

  421. Zash

    pep., http://paste.debian.net/1099725/

  422. Zash

    ``` 00000000: 6672 6f6d 3d27 7873 6640 6d75 632e 786d from='xsf@muc.xm 00000010: 7070 2e6f 7267 2fd8 9c27 pp.org/..' ```

  423. Ge0rG

    Zash: what's /x?

  424. Zash

    .

  425. pep.

    Zash, yes, that's U+061C and x

  426. Zash

    Where did my paste go

  427. Ge0rG

    Zash: your server complained about the X, not about the RTL

  428. Zash

    Huh

  429. Zash

    less wins over lnav Sep 09 20:39:28 stanzarouter warn Received stanza with invalid source JID: xsf@muc.xmpp.org/<U+061C>x

  430. ralphm

    less is more

  431. ralphm

    So a modifier by itself is ok, but modifying x is not?

  432. Zash

    LATIN SMALL LETTER X isn't arabic, so I guess

  433. ralphm

    Can you tell what rule fails?

  434. ralphm

    I'm not behind a machine to check right now

  435. Zash

    Looks like this behaves differently between libidn and ICU

  436. Zash

    ICU rejects, libidn accepts

  437. Ge0rG

    Yay for consistency

  438. Zash

    Robot face bug again

  439. Ge0rG

    Zash: why is your server enforcing it on incoming s2s?

  440. Zash

    I'm using ICU, libidn is usually the default.

  441. ralphm

    Isn't rejecting invalid stuff at your edge perfectly fine?

  442. pep.

    So we don't have specs saying what's actually valid?

  443. Zash

    pep., we do. three of them.

  444. pep.

    Great

  445. Ge0rG

    ralphm: is getting kicked from a MUC because somebody sent junk perfectly fine?

  446. Zash

    Ge0rG, at least it should be fine with robot face now

  447. Ge0rG

    ralphm: some servers will even tear down s2s

  448. ralphm

    Well, yeah, that sucks

  449. Ge0rG

    Zash: don't challenge me

  450. pep.

    Ge0rG: I'd say the MUC should kick them

  451. Zash

    The two libraries differ in how they treat unassigned code points. ICU rejects by default, libidn accepts by default.

  452. Ge0rG

    pep.: yes, but it doesn't. What now?

  453. Zash

    That's why you got robot face bug in the past, getting ICU-users kicked.

  454. jonas’

    we do have specs which do checks against RTL-weirdness, specifically stringprep

  455. jonas’

    RFC 6122 has wording on that

  456. Zash

    But prosody if built with ICU now (in trunk) will tell ICU to behave like libidn.

  457. jonas’

    https://tools.ietf.org/html/rfc6122#appendix-A.6 https://tools.ietf.org/html/rfc3454#section-6

  458. jonas’

    2) If a string contains any RandALCat character, the string MUST NOT contain any LCat character. 3) If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string.

  459. Zash

    And the MUC here uses libidn

  460. jonas’

    pep., ^

  461. Zash

    jonas’, TL;DR rejecting is correct?

  462. jonas’

    Zash, probably, I’d have to check the categories of the involved characters

  463. Zash

    U+061C ARABIC LETTER MARK U+0078 LATIN SMALL LETTER X

  464. jonas’

    u+061c is invalid because it’s unassigned to my validator

  465. Zash

    Hm, is that going to bypass the rule forbidding empty nicknames;

  466. jonas’

    Zash, but yes, if we used a newer unicode version: U+061C is AL, thus RandALCat as per StringPrep, U+0078 is bidi category L, which is LCat, which MUST NOT occur in a string with RandALCat

  467. ralphm

    One of the issues might be that resourceprep is defined using Unicode 3.2 and this codepoint is 6.3.

  468. jonas’

    fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell

  469. jonas’

    ralphm, yeah, that’s what I meant when I said "u+061c is invalid because it’s unassigned to my validator"

  470. jonas’

    Zash, so, yes, rejecting is valid, but only if you also reject U+061C on its own

  471. jonas’

    otherwise you’re rejecting based on the wrong reasons, at least if you’re using resourceprep from RFC 6122 as basis

  472. jonas’

    (if you’re using PRECIS, I don’t know)

  473. ralphm

    Probably something is using newer tables for normalization.

  474. Zash

    Not using PRECIS

  475. Zash

    Neither of the two libraries I can currently choose between has PRECIS

  476. jonas’

    Zash, then something is wrong on your end if it allows U+061C, but not U+061C U+0078

  477. Ge0rG

    So the logical consequence is to reject strictly on c2s and less strictly on s2s?

  478. ralphm

    Also no 🥓 or 🦒 in resources

  479. jonas’

    Ge0rG, I think that’s the only sane way forward

  480. Ge0rG

    So you can't get kicked because of somebody else

  481. pep.

    "Ge0rG> pep.: yes, but it doesn't. What now?" You also validate and reject it (send message errors)

  482. ralphm

    Ge0rG: why wouldn't a server reject incoming invalid JIDs on s2s?

  483. ralphm

    That other server is clearly not checking properly

  484. Zash

    Problem: Allowing unassigned code points has been the default (probably unintentionally) too long. Everything will be painful.

  485. Ge0rG

    ralphm: because what happened to Zash in this MUC today

  486. ralphm

    So xmpp.org is at fault

  487. ralphm

    It apparently accepted the bad jid and then also sent it on?

  488. Zash

    In turn because libidn and relaxed defaults.

  489. pep.

    ralphm, yes

  490. flow

    > jonas’> fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell Isn't this only true if we accept unassigned codepoints?

  491. Zash

    Postulate that we do.

  492. Zash

    flow, jonas’ stated that there may be things that normalize to different things between versions

  493. flow

    unicode standard versions?

  494. Zash

    Yes

  495. flow

    Potentially yes, but I'd expect that to be very rare. Could be wrong though

  496. Zash

    flow, also, as I mentioned earlier, accepting unassigned codepoints is the default in libidn and thus prosody for some reason

  497. Zash

    and probably other users of libidn

  498. flow

    Something else ftw

  499. flow

    Just reading ralphm blog post. So 2019-09-02-14 attaches to 2019-09-02-11, but since -11 has been corrected multiple times, it actually attches to 2019-09-02-13?

  500. ralphm

    flow: as currently envisioned, attaching is solely to the original stanza.

  501. ralphm

    But I agree this part is something needing more thought.

  502. ralphm

    It might be useful to specify a second id, in this case the edit

  503. flow

    well that id you already have, the <stanza-id/> of the stanza performing the edit, no?

  504. ralphm

    "apply to 1, as modified by 2"

  505. Zash

    Wave but not quite?

  506. flow

    ralphm, xep372 begin/end are zero indexed

  507. ralphm

    Because it depends on semantics of the thing being attached.

  508. flow

    it appears you use 1-index in your examples

  509. flow

    Yeah, I also think how much we potentially could learn from wave

  510. ralphm

    flow: oh, I'll check that tomorrow

  511. flow

    A look at the wave spec couldn't hurt

  512. Zash

    Protobufs, just like Ge0rG wanted

  513. ralphm

    E.g. for reactions you generally apply to the 'message' irregardless of edits.

  514. ralphm

    But references break with edits.

  515. ralphm

    Yeah Ge0rG and stanza versioning has come up a few times in private discussions I've had in this.

  516. Ge0rG

    I was not involved in any backroom deals!

  517. flow

    I've just read up on U+061C, it's assigned since 2013 and in the Cf category, which means it is a control character and hence disallowed in resourceparts

  518. U+061C

    yay, protobufs, this NIH thing known only because google invented it

  519. Zash

    It also magically solves all protocol problems

  520. pep.

    Isn't that just a serialisation format? (I've never actually used it)

  521. U+061C

    indeed. seen a bad case of hyperprotobufoxia before

  522. Zash

    Why does XMPP even exist when protobufs can do all that?

  523. Zash

    Or was it MQTT?

  524. Zash

    pep.: I haven't used it either, which makes me qualified to describe exactly what it is. And I say "versioned structs".

  525. U+061C

    pep., yes, it's a serialization format that's mediocre at what it can express (lots of great prior work) with somewhat good tooling (something that, i think, was the actual breakthrough of protobufs)

  526. pep.

    So it's like JSON?

  527. U+061C

    more strongly typed

  528. pep.

    I see

  529. U+061C

    also, binary

  530. Zash

    It's like C structs

  531. Zash

    With version numbers!

  532. U+061C

    and not self-describing, ie. you can't parse a protobuf binary encoding unless you know the spec used to generate it

  533. U+061C

    and not self-terminating either, ie. if you have a binary message, only part of it being a protobuf, you need to figure out where it ends on your own (e.g. sending length separately)

  534. Zash

    So you write some C struct definition and then run some tooling that spits out tons of boilerplate for whatever language.

  535. U+061C

    both of these result in shorter messages though

  536. Zash

    Not being self-describing will do that for you

  537. U+061C

    chat states in this webchat thing are so annoying

  538. U+061C

    it's not a bad tool, but those google folks could have instead support an existing standard instead. that's why it's NIH

  539. ralphm

    flow: but it being unassigned in Unicode 3.2 makes the rest of your argument moot anyway?

  540. ralphm

    Or are you looking at Précis?

  541. ralphm

    So I guess 🥓 being a So makes it acceptable for a resource?

  542. pep.

    Bacon is always acceptable