XSF Discussion - 2021-03-23

  1. larma

    I'm kinda confused by this change: https://xmpp.org/extensions/xep-0176.html#revision-history-v1.1 > Make the 'foundation' attribute a string instead of an unsignedByte, in accordance with RFC 8445 [1]. XEP-0176 is meant to implement RFC 5245, XEP-0371 is meant to implement RFC 8445. Why would we adjust XEP-0176 to be in accordance with a related but incompatible RFC?

  2. Daniel

    i’m confused about the existence of 371

  3. Daniel

    couldn’t we have just made incremental changes to 176

  4. larma

    The RFCs are not fully compatible, so, no?

  5. larma

    I mean apparently a bunch of clients seem to do RFC 8445 over XEP 176 now

  6. larma

    Because it was already widely used and looked similar to what they're doing I guess

  7. Daniel

    is there any client doing 371?

  8. larma

    Don't think so, but most WebRTC clients probably should

  9. larma

    Assuming they use libwebrtc

  10. larma

    Given that most (if not all) WebRTC clients are incompatible with what was around before, there really was no reason to stick with the 176...

  11. Daniel

    to be honest for me it was a discovery thing. i didn’t even know about 371

  12. Daniel

    or have a good enough understanding to be able to tell the differences

  13. Daniel

    (i still don’t know the difference)

  14. Daniel

    without putting words into peoples mouths I assume this may have been similiar for the two implementations that predate Conversations

  15. Kev

    We’ve always struggled for review on Jingle stuff, *especially* Jingle WebRTC stuff. There’s a couple of very knowledgeable people around, but nothing like the volume of knowledge we have relevant to most XEPs.

  16. Daniel

    larma, 371 used to use 5245 as well and was then upgraded to 8445

  17. Daniel

    without any problems

  18. Daniel

    so i'm wondering if the same can not be done for 176

  19. Daniel

    (possibly with some extra disco features for example for "i support 176 + tcp candidates" or something)

  20. larma

    I implemented a client of 176 that implements RFC 5245 and it can't be connected from Conversations because libwebrtc implements RFC 8445 (it probably works the other way round because that changes who is the controller). Incompatibility to me sounds like a good reason not to update/change a Draft XEP

  21. larma

    OTH we now have a bunch of clients claiming 176 conpat in disco that are not fully compatible, so I guess the damage is already here

  22. larma

    OTOH we now have a bunch of clients claiming 176 conpat in disco that are not fully compatible, so I guess the damage is already here

  23. Link Mauve

    larma, I originally only wanted to extend from unsignedByte to unsignedInt, as that was what libwebrtc (and all clients based on it) was doing.

  24. Link Mauve

    But RFC 5245 was already requesting a string up to 32 characters (whatever that means, probably bytes).

  25. Link Mauve

    “ foundation = 1*32ice-char”

  26. Link Mauve

    “ ice-char = ALPHA / DIGIT / "+" / "/"”

  27. larma

    Link Mauve: I guess I was more confused about the reference to RFC 8445 than the change itself

  28. Link Mauve

    Ah hmm, maybe I was the one who got confused, as 5245 already had the exact same requirement and we imported it as an unsigned byte instead, probably in accordance with implementations of the day.

  29. Link Mauve

    larma, AIUI the incompatibility doesn’t come from 5245 vs. 8445, but from mandatory DTLS-SRTP vs. not supported.

  30. larma

    That's something else

  31. Link Mauve

    Or maybe you’re aware of some incompatibility between the two RFCs that I’m not?

  32. larma

    I'm specifically talking about ICE

  33. larma

    8445 allows sending data before candidate nomination, basically making candidate nomination optional (also the reason the got rid of the aggressive nomination mode). 5245 requires nomination before sending. If the controlling side is 8445 they might never nominate a candidate, thus the 5245 side can't send.

  34. larma

    I had to discover that through wireshark ;)

  35. Link Mauve

    How is that negociated in non-XMPP deployments?

  36. larma

    They probably all use 8445 nowadays and just updated when Google dictated them to?

  37. Link Mauve

    All legacy telephony systems?

  38. larma

    They're not compatible with WebRTC anyway due to dtls-srtp

  39. larma

    So nobody cares I guess

  40. larma

    Others would just make their client such that it's compatible with legacy systems (e.g. by nominating a candidate pair even if not required for them)

  41. larma

    If care is taken, you can implement ICE clients that are compatible with different versions of ICE. For example, some early drafts of ICE required sending USERNAME attribute in responses. If you aim for compatibility you can just do it, as adding more attributes than required is allowed and they simply get ignored by RFC implementations

  42. Link Mauve

    Is “candidate pair” the proper name of a c= line in SDP?

  43. larma

    No, that's just the candidate

  44. Link Mauve

    Because I’ve seen implementations include a dummy one.

  45. Link Mauve

    In the initial offer.

  46. larma

    The pair is a combination of local and remote candidate

  47. larma

    Safari does not send proper candidates before granting audio/video permission

  48. larma

    For privacy reasons

  49. Daniel

    larma, if there is any low hanging fruit like sending transport-info/remote candidate or someting that improves the situation for you let me know

  50. larma

    I guess we'll just make sure to be compatible with RFC 8445 as well when using 176...

  51. larma

    Daniel: you mentioned TCP, do you actually do RTP over TCP?

  52. Daniel

    larma: I've disabled that because 176 doesn't support it

  53. Daniel

    Until know I was under the impression that this is the only major difference

  54. Daniel

    As this is what the introduction of 371 focuses on

  55. Link Mauve

    That was also my impression btw, which is why I never pushed for 0371.

  56. larma

    Well ICE-UDP is a datagram transport and ICE-TCP is a stream transport but according to 166 each transport should decide to either be datagram or stream and according to 167 RTP is only allowed over datagram

  57. Link Mauve

    I referred to the RFC to understand some things, but didn’t compare them thoroughly.

  58. larma

    I think having ICE-UDP and ICE-TCP not in the same XEP or at least not use the same namespace makes sense. I also wonder what libwebrtc does when setting up RTP over TCP because it will need to encapsulate the RTP datagrams somehow so they can go on a stream

  59. larma

    (encapsulate can be as easy as prefixing with a length)

  60. L29Ah

    are XMPP addresses case-sensitive? couldn't find such info in https://tools.ietf.org/html/rfc6122

  61. Daniel


  62. Daniel

    The local part is normalized

  63. Daniel

    Aka 'fancy lower cased'

  64. Link Mauve

    The fancy part means you can’t just lowercase it and do the comparison, you have to use stringprep.

  65. Link Mauve

    Not doing so is a vulnerability awaiting.

  66. Daniel

    Yes if you are asking from a developers perspective definitely understand how stringprep works. From a user perspective it's simpler to just think of lower case

  67. Zash

    L29Ah, so you would look at https://tools.ietf.org/html/rfc6122#appendix-A and then look up the referenced tables in https://tools.ietf.org/html/rfc3454

  68. Zash

    E.g. https://tools.ietf.org/html/rfc3454#appendix-B.2 is the long version of "lower-case"

  69. L29Ah


  70. dwd

    Anyone available for doing React and Stanza.js for a contracting gig?

  71. MattJ

    Don't forget https://xmpp.work/

  72. Link Mauve

    sonny, ↑

  73. sonny

    nope pretty busy ATM

  74. flow

    L29Ah, check https://tools.ietf.org/html/rfc7622

  75. Zash

    Check this handy graph ```dot digraph "xmpp-addr" { rfc3920 -> idna2003 [label="ref"] rfc3920 -> stringprep [label="ref"] rfc3920 -> rfc6122 [label="update"] rfc6122 -> idna2003 [label="ref"] rfc6122 -> idna2008 [label="ref"] rfc6122 -> stringprep [label="ref"] rfc6122 -> rfc7622 [label="obsolete"] rfc7622 -> idna2008 [label="ref"] rfc7622 -> precis [label="ref"] idna2003 -> idna2008 [label="obsolete"] idna2003 -> stringprep [label="ref"] } ```

  76. MattJ


  77. MattJ


  78. eric

    MattJ: what did you use for rendering?

  79. MattJ

    dot -Tpng

  80. eric


  81. Zash

    FTR I pasted the source so that in the far future, after all the http-uploaded files have expired, someone could still see what it was

  82. MattJ

    This URL isn't expiring any time soon :)

  83. L29Ah

    i have a string, "/"

  84. L29Ah

    is this a valid XMPP address?

  85. jonas’


  86. L29Ah


  87. jonas’

    oh, it is

  88. jonas’

    it gets normalised to `/` which is apparently a valid domain name.

  89. jonas’

    I mean "valid"

  90. L29Ah

    it might be a valid domain name but when parsed as a jid after normalisation it would denote an empty domain name with empty resource

  91. Zash

    Oh no, is this another case of "turns out a HTTP URL is a valid hostname"?

  92. L29Ah

    Zash: no, i'm figuring out why i have a failing test in a xmpp library i maintain

  93. jonas’

    L29Ah, oh no.

  94. jonas’

    that is ... interesting

  95. L29Ah

    the test suite has come up with such a nice jid

  96. L29Ah

    that the library can serialise (with normalisation) but can't parse afterwards

  97. Zash

    It's invalid because `/.` is not an existing top-level domain.

  98. L29Ah

    Zash: it might be /.local.

  99. Zash

    Oh no

  100. Zash

    But _that_ isn't valid

  101. jonas’

    is it not?

  102. Zash

    empty host, `.local` as resource!

  103. jonas’


  104. jonas’

    not if written as /.local

  105. jonas’

    normalization of the domainpart happens *after* splitting

  106. Zash


  107. jonas’

    can’t be reserialized as JID anymore though :)

  108. Zash

    Also true

  109. jonas’

    L29Ah, congrats, that’s a terrible test case

  110. jonas’

    might even warrant an erratum to RFC 6122, would have to check if 7622 has the same issue

  111. L29Ah

    "awesome test case", you mean?

  112. jonas’

    L29Ah, yes, in the original sense of the word

  113. jonas’

    well, in both senses that is

  114. jonas’

    L29Ah, where did you find it?

  115. L29Ah

    16:01:35]<L29Ah> the test suite has come up with such a nice jid

  116. jonas’

    which test suite?

  117. L29Ah

    it generates random strings

  118. L29Ah


  119. jonas’


  120. jonas’


  121. jonas’

    I mean amazing

  122. jonas’

    but awful

  123. jonas’

    you know what I mean

  124. Sam

    ooh, that's a good one. Works, but definitely seems like something we should be making illegal somehow https://play.golang.org/p/F7GRBN3EkDX

  125. Sam

    (that example is using 7622, you may have to run it twice for it to cache the library and not timeout because of the download time)

  126. jonas’

    Sam, thanks for the 7622 check

  127. Kev

    “not if written as / .local” Why does that space matter? It’s still split on the / so the latter part is the resource?

  128. Sam

    Kev: that's not a space :)

  129. jonas’

    Kev, it’s not a space, it’s a strange slash character

  130. Sam

    (it's not a '/' either :) )

  131. Zash


  132. Kev

    Ah, if it’s not / then ok :)

  133. Sam

    Should be fine because it will never be normalized to '/' in 7622 at least, but it *looks* confusing which is possibly bad

  134. Kev

    Yes, “fine” might be quite subjective here :)

  135. Sam

    Eg. if I buy "google.com/definitelynotevil.com"

  136. Sam

    "Hi, I'm an important person from Google which you can verify from my JID!, I want to give you 5 million dollars!"

  137. L29Ah

    ok seems like i need to replace my stringprep stuff with 7622 stuff

  138. Sam

    L29Ah: does stringprep normalize that to '/'? Yah, that seems like a potential place for serious bugs

  139. L29Ah

    yes it does

  140. Kev

    Is this the point where I repeat my usual complaint that precis-based JIDs are broken? :)

  141. Sam

    Kev: in this case it appears to be the stringpep based JID that would break.

  142. Zash

    Does PRECIS fix this?

  143. Kev

    Sam: In the sense that there’s no upgrade path from stringprep to precis, and therefore they can’t be safely used on the same network unless they’re compatible, and if they were compatible (they’re not) there’d have been no reason to go to precis.

  144. Sam

    It just uses IDNA's toUnicode for domains, so yah I guess so. It seems bad that stringprep does more than that, because then you'd end up with domains that are valid but you can't use them for JIDs

  145. Sam

    But I haven't really looked, so that's assuming this is all true and not a bug in one of our libraries.

  146. Sam

    Kev: they're compatible enough in the real world. But yah, the upgrade path is tricky. If this is really true though, I'd say it's a huge reason to upgrade. stringprep not allowing valid domains in JIDs seems really bad

  147. Sam

    Anyways, back in a bit then I need to write some tests around this.

  148. Kev

    “They’re compatible enough in the real world” is exactly the point. People make that argument, but if it were actually true there’d be no reason to need to go to precis.

  149. L29Ah

    https://tools.ietf.org/html/rfc3491#section-4 yeah nameprep tells it gets normalized

  150. Kev

    We can’t both have the “stringprep is broken, we must precis” argument and the “but it doesn’t matter because they’re compatible in every way that matters” argument both being true :)

  151. Zash

    How about we just be very conservative with new usernames and stuff until we're all on PRECIS

  152. Kev

    Zash: With which unicode version?

  153. Zash


  154. L29Ah

    screw that, i'll just sanitize stringprep output for @ and /, and tell that i'm done

  155. Kev

    AFAIK, you can’t safely mix unicode versions in XMPP (nor in JIDs), and you can’t safely mix precis and stringprep-based JIDs. But we pretend that you can, while pasting “This is fine” GIFs :)

  156. Sam

    Kev: I disagree. They're compatible in every way that matters, but stringprep is broken in a way that while it's not likely to be seen in the real world seems bad, but not because of its incompatibility with precis, because of its incompatibility with DNS.

  157. Sam

    I mean, don't get me wrong, we should come up with a graceful way to upgrade and handle the differences, I'm just saying that 90% of the time it actually is fine and stringprep is apparently broken in ways that have nothing to do with its incompatibilities with precis.

  158. Kev

    I don’t disagree that precis might be better, I just don’t see how we can be expecting everything to work nicely without upgrade paths.

  159. Sam

    Yah, we should come up with some of those.

  160. Sam

    It's just going to be hard to get anyone to do it because it will work well enough, so check your database, if there are no differences in any JID or JID that people are sending to: go ahead and upgrade. If there are, wait for an upgrade path.

  161. jonas’

    step 0: find all JIDs in a database

  162. jonas’

    that’s a challenge in and of itself

  163. moparisthebest

    is your database the only one that matters? doesn't it break interop with everyone else too ?

  164. Zash

    I'm still thinking Be strict when creating local resources (users, rooms, nickname registrations...) Be relaxed with incoming data from other servers.

  165. moparisthebest

    kinda like if your email server can enforce authenticated TLS only just turn it on, and enjoy your no messages from anyone from that point forward :)

  166. Ge0rG

    Zash: 🤖 disagrees with that.

  167. Zash

    🤖️ doesn't exist, it can't hurt you

  168. Kev

    It’s even wider than JIDs, actually (Unicode, rather than precis/stringprep).

  169. L29Ah

    okay, is "foo@bar:666/baz" a valid jid?

  170. Kev

    Even with message bodies, unicode version changes can break things.

  171. Kev

    Are those all the characters they look like?

  172. L29Ah

  173. Zash

    L29Ah, maybe but I don't like it

  174. Zash

    IIRC you're allowed to put port numbers in the domainpart, but I doubt it'll be reliable

  175. moparisthebest

    there's generally a wide difference between "what the spec allows" and "what you can actually use in practice"

  176. Zash

    L29Ah: `[db8::123:abc]` is a legal domainpart too, and that has `:` in it

  177. L29Ah

    Zash: oh, thanks

  178. Zash

    Not completely sure about port numbers

  179. moparisthebest

    I recall a poor lady named something like Mary O'Toole who's email was Mary.O'Toole@domain.org which is a perfectly valid email that most email systems refused to deliver mail to

  180. Zash

    not mentioned in 6122

  181. Zash

    Don't mention email :(

  182. Kev

    I thought that port numbers weren’t allowed, but would have to scour specs that I don’t want to scour at teh moment.

  183. moparisthebest

    point being, it's the same in XMPP land, you can't use PRECIS for this reason

  184. L29Ah

    ok so i just strip / and @ from domainpart, and declare all jids with domainpart that normalizes to a string with those invalid, what do you think?

  185. L29Ah


  186. Zash

    Sounds sensible

  187. Zash

    > Implementation Note: When dividing a JID into its component parts, an > implementation needs to match the separator characters '@' and '/' > before applying any transformation algorithms, which might decompose > certain Unicode code points to the separator characters.

  188. Zash

    ... but then nothing about what to do if that actually happens 🙁

  189. flow

    L29Ah, so what's the lib in question. I only know quickcheck from haskell and there I know one XMPP lib

  190. flow

    L29Ah, so what's the lib in question? I only know quickcheck from haskell and there I know one XMPP lib

  191. L29Ah

    flow: pontarius-xmpp

  192. flow

    I figured

  193. flow

    so is pontarius alive again?

  194. L29Ah


  195. L29Ah

    but i took over to keep pontarius-xmpp in shape and hopefully write a decent XMPP client someday

  196. flow

    well, you came here and ask the right questions, so I'd say you are on a good way ;)

  197. L29Ah

    at least now i have a replacement for the bitrotten sendxmpp: https://github.com/l29ah/hsendxmpp

  198. MattJ

    Everyone does

  199. L29Ah

    google failed me :(

  200. Zash

    It's slowly growing into the hello world of XMPP :D

  201. MattJ

    But everyone who doesn't continues to use the bitrotten version :)

  202. L29Ah

    bitrotten version stopped working for me

  203. MattJ

    We need to get some/all of them packaged in distros

  204. MattJ

    It stopped working for me a long time ago, and then I later heard it was active again (and/or there is a fork with the same name)

  205. L29Ah

    hsendxmpp is packaged in nixos :]

  206. L29Ah

    (as they package everything on hackage automatically)

  207. flow

    L29Ah, you may want to consider passing the password as command line argument

  208. L29Ah

    flow: i do

  209. flow

    L29Ah, you may want to consider not passing the password as command line argument

  210. L29Ah

    flow: i also do

  211. moparisthebest

    L29Ah, yet another https://crates.io/crates/sendxmpp

  212. moparisthebest

    so many sendxmpp's :P

  213. L29Ah

    For full functionality of this site it is necessary to enable JavaScript.

  214. moparisthebest

    ah sorry https://lib.rs/crates/sendxmpp there you go

  215. Sam

    Wow, there are a lot of these. I think Martin also maintains https://salsa.debian.org/mdosch/go-sendxmpp

  216. Sam

    And I vaguely remember a Python one a while ago too (though I don't remember if it was maintained)

  217. mdosch

    Yes, I once listed up those sendxmpps known to me there: https://wiki.ubuntuusers.de/Archiv/sendxmpp/#Alternativen

  218. mdosch

    German, but shouldn't be an issue in that case.

  219. moparisthebest

    Sam, that was https://github.com/moparisthebest/sendxmpp-py and supposedly it still works for some people but it quit working for me so I wrote the rust one and abandoned it

  220. Sam

    Oh yah, that's the one.

  221. flow

    am I to late for the party? https://github.com/Flowdalic/sendxmpp/blob/master/sendxmpp

  222. Sam

    I've actually got one somewhere too (but it was just an example of using a library, not something I maintain or that's feature complete). More sendxmpps!

  223. MattJ

    Maybe we should list all these :)

  224. Zash

    I have an `sendxmpp-curl` that talks to a mod_post_msg I wrote for Prosody a million years ago

  225. sebastian

    > I have an `sendxmpp-curl` that talks to a mod_post_msg I wrote for Prosody a million years ago which works great by the way... i receive several dozen messages per day this way :-)

  226. L29Ah

  227. mdosch


  228. L29Ah

    If the domainpart includes a final character considered to be a label separator (dot) by [IDNA2003] or [DNS], this character MUST be stripped from the domainpart before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP-URI]. In particular, the character MUST be stripped before any other canonicalization steps are taken, such as application of the [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII operation as described in [IDNA2003].

  229. L29Ah

    so am i compliant if all the dots right before / in any jid are stripped?

  230. L29Ah

    at the end of domainpart, that is

  231. flow

    L29Ah, only the final dot

  232. flow

    user@example.org is the same as user@example.org.

  233. Sam

    If there are multiple dots in a row I think that would just be an invalid domain label

  234. flow

    I think so too

  235. flow

    btw, this is not an xmpp specific thing, in fact all DNS names have a final dot, we just don't write it usually

  236. L29Ah

    flow: then it would strip an additional dot at each re-serialization

  237. flow

    L29Ah, I think the jid should be rejected prior that

  238. flow

    so exmaple.org... would become example.org.. which hopefully your DNS library would reject as invalid DNS name

  239. L29Ah

    say i received the jid from a remote party

  240. flow

    but the rules what constitutes a valid domainpart are blury in rfc 7622. I submitted an errata for that, basically you want to allow IPv4 and v6 addresses and DNS names consisting of U-labels in the domainpart

  241. flow

    but the rules what constitutes a valid domainpart are blurry in rfc 7622. I submitted an errata for that, basically you want to allow IPv4 and v6 addresses and DNS names consisting of U-labels in the domainpart

  242. L29Ah

    so i just can't handle ⒐ as a domain name in nameprep-based xmpp

  243. L29Ah

    time to look for PRECIS implementations it seems

  244. flow

    yes, I would suggest that. but ultimately the question is if ⒐ is valid in an U-label

  245. L29Ah

    still, rfc7622 notes the same about dots, so i'll have to strip them all

  246. Zash

    Ah yes, the `blah..` edge case. Such fun.

  247. Zash

    Perhaps ".." should be rejected early, before you strip the last "."

  248. L29Ah

    what about ...?

  249. dwd

    L29Ah, What about what?

  250. Zash

    matches ..?

  251. dwd

    L29Ah, (I'm joking). A domain name is an array of labels, written as a single string with the labels separated by dots, and so if you encounter a zero-length label in a domain name anywhere but the end (where there is one implicitly) then it's an error.

  252. dwd

    L29Ah, But note it's not just '.', but other separators, like (I think) '·'.

  253. Zash

    What about '·'‽

  254. flow

    there a list somewhere™

  255. flow


  256. flow

    Zash, so the answer is "no"

  257. L29Ah

    is there a normal form of domainpart?

  258. flow

    L29Ah, no, which will probably hurt us in case of IPv6

  259. Zash

    Isn't that nameprep?

  260. Zash

    DNS has that, and something something A vs U labels. IPv4 is easy, IPv6 has a canonical form too afaik.

  261. Zash

    But you don't encounter very many IP literals in the wild. Prosody didn't even support them at all until recently.

  262. Kev

    I had in my head that they weren’t valid for JIDs for some reason.

  263. flow

    Zash, I don't see no nameprep in rfc7622

  264. Zash

    flow: well if you look at rfc7622 then you get to play rfc recursion from https://www.rfc-editor.org/rfc/rfc7622.html#section-3.2 and on

  265. Zash

    have fun!

  266. flow

    Zash, not sure in which direction you want me to go

  267. flow

    can you point me to the next step after rfc7622 § 3.2

  268. flow

    can you point me to the next step after rfc7622 § 3.2 ?

  269. Zash

    No, sorry, don't wanna risk summoning back the headache that's been looming over my head today.

  270. flow

    I guess my point is that there is not much to follow, besides probably U-Label

  271. flow

    but IIRC there is no normal form for U-labels

  272. Zash

    Aren't there a bunch of RFC links in the following sections?

  273. flow

    I think so

  274. flow

    but nothing I connect with domainparts (besides, you guessed it, U-labels)

  275. Zash

    Convert to A-labels (that's the pure ASCII one, right?), lowercase. Done! 😀

  276. L29Ah

    This implies that the string MUST NOT include A-labels as defined in [RFC5890]; each A-label MUST be converted to a U-label during preparation of a string for inclusion in a domainpart slot.

  277. flow

    L29Ah, that's a bit misleading

  278. flow

    XMPP domainparts should (IMHO) never contain A-labels

  279. flow

    they are always U-labels

  280. flow

    domainparts that form a DNS name, consists of U-labels

  281. flow

    so that this is trying to say is: if you want to make a domainpart out of something that you know is an A-label, then transform it to an U-label prior creating the domainpart

  282. flow

    L29Ah, sorry, I somehow missed the 'NOT' in your statement

  283. emus

    Tatsächlich finde ich jedoch einen Fork für eine Monal Android app garnicht so uninteressant 🤔️

  284. emus


  285. flow

    L29Ah, FYI there is a cropus if valid/invalid JIDs at https://github.com/igniterealtime/jxmpp/tree/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids

  286. flow

    but be aware that it is not impossible that some strings are in the wrong category. I am happy about feedback and/or new suggestions