XSF Discussion - 2020-09-17


  1. flow

    pep., if you replace it, then the old/previous feature is also gone, right?

  2. pep.

    yes

  3. flow

    so i'd just remove all traces of "max" and add a new feature for your proposed "-1"

  4. flow

    related: I do wonder if there should be room for a union type form field, e.g. this field's value is either a int or one of "foo", "bar" or "baz".

  5. flow

    related: I do wonder if there should be room for a union type form field type, e.g. this field's value is either a int or one of "foo", "bar" or "baz".

  6. flow

    as I also don't like overloading integer values with extra semantics (think "error codes"), but I can see that the way of least resistance may be the way forward in this case

  7. Daniel

    > as I also don't like overloading integer values with extra semantics (think "error codes"), but I can see that the way of least resistance may be the way forward in this case I'm really not a fan of this either. That's why my original proposal didn't. But it seems like the community has spoken

  8. pep.

    yeah I'm also not a fan, but..

  9. MattJ

    To be clear 'max' is not a blocker for me

  10. flow

    > But it seems like the community has spoken I am not sure if I'd put it that way. Clearly there are two different camps in how this should be done. What we should do now is to see if we can find a compromise

  11. flow

    MattJ, ahh ok, I assumed that pep made the propsoal because this was blocking adoption by prosody

  12. MattJ

    We have had this discussion already in the past year, and I think the conclusion was that we need some new type like 'integer-with-max'

  13. flow

    more like "integer-with-list-of-predifined-strings", but yes

  14. flow

    more like "integer-with-list-of-predefined-strings", but yes

  15. MattJ

    Predefined where?

  16. MattJ

    The point is that we need to validate it, so the list of possible strings needs to be known

  17. flow

    hence predefined

  18. MattJ

    So what strings are you thinking?

  19. flow

    depends on the use case

  20. flow

    the xep where the form field is specified in also declares those

  21. MattJ

    No thanks

  22. Zash

    How about 'min' and 'max' as aliases for the xep122(?) min and max limits?

  23. MattJ

    I mean, again not a blocker, but annoying

  24. MattJ

    Yes, min and max makes sense

  25. MattJ

    What I would rather not have is an open-ended data type where the possible legal values are dependent on context

  26. Kev

    Zash: I think max is distinct from the integer limit though, no?

  27. Kev

    In that it's asking the server to be essentially unlimited, as much as is allowed.

  28. Kev

    (I don't particularly have a horse in this race, I think pretty much anything is workable here)

  29. MattJ

    The max integer limit is "as much as is allowed"

  30. MattJ

    But what I'm guessing you're saying is that it may change

  31. Holger

    MattJ: It wouldn't really depend on _context_, in that this field variable would always have this data type, no? (We do have XEPs where valid types do depend on context, I do hate _that_ ...)

  32. MattJ

    Holger: what I took the proposal to be is a data type that is essentially an integer or string

  33. MattJ

    Where the strings are chosen by the XEP it is used in

  34. MattJ

    Which is almost useless for validation

  35. pep.

    > MattJ, ahh ok, I assumed that pep made the propsoal because this was blocking adoption by prosody I kinda did?

  36. pep.

    if it's not blocking then.. great? :)

  37. Holger

    MattJ: We have various form fields and whatnot where an XEP defines a limited set of valid strings already, no? (I.e. enumerations ...)

  38. Holger

    Whatever, in this specific case it's really about integer|'unlimited', not integer|string, right ...

  39. Zash

    And those would use list options

  40. MattJ

    I'll restate the problem: we offload dataform parsing and validation to a library, it currently takes care of ensuring max_items is an integer, and so on. The proposed "max" change means we have to stop declaring this field as an integer and move all validation back into code that uses the library

  41. Holger

    MattJ: Or fix the library ;-)

  42. MattJ

    Obviously that can be done, but using this "max" hack has come up in other contexts since

  43. MattJ

    Holger: fix it to do what?

  44. Holger

    (I have a similar problem but I do see how union types are useful to support.)

  45. MattJ

    "max" is not valid for xs:integer

  46. Holger

    To support validation of complex types.

  47. Ge0rG

    if somebody had told Council back then, we'd probably have approved -1 instead of "max" or "โˆž"

  48. Holger

    I just wouldn't have seen declaring the type to be "integer|'unlimited'" (or in other cases "integer|enum('one', 'two', 'three')") as a hack. Quite the opposite, I'd see limiting us to simple types as a hack to work around implementation problems.

  49. pep.

    Not everything goes into integers indeed. and having "max" is certainly more explicit than "-1" for clients or server devs

  50. MattJ

    Holger: it's based on XEP-0122 so that validation constraints can be communicated to clients

  51. Holger

    Ah!

  52. MattJ

    So all I'm asking is that we use a proper defined type instead

  53. pep.

    So it's a spec limiting an implementation limiting another spec!

  54. flow

    we surely could extend xep122 to support those kind union form field type

  55. Holger

    pep.: Exactly.

  56. flow

    we surely could extend xep122 to support those kinds of union form field types

  57. MattJ

    I'd be totally happy to get behind that - and I see it being useful in other contexts too

  58. pep.

    That does mean a lot more work..

  59. MattJ

    I'm also happy with xmpp:integer-with-max :)

  60. MattJ

    Whatever makes most sense to people

  61. pep.

    UsefulPubSubThings when? (hint: never!!)

  62. pep.

    A well thought design is appealing, but the path leading to that is full of ambushes :p

  63. pep.

    Long and perilous

  64. Zash

    So we should just pile on hacks?

  65. MattJ

    pep.: yes, I know spec work is draining in this way :(

  66. pep.

    Zash: isn't that what happens in practice most of the time

  67. Zash

    Giving up and adding more hacks isn't going to help with that

  68. pep.

    I agree, but that needs work and dedication. I'm curious how projects like Movim and Sร t ever managed to make something useful out of pubsub without this tbh, or what I point out in https://mail.jabber.org/pipermail/standards/2019-October/036503.html

  69. MattJ

    Me too

  70. pep.

    I may not be entirely available for the board meeting. I'll be in transports in between things (missing a word.)

  71. Ge0rG

    I have two AOBs for Board.

  72. Ge0rG

    Or rather, Council has.

  73. eta

    pep., MattJ: I think movim just gets you to force max-items to something high

  74. eta

    in server config, that is

  75. MattJ

    We're also lacking a config option to ask the server to return an error when reaching the limit, rather than discarding older items

  76. pep.

    eta, yeah and that fails whenever an operator is not aware one of their users is using movim

  77. pep.

    And what MattJ says

  78. pep.

    (which I mentioned in my email last year)

  79. eta

    ah.

  80. pep.

    Even though for the issue I mentioned just now, that's possibly another issue that goes alongside using servers that correspond to your use-case

  81. pep.

    (how to find them is something I want to tackle but -ENOTIME)

  82. pep.

    Busy adding custom types in XEPs

  83. pep.

    MattJ, something something registry not working.

  84. MattJ

    Yeah, that minor issue :)

  85. pep.

    So I "can't" submit my change just now.

  86. pep.

    https://xmpp.org/extensions/xep-0137.html#example-1 oops, unqualified NS "si-profile"?

  87. pep.

    How do I define a datatype in a registrar definition? :/

  88. pep.

    I mean not just saying it exists

  89. pep.

    Taking example on https://xmpp.org/extensions/xep-0137.xml#registrar.xdata-validate, that includes a definition from the XEP itself, is that enough?

  90. pep.

    In https://xmpp.org/extensions/xep-0137.xml#usecase.xdata

  91. MattJ

    Yeah, I guess the new type needs a XEP?

  92. pep.

    I'm not entirely sure this is the correct thing to do though, MattJ. You can apply a range to xs:integer for sure but how to you apply a range to <xs:simpleType><xs:union><xs:simpleType><xs:restriction base='nonNegativeInteger'/></xs:simpleType><xs:simpleType><xs:restriction base='string'><enumeration value='max'/></xs:restriction></xs:simpleType></xs:union></xs:simpletype>

  93. pep.

    What I had in mind at the beginning was to allow servers to send over their own type definition :x

  94. pep.

    But that's madness

  95. Ge0rG

    kinda like EXI?

  96. MattJ

    Agreed, madness :)

  97. pep.

    But then how do I solve the <range/> thing.

  98. pep.

    It's also not like it could be applied to a variant of our custom union type because there's no variant

  99. pep.

    And I can't define another derived integer type with custom range because every deployment is different :)

  100. pep.

    In this new XEP/modification to existing XEP I might be able to say "any <range/> thing applies to this integer value" but that's meh

  101. MattJ

    It's meh but I'm not sure I see another solution

  102. pep.

    Fortunately 122 says there can only be one <range/> within <validate/> (in the non-normative schema)

  103. pep.

    another solution would be to go to the w3c with a revolutionary union type with variants! (not me plz)

  104. ralphm bangs gavel

  105. ralphm

    0. Welcome + Agenda

  106. pep.

    half-here

  107. ralphm

    Hi

  108. Seve

    ๐Ÿ‘‹

  109. Seve

    MattJ Guus

  110. Guus

    hi

  111. Guus

    sorry

  112. MattJ

    Oh, forgot it was Thursday

  113. MattJ

    o/

  114. ralphm

    welcome all

  115. ralphm

    I've added an item from last meeting from Ge0rG

  116. ralphm

    And although my name wasn't mentioned thrice, it appeared that dwd had a suggestion for a topic from the Council meeting, too

  117. ralphm

    Hope either of them is around.

  118. Guus

    I'd really like to receive agendas prior to the meeting, so that we can prepare. We've agreed on that, didn't we?

  119. Ge0rG

    ralphm: the Council asked to create a web page linking to the latest / emphasizing the latest and linking to all Compliance Suite(s)

  120. ralphm

    We did indeed. My apologies

  121. Ge0rG

    ralphm: and the second question from dwd was "what about the badges"

  122. Ge0rG

    (I'm paraphrasing here)

  123. ralphm

    ok

  124. dwd

    For board to consider: the discussion on the compliance suites.

  125. ralphm

    1. Minute taker

  126. ralphm

    I'll write up minutes later.

  127. ralphm

    2. IETF's use of Jabber

  128. ralphm

    This was an AOB item by Ge0rG last meeting.

  129. ralphm

    Ge0rG, what is this about?

  130. Ge0rG

    there was a thread on the IETF (users?) ML about how they are trying Slack as an IM alternative

  131. Ge0rG

    and in that thread, there were some opinions about XMPP that are based on ~15 years old facts

  132. Ge0rG

    so I wrote a nice mail to their xmpp admin, offering help with improving their xmpp infrastructure as well as their recommended clients

  133. ralphm

    Ah, I haven't seen that.

  134. Ge0rG

    the xmpp admin forwarded it to the IETF Executive Director

  135. ralphm

    Thanks for picking that up. Any response, yet?

  136. Ge0rG

    yes, we've had some communication, and the next step would be to set up a converse.js instance, help them a bit with ejabberd config and provide better client recommendations

  137. Ge0rG

    The ones on https://www.ietf.org/jabber/ are also ~15 years old

  138. Ge0rG

    Do we have something solid we can recommend for the major platforms?

  139. Ge0rG

    They also asked if we can offer commercial-grade service / hosting for them, but I declined

  140. Ge0rG

    we can hardly offer commercial-grade hosting for our own needs.

  141. ralphm

    You can, 'we' can't.

  142. flow

    but I think we have people who do offer commercial-grade hosting?

  143. MattJ

    The XSF obviously doesn't offer hosting, but I'm sure there are people who would be happy to provide such an offering

  144. Ge0rG

    ralphm: the original mail was signed by me and two other XSF members

  145. ralphm

    I.e. we, the XSF, vs you, people in the community.

  146. Ge0rG

    flow: those people need to stand up and volunteer then.

  147. flow

    wait volunteer?

  148. flow

    I assumed we where talking about commercial paid services

  149. Ge0rG

    flow: no

  150. flow

    ahh so commercial-grade without the commercial

  151. Ge0rG

    None of the people who contributed to the initial mail volunteered any infrastructure yet.

  152. Ge0rG

    flow: commercial-grade as opposed to commercial

  153. MattJ

    I'm assuming they don't just want a random XMPP community member running this

  154. Guus

    Ge0rG I suppose we can call for volunteers on a mailinglist?

  155. Ge0rG

    but maybe that was just a misunderstanding between me and the IETF folks

  156. ralphm

    MattJ, right, that makes sense

  157. MattJ

    There are a number of commercial entities around XMPP who I'm sure would be happy to sponsor a commercial-grade deployment for the IETF

  158. ralphm

    Do IETF also provide XMPP accounts, or just the groupchat service?

  159. flow

    wasn't the initial jabber setup of the ietf done by some random xmpp community member?

  160. Guus

    exactly my thought Matt

  161. ralphm

    I seem to remember we did the latter long, long, long time ago.

  162. Guus

    this all is exciting, and I applaud the people involved to have picked this up - but how is this a board issue?

  163. Ge0rG

    ralphm: they are only hosting the MUC server and intend to keep doing so.

  164. Ge0rG

    ralphm: aka. they don't want to host user accounts themselves

  165. Ge0rG

    but they'd probably be grateful to have a recommended server with IBR and good stability

  166. Ge0rG

    or a small list of recommended servers

  167. ralphm

    Guus: the question might be, besides running muc.xmpp.org, do you also want to run muc.ietf.org, as an XSF effort. This would surely need to pass board.

  168. flow

    Ahh, that MUC-only requirement may lower the bar to provide the service for free

  169. Ge0rG

    I'd offer mine, but it lacks both in stability and in bus factor

  170. Ge0rG

    ralphm: I don't think they want to change hosting for their MUC component.

  171. ralphm

    ok

  172. Ge0rG

    I'm pretty sure we can put up a Holger to review their configuration and to add / fine-tune the modules needed for MAM and all the other fancy stuff, though

  173. ralphm

    Sure

  174. Ge0rG

    Then we also need to make a list of recommended clients

  175. Ge0rG

    And then we need to set up a converse.js instance with a nice fancy web front listing all their MUCs

  176. pep.

    Ge0rG: 'we'? we can hardly get a client list up on our website :)

  177. ralphm

    I'm reluctant to provide a recommendation on behalf of the XSF.

  178. Ge0rG

    Any other volunteers?

  179. ralphm

    But I know there are people in this discussion with opinions, that'd be perfectly fine to be voiced.

  180. ralphm

    Outside of their capacity within the XSF.

  181. Ge0rG

    the last mail from the IETF came on Sept 8th, and I failed to respond so far.

  182. Ge0rG

    ralphm: I don't want to make it political, I want to help in pragmatic and useful ways

  183. ralphm

    Indeed.

  184. Guus

    I do not see an issue with individuals making recommendations, even if those individuals have XSF associations.

  185. ralphm

    I very much like us to help the IETF, don't get me wrong.

  186. Ge0rG

    ralphm: 'us'?

  187. ralphm

    Just that given the recent discussion, it cannot be an XSF recommendation.

  188. Ge0rG

    I'm perfectly fine with signing that recommendation with my name only.

  189. Ge0rG

    But I still need help preparing it, see above.

  190. MattJ

    I'm happy to recommend some clients

  191. ralphm

    See :-D

  192. Ge0rG

    Also I'm going on vacation in some days and my capacity to prepare something will go from ~0 to ~-10

  193. Ge0rG

    MattJ: yes, ripping your client recommendation list came to my mind

  194. Guus

    10 minutes left. Does this need furhter board action?

  195. MattJ

    The new one in Prosody? That's less of a recommendation list and more a list of clients that came to mind, but yeah

  196. Ge0rG

    MattJ: maybe in terms of a diff to https://www.ietf.org/how/meetings/jabber/ ;)

  197. Ge0rG

    Guus: no, that was FYI

  198. ralphm

    Guus: I think can move the remainder of this discussion outside of the meeting.

  199. ralphm

    Thanks for noting this Ge0rG!

  200. Ge0rG

    unless the Board wants to get all political and provide actual help, of course

  201. ralphm

    3. Compliancy Suites

  202. Ge0rG

    Council is preparing a new Compliance Suite for 2021, and thus Dave was so kind to make a public inquiry on standards@ about their usefulness.

  203. Ge0rG

    The feedback was mainly: - we need badges to make CS more useful - the XEP process is horrible, we need just a webpage

  204. Ge0rG

    But a new webpage would require New Council Process as well as New Webteam Process, I've decided to stick to the old process so far.

  205. Ge0rG

    I with my CS author hat, that is.

  206. Guus

    Why do we need processes to get a page added / modified on the website?

  207. Ge0rG

    Nevertheless, it would be Awesome:tm: to have Somebody Else:tm: create a page on our website that would be linked prominently and link to the current CS

  208. ralphm

    I've failed to get in contact with the person who initially offered to do the design of the badges. At this point, I'd have whoever volunteers just create *something*.

  209. Ge0rG

    Guus: up to now the Council has defined what belongs into CS. Of course we can delegate that to the Webteam

  210. ralphm

    As for the website, please collaborate with the comms team.

  211. Ge0rG

    https://op-co.de/tmp/xmpp-compliance-badges-2020/ :D

  212. Guus

    Isn't the website merely a reflection of what's in the most up-to-date CS?

  213. ralphm

    Ge0rG: hooray!

  214. Ge0rG

    Guus: it would suffice to have a page on the website that explains CS (copy&paste from the CS intro!) and links to the document du jour

  215. Guus

    If we can avoid changing or adding any processes, and just have a page that reflects that... that'd be ... good?

  216. Ge0rG

    Guus: a paragraph, a bold link to current year, a list with links to previous editions

  217. pep.

    > The feedback was mainly: > - we need badges to make CS more useful > - the XEP process is horrible, we need just a webpage Is that really the only feedback? You (council) discarded the part where some said they're not so useful as is?

  218. Ge0rG

    Guus: and a place in the website where it should be

  219. ralphm

    I'd indeed just create a PR and have someone in comms +1 it

  220. Guus

    all fine by me - but more of a commsteam issue than board?

  221. Ge0rG

    Guus: somebody needs to do it

  222. Guus

    sure, but that's not neccesarily a board member? :_)

  223. Ge0rG

    Guus: I hoped Board can direct some resources at it.

  224. Guus

    I don't think so, as board depends on volunteers.

  225. Guus

    unless you propose hiring someone or somesuch

  226. Seve

    I'm very busy at the moment but I will try to tackle that Ge0rG

  227. Ge0rG

    > I've failed to get in contact with the person who initially offered to do the design does that mean you tried and they didn't respond or that you had no chance to try?

  228. Ge0rG

    Seve: cool, thanks!

  229. Seve

    I'm also in comms so.. ;)))

  230. ralphm

    Ge0rG, I tried and they didn't respond

  231. ralphm

    (several times)

  232. Ge0rG

    ralphm: cool, thanks for that!

  233. Ge0rG

    there was significant bike-shedding of the design a year ago or two, and an alternative design by theTedd.

  234. ralphm

    Thanks, Seve

  235. Ge0rG

    So I have mixed feelings about just pushing through with mine, as it's clearly not perfect

  236. ralphm

    Ge0rG, let's just have something, and then go from there.

  237. Guus

    +1

  238. Ge0rG

    But OTOH, I could just PR it on shields.io and be done

  239. ralphm

    If somebody then steps up with: "hey, I fixed your fugly graphix, here's the PR", then yay

  240. Guus

    I'm applauding all of your efforts, Ge0rG - unsure if your due dilligence by running it past board adds unneeded delays though.

  241. ralphm

    ok

  242. ralphm

    4. AOB

  243. Seve

    I would like for next meeting to discuss this https://trello.com/c/GHGXcYuq/405-how-should-we-approach-txxmpps-pr

  244. pep.

    I had a quick look and I don't see the issue. happy to take that to next meeting

  245. Seve

    It has been there for a while already and would like to close the issue

  246. Seve

    (No more AOB here)

  247. ralphm

    Ok

  248. ralphm

    5. Date of Next

  249. ralphm

    +1W

  250. ralphm

    6. Close

  251. ralphm

    Thanks all

  252. Guus

    Thanks!

  253. ralphm bangs gavel

  254. Seve

    Thank you everyone ๐Ÿ™‚

  255. pep.

    thanks

  256. Ge0rG

    is it me or is git.gnupg.org down?

  257. Ge0rG

    MattJ: so, do you volunteer to make a useful modern client list?

  258. MattJ

    On the page you linked: s/Pidgin/Gajim/;s/Adium/Beagle IM/

  259. MattJ

    I'll let you make the call for Android :)

  260. Ge0rG

    yeah, it's obviously s/Yaxim/yaxim/

  261. MattJ

    Pidgin and Adium are borderline unmaintained right now (I know they have hope to revive Pidgin's XMPP support Soonโ„ข, but I'm not holding my breath, and Adium basically has no developers at all)

  262. Ge0rG

    MattJ: I am aware of that, but is Beagle a good modern desktop client?

  263. Ge0rG

    What about Swift.IM and Dino?

  264. Ge0rG

    Monal desktop probably isn't there yet

  265. MattJ

    Dino isn't officially packaged for Windows, and... I think it doesn't support MAM in MUCs yet (?)

  266. Zash

    MattJ: Accurate afaik

  267. Ge0rG

    MattJ: did you test BeagleIM on mac?

  268. MattJ

    and I haven't been following Swift recently, but pretty sure it's even further behind on that kind of thing

  269. MattJ

    No, I haven't

  270. MattJ

    That would require dusting off my Mac, which I do need to do at some point

  271. Ge0rG

    so there is no reliable recommendation for macOS?

  272. MattJ

    Beagle is using the same underlying code as Siskin, I don't have a problem with recommending it

  273. Andrzej

    the question is what moden client is?

  274. MattJ

    Not Adium

  275. Andrzej

    Beagle has the same set of features as Siskin and is based on the same library

  276. Ge0rG

    Andrzej: https://xmpp.org/extensions/xep-0423.html would be a good start :D

  277. MattJ

    If it supports MUC, HTTP upload, and MAM, we're pretty good I think

  278. Ge0rG

    MAM and Carbons

  279. Andrzej

    it has MUC, MAM:2, HTTP File Upload, VoIP (jingle/JMI), Carbons, MIX, Message retraction, last message correction, etc

  280. Zash

    And MAM in MUC?

  281. Andrzej

    it is available since latest release

  282. Ge0rG

    Andrzej: that's great!

  283. Andrzej

    VCardTemp, VCard4, PEP based avatars, stream management, XEP-0184, chat states (partially), user blocking,

  284. Andrzej

    I would say it almost matches CS2020 as it is missing Jingle File Transfer and `/me` command

  285. Ge0rG

    WHAT? NO /me?!?!

  286. Zash

    THE MOST IMPORTANT XEP OF ALL!!!11!!!1

  287. Ge0rG is disappointed

  288. Seve

    Hah

  289. Zash

    Someone actually told me once that XMPP wasn't acceptable because of a client that didn't do /me

  290. Andrzej

    I do not fell that I'm missing something due to lack of `/me` but someone would report that as a feature maybe it could be added

  291. Andrzej

    I do not fell that I'm missing something due to lack of `/me` but if someone would report that as a feature maybe it could be added

  292. Ge0rG

    Technically, it's `/me `

  293. Zash

    Weird semantics-shoehorned-into-<body> thing, but it's one of those small details.

  294. pep.

    Zash: may I remind you a sentence of yours this day :p

  295. Zash

    ?

  296. pep.

    โ€œGiving up and adding more hacks isn't going to help with thatโ€

  297. Zash

    Well-established hack dating back to IRC behavior.

  298. Zash

    If you come up with a way to do this in a more XMPP-ish way, I'm all ears. Or eyes.

  299. Ge0rG

    Zash: technically, the wire-format is not from IRC. The XMPP variation added a hack on top of XMPP

  300. Zash

    message { is-action body "is doing stuff" }

  301. mdosch likes /me

  302. Zash

    Ge0rG: Why I said "behavior", not protocol. :)

  303. mdosch

    > mdosch likes /me But not when someone is quoting it as you don't know anymore who is /me

  304. mdosch

    Woo, conversations changed that.

  305. Ge0rG

    I wonder if I should steal that

  306. Daniel

    this seems like a bug

  307. mdosch

    Do it!

  308. Daniel

    unless you do it properly of course

  309. Zash

    a featurebug!

  310. Zash

    Speaking of which, where'd references & co go?

  311. MattJ

    Andrzej, https://github.com/tigase/beagle-im/issues/50 - you're welcome :)

  312. pep.

    well the good thing about stuffing everything in body is that clients don't need support!

  313. Ge0rG

    is Siskin in a usable state for end users?

  314. Ge0rG

    I had to give away my iPhone recently

  315. Andrzej

    I would say "yes", but it depends on what you expect from the app, used server, etc.

  316. MattJ

    I would say "no", but that also applies to most software I use and write every day... :)

  317. Ge0rG

    Andrzej: a client where a technically competent person can set up an account and join a MUC without jumping through burning hoops or running into dead ends (failure without error messages etc)

  318. MattJ

    I haven't tried the latest release yet, but I think all the issues I could find are reported as fixed

  319. Ge0rG

    cool

  320. Andrzej

    MattJ, yes they are fixed

  321. Andrzej

    and some parts of the UI are simpler now

  322. Ge0rG

    is it reasonable to list Dino as a Linux client?

  323. MattJ

    Nice

  324. MattJ

    Ge0rG, I worry about it not supporting MUC MAM

  325. Ge0rG

    MattJ: yaxim doesn't either. MUC history seemed good enough for me

  326. MattJ

    In a MUC-focused deployment, that will be a weird cause of confusion if Dino users only see some of the history

  327. Ge0rG

    Also the interaction between MAM and joining a room is bad.

  328. Ge0rG

    whoever invented that...

  329. theTedd is currently working on *something* re: badges (we can always fiddle with the design) and compliance suites (current, history, future directions)

  330. Ge0rG

    theTedd: that's exciting!

  331. theTedd

    also, Ge0rG, I had some suggestions for CS (actually from last time, but I didn't want to interrupt the process) - let me know whenever you're mentally prepared ๐Ÿ˜‰

  332. Ge0rG

    theTedd: I totally loved your badge generator workflow, maybe you can make it work out of DOAP?

  333. Ge0rG

    theTedd: just pile them on https://github.com/xsf/xeps/pull/980

  334. theTedd

    I have considered that, in addition to just dumping a text list of xeps

  335. Ge0rG

    theTedd: I'm currently mentally not able to do useful discussion, but feel free nevertheless

  336. theTedd

    that's what I presumed; it's more ideas/discussion than PR suitable

  337. Ge0rG

    and re badges, I thought about putting the level and year on the RHS of the badge, something like [Mobile Client: 2020 Core] with colorcoding of advanced>core and 2020>2019>...

  338. Ge0rG

    </bikeshed>

  339. theTedd

    I will be doing colours by year (shades of green through orange and red)

  340. theTedd

    related question: is there anything for a client to actually implement for XEP-0411 (Bookmarks Conversion) ?

  341. Zash

    If it has code to do bookmarks conversion itself, disable that if it sees the feature.

  342. theTedd

    I was wondering whether it makes sense to have it as a requirement in the CS for clients (it currently is for IM Advanced)

  343. Ge0rG

    theTedd: yes, because both legacy bookmark formats are mandatory for Advanced IM Client

  344. Ge0rG

    so if you have a server that does 0411, you'll end up with duplicate bookmarks

  345. theTedd

    right, okay

  346. theTedd

    in other news:this muc kicks me if I join from jabber.org (which may be justified)

  347. mdosch

    You can't join or you get kicked?

  348. theTedd

    it joins, sync, and is then immediately kicked with "Kicked: jid malformed" (errors 333 and 110)

  349. theTedd

    I'm assuming it's actually a S2S issue

  350. pep.

    your client sending an error to the muc?

  351. mdosch

    But yeah, jabber.org is difficult. My s2s to it is broken for a long time. First we didn't share a cipher, now I can't validate the cert and it relies on dialback which is diabled here.

  352. Zash

    A 199 ping from jabber.org to muc.xmpp.org seems to get there and back just fine

  353. Ge0rG

    theTedd: sounds like one of the nicknames here causes jabber.org to freak out

  354. Ge0rG

    I blame Rixon ๐Ÿ‘๐Ÿ—จ

  355. Ge0rG

    You receive initial presence, your server dislikes it and bounces the stanza, you get kicked

  356. Zash

    This can be from the Prosody MUC code if your nickname does not satisfy resourceprep in "strict mode"

  357. Zash

    ... or maybe not

  358. theTedd

    joining jdev and council worked, so yeah it's probably a nick

  359. Zash

    Mmm, yeah, looks like Rixon ๐Ÿ‘๐Ÿ—จ

  360. Zash

    Oh wait, the "strict mode" thing isn't in a release, so never mind.

  361. eta

    MattJ: lack of MUC MAM is definitely an issue

  362. eta

    Ge0rG: you just don't notice it on yaxim because your phone is nearly always on

  363. Ge0rG

    eta: that's true. Also I've configured my rooms to keep 500 messages and to return 50 by default

  364. Ge0rG

    and yaxim will poll for history since the last message's timestamp. That's absolutely not prone to race conditions!