XSF Discussion - 2019-12-19

  1. Ge0rG shakes fist at xmpp.net... "504 Gateway Time-out"

  2. Guus

    There's something off there, that we can't quite put our fingers on.

  3. Ge0rG

    okay, qualys hangs as well

  4. Guus

    wow, I got a blinking notification in my favicon thingy as soon as I opened the first google hit for "qualys"

  5. Guus

    that's a sure way to have me close a browser tab in record time.

  6. Ge0rG

    blinking favicons. lovely

  7. Ge0rG

    the only thing even worse is "randomnews.example wants to access your location"

  8. Guus

    "wants to send you notifications"

  9. Guus

    I actually don't always mind sharing my location (eg: weather updates)

  10. pep.

    Guus, "randomnews.example wants to access canvas" also

  11. Zash

    There's access control for canvas now?

  12. Guus

    I've never had that

  13. pep.

    Zash, it's been a while

  14. Ge0rG

    everything in web is horrible

  15. Guus

    I'd love to imagine what you could write on Chrismas cards... 😉

  16. dwd

    "Wishing You a Merry Christmas. Somebody must get one, after all, and it couldn't be any worse that last Christmas."

  17. jonas’

    I think it’s indeed hard to have anything worse than Last Christmas ("I gave you my heart")

  18. Seve

    But the very next day..

  19. jonas’

    I heard it TWICE this year already, and I’m neither proud nor happy about that

  20. Link Mauve

    Here the government is kind of preventing Christmas, by forcing their pension reform upon us and we don’t like that.

  21. pep.

    And they still have the guts to ask for a break for christmas :)

  22. dwd

    Link Mauve, Trust me, you have no reason to complain at your government.

  23. Link Mauve

    Trust me, we do. :p

  24. dwd

    Try living in the UK.

  25. Link Mauve

    Not diminishing yours in its terribleness of course.

  26. Link Mauve

    I did try that for quite a while. :p

  27. Link Mauve

    But you never let me vote for an election which matters.

  28. Guus

    having a vote on stuff that matters didn't turn out to be much of an improvement...

  29. Link Mauve

    True, your latest one was a disaster once again.

  30. Zash

    You all need Fully Automated Luxury Space Communism!

  31. Guus

    I had to google that.

  32. Zash

    Joining a potato farming collective is also an alternative to consider.

  33. Guus

    I'm from the Netherlands. We _are_ a potato farming collective.

  34. Ge0rG

    pot-ah-to or pot-ay-to?

  35. Zash


  36. Guus


  37. !XSF_Martin

    > I'm from the Netherlands. We _are_ a potato farming collective. You switched to potatoes after the tulips bubble collapsed?

  38. !XSF_Martin

    Ah, it's called tulpenmanie

  39. Guus

    apparently, we produce about 3 billion tulip bulbs annually.

  40. Guus

    assuming that an average potato weighs about 100 grams, we do ~70 billion potatoes.

  41. Guus


  42. Guus

    (potatoes are probably a lot cheaper though)

  43. dwd

    Guus, Maybe I should invest in tulips, then.

  44. !XSF_Martin

    dwd: Don't https://en.m.wikipedia.org/wiki/Tulip_mania

  45. Guus

    I like how !XSF_Martin is single-handedly trying to save us from another event like the crash that happened in February 1637.

  46. pep.

    Almost time?

  47. MattJ


  48. ralphm bangs gavel

  49. Guus

    I appear to be here, against all odds.

  50. ralphm

    0. Welcome

  51. pep.


  52. ralphm


  53. ralphm

    Who do we have?

  54. MattJ


  55. pep.

    Seve was here ealier?

  56. Seve


  57. pep.


  58. ralphm

    Also, I'm expecting a contractor to show up at my door between now and 16:00, so I might have to leave early.

  59. ralphm

    1. Minute taker

  60. Guus

    (as if those ever show up on time)

  61. pep.

    Can do

  62. nyco

    I'm on it: https://mensuel.framapad.org/p/9dye-cfzbnvup1y-XSF-board-weekly-2019-12-19

  63. pep.


  64. ralphm

    Thanks nyco!

  65. ralphm

    2. Board Mailing List

  66. nyco

    my contractor is there tomorrow morning :)

  67. ralphm

    I've saw a few mails around this subject, and I'd like to reiterate my view:

  68. ralphm

    The board@xmpp.org mailing list is specifically for non-public discussions and silly things like sending regrets for meeting attendance. We aim to do as much as possible in the open, either here or on the members' mailing list.

  69. ralphm

    Non-public stuff would include discussions on particular individuals, eg. bad behavior. I don't see a lot falling in this category.

  70. pep.

    I've raised the subject because I haven't seen anything explicit about this.

  71. ralphm

    As for the archive, I actually don't know if it is archived currently.

  72. Seve

    One thing to mention as well, the board@xmpp.org address can be used as well to receive emails from people outside our communitiy, trying to get in touch with the Board. So in that sense this cannot be public.

  73. pep.

    Seve, cannot is a strong word

  74. Seve

    pep., either we create a contact@xmpp.org or we cannot make it public

  75. ralphm

    pep., you may not have, and I'm not entirely sure how to make sure we do going forward. Like a standing list of decisions on a wiki might be a good thing, but I'm not sure how unweildy that could become.

  76. pep.

    That'd be a first step I guess

  77. MattJ

    A general observation: I think there is much about the running of the XSF that is currently undocumented

  78. pep.

    Like a "board decisions" category on the wiki or sth

  79. pep.

    MattJ, agreed

  80. Guus

    let's stay on point though.

  81. MattJ

    Board decisions are buried in minutes, but there are other things that are often just a verbal "This is the way we do things, this is the way we have always done things"

  82. ralphm

    I'm happy with such a decision list, with identifiers like 20191219-001

  83. ralphm

    So you can refer to the original discussion dates.

  84. ralphm

    (I've seen this in many other orgs)

  85. MattJ

    Sounds good

  86. pep.

    A bit cryptic to me, but I'm happy to bikeshed once we've agreed that this needs doing

  87. ralphm

    I was going for a date and a sequence number, but whatever you want.

  88. pep.

    So do we agree that members@ is the venue we want to use? and board@ only when things need to be private? (when is that even6)

  89. ralphm motions we will keep a public list of Board decisions, on our wiki, using identifiers that help finding context (much) later.

  90. ralphm


  91. Guus


  92. pep.


  93. ralphm

    pep., yes members is our venue by default

  94. MattJ


  95. ralphm


  96. Seve

    I didn't know that was the point, but to that sentence I'm +1

  97. Seve

    I didn't understand that was the point, but to that sentence I'm +1

  98. pep.

    That wasn't (in my agenda items) but it's an underlying issue

  99. pep.

    What about the list history? Is it kept somewhere?

  100. pep.

    If not can we? And if so can we open it?

  101. Guus

    As far as I know, Peter answered that correctly. We might want to ask iteam to have another look, as I think having history would be nice.

  102. ralphm motions that we re-affirm Board uses public communications channels (such as members@xmpp.org, xsf@muc.xmpp.org) as much as possible, and board@xmpp.org is strictly for matters that are (initially) confidential.

  103. ralphm

    (sorry, I was typing for a while)

  104. pep.


  105. ralphm


  106. Guus


  107. Seve

    Perfect ralphm :) +1

  108. MattJ


  109. Kev

    ISTM that if conversations have to be confidential, possibly not archiving them is ok?

  110. ralphm

    pep., as I said, I honestly don't know if we keep archives of board@. MattJ ?

  111. MattJ

    I don't believe we do

  112. Kev

    I do not believe board@ is archived.

  113. ralphm

    Kev, I think so

  114. ralphm

    both motions carry and will be the first to go on the wiki, yay!

  115. Guus

    For reference: Peters answer mentioned technological challenges to getting a non-public archive realized.

  116. ralphm

    I'm curious about those, but I agree with Kev that this might be a thing we shouldn't do

  117. Guus

    I don't agree with that.

  118. pep.

    I don't agree with Kev on this point. And I'm curious about the technical issue

  119. Guus

    it might be very benificial for new boards to be able to read back.

  120. Guus

    I don't, however, think this is so valuable that we should spend a lot of effort on this.

  121. pep.

    But if it's a technical issue I'm happy to leave it be until iteam changes software (maybe)

  122. ralphm

    I do know that I have private mailman lists (as administrator) on ik.nu, and that's not been an issue

  123. Kev

    Guus: I guess the question is "What is the issue that means that members should not be able to access the discussion history?".

  124. Kev

    Because I'm prepared to bet that lots of those are cases where potential future Board members likely shouldn't be privy to it either.

  125. MattJ

    Having new Board members able to read previous discussions I think would be a desirable thing - especially in the case where issues are ongoing at the point of a handover

  126. Guus

    Kev members or general public?

  127. Kev

    (Well, 'lots of those cases'. I believe that such instances are rare in the first place)

  128. ralphm

    Sorry gotta leave.

  129. Guus steals gavel.

  130. Kev

    MattJ: I think in such a case it would be very appropriate for old Board to brief new Board directly.

  131. Kev

    Guus: They're basically one and the same :)

  132. MattJ

    Brief != access to raw data

  133. Guus

    not really

  134. MattJ

    i.e. the outgoing Board then has full control over the narrative passed to the new Board

  135. Guus

    for example when discussing negotiations with outside entities

  136. Kev

    Guus: Find a nominal member of the general public who shouldn't have access to a discussion while a member should, and then how that public person would be prevented from joining :)

  137. Guus

    might be relevant to keep that under board/membership and not the outside world, pending negotiations (we've had some examples with making our minds up about the way to work with sponsoring, copyright, things like that)

  138. Guus

    Is there anyone here that wishes us to further look into (technical) possibilities to realize such an archive at this point?

  139. Guus

    (if not, I'd like to move on)

  140. MattJ

    I'm fine with things as they are right now, though would be open to making this a potential iteam todo later down the road

  141. Guus

    that's the same for me

  142. pep.

    I'd like to have it if it's technically possible. If it's an issue with our software then maybe moving to something else (mailman3?) would be benefitial (also for other things). I'm not rushing iteam but I want this to be considered

  143. pep.


  144. Seve

    An archive for board@xmpp.org accessible by Board?

  145. pep.

    Seve, yes

  146. Seve

    Then what MattJ said sounds very good to me, indeed

  147. Guus

    ok - MattJ with your iteam hat on, will you commit to look into technical feasibility?

  148. MattJ

    With my iteam hat on, iteam has more pressing todo items unless Board considers this high priority (and I'm not sure most of us do)

  149. pep.

    Well I'm in board and I already don't have access anyway so I guess we got at least a year :-°

  150. Guus

    pep. can you agree to this being a low-prio thing?

  151. pep.


  152. pep.

    Well, lower priority than other things

  153. Guus

    I've moved the Trello card to the backburner lane

  154. pep.

    Not low priority

  155. pep.

    (If there is a semantical difference here)

  156. Guus

    let's circle back to this once iteam has found the time to look into it.

  157. MattJ


  158. Seve


  159. Guus

    We've got five minutes let.

  160. Guus


  161. Guus

    I'd like to tackle this item from trello: Consider speaking out about savedotorg.org

  162. Guus

    as that is going to be outdated soon.

  163. Guus

    Do we want to pursue this?

  164. Guus

    (speaking out publicly)

  165. pep.

    I don't see why we wouldn't

  166. Guus

    In a previous meeting, we postponed discussing this topic, to give board members time to read up.

  167. pep.

    I don't think we especially have to write something about it

  168. Seve

    So do we have to take any actions?

  169. Guus

    I personally do not want to publish anything about this. Sure, I don't like what's going on, but I am not concerned that it will have the impact big enough for us to speak out against it.

  170. MattJ

    Many larger organisations than ours have already spoken up. That doesn't mean we shouldn't, but also ICANN are reviewing the situation - I'm not sure "speaking up" will make a difference to the outcome in any meaningful way.

  171. pep.

    But not saying anything about it is also saying something about us.

  172. pep.

    Especially now that we're aware of it

  173. Seve

    What should be acceptable then? A tweet?

  174. MattJ

    I'm on the fence between speaking up and just avoiding getting involved in the latest internet outrage currently top of peoples' minds

  175. Guus

    let me put it this way: I'm not seeing anything that we should voice concerns about. It's more of an internet outrage (thanks Matt) than an actual issue, in my opinion.

  176. Guus

    I've read some texts about potential far-reaching effects of this that I absolutely don't agree with.

  177. MattJ

    There is the possibility that the transition will allow the increase of .org pricing. I find it hard to believe this will affect us in any way (if the XSF and other organisations cannot afford their domains, switching is painful but possible)

  178. Guus

    sure, it's a bastard move from people wanting to make money - but I don't feel that this is going to significantly hinder free speech, or anything to that extend.

  179. MattJ

    Then there is the possibility that the deal was under-handed in some way. I don't think we know enough to pass judgement on this.

  180. MattJ

    Nor is it necessarily our place to get involved in that debate

  181. MattJ

    (when as I said, I don't think it would affect the outcome in any way)

  182. Seve

    Sounds wise

  183. Guus

    do we want a vote on this?

  184. MattJ

    Don't see why not

  185. pep.

    I guess there is consensus. I don't especially agree but I'm not going to block it

  186. MattJ

    We need to fill up that wiki page

  187. Guus motions that the XSF chooses to not make a public statement about savedotorg.org at this time, without ruling out that future developments might reverse this decision.

  188. MattJ


  189. Seve


  190. Guus


  191. pep.


  192. Guus

    Motion passes.

  193. Guus

    Our time is up.

  194. Guus


  195. MattJ

    None here

  196. Seve

    Thanks nyco for the minutes :)

  197. pep.

    I had one but it's been discussed (wiki stuff)

  198. pep.

    Nothing else

  199. Guus

    I'd like to mention two things:

  200. Guus

    1. GSOC has been announced. If we want in, we should act before mid january. Let's think about that.

  201. Guus

    2. People interested in joining the Summit or FOSDEM should subscribe to the summit mailing list.

  202. Guus

    date/time of next

  203. Guus

    as +1 week is Chrismas, I propose +2w

  204. pep.

    I can do both.

  205. pep.

    I'm fine with +2w

  206. Seve

    I can do next week, but probably not until two weeks after (not sure yet)

  207. MattJ

    +2w wfm

  208. Guus

    I can't make it next week.

  209. Seve

    So that settles it :)

  210. Guus

    lets do +2w

  211. Guus

    happy holidays!

  212. MattJ


  213. pep.

    Thanks all.

  214. Guus bangs gavel, carefully places it back on Ralphs bench.

  215. Seve

    You all too! Thank you for the mmeting

  216. MattJ

    Thanks all

  217. pep.

    I guess I forgot an AOB, and I already said last week I'd take that to the list. I'd like to stop having meetings be at the center of what we do. Topics for discussion can and should be taken up to the list first IMO, to give a choice to anybody (board mostly but also members) to express their opinion and not be simply ignored because they can't participate in meetings.

  218. pep.

    I'll take that to the list now.

  219. Guus

    I agree - it'll make us a lot more effetive.

  220. nyco

    please review: https://mensuel.framapad.org/p/9dye-cfzbnvup1y-XSF-board-weekly-2019-12-19

  221. Guus

    nyco for future reference: I think it's better to explicitly note in the minutes if a motion passes or not. That removes any uncertainty.

  222. pep.

    And also add ACTION points, imo

  223. Guus

    I've added it to todays minutes (and thanks for doing them in the first place)

  224. pep.

    If there are any

  225. pep.

    A decision without any action is :x

  226. pep.

    (generally not useful)

  227. nyco

    be my guest

  228. pep.

    Yep I'm adding it

  229. pep.

    Thanks for writing all this :)

  230. nyco

    if there are actions, they you should maintain/track/follow such a list, for example in a Trello, or whatever, and review the status at each meeting

  231. nyco

    otherwise, actions are lost

  232. pep.

    I want automation really. I don't think trello is much better tbh

  233. nyco

    Trello is only a tool, nothing there is automated

  234. pep.

    I want a bot or sth we can talk to directly in meetings or on list that would be our source of truth (?) potentially posting stuff on the wiki or sth

  235. pep.

    (or on trello or..)

  236. nyco

    the goal for a team is to share, track, overview

  237. nyco

    a bot is only another tool (that adds one more layer, btw)

  238. pep.

    "automation", whatever form that takes, is good to take

  239. nyco

    "Actions review" should be an agenda item then

  240. pep.


  241. nyco

    not always

  242. Guus

    Yeah - plus, putting in effort to write a bot requires a lot more effort than manually keeping things updated in tools we use now.

  243. pep.

    Maybe you're not seeing the same things I am seeing

  244. nyco

    automation rocks when there is already a routine

  245. pep.

    Anyway, that's all ifs for now

  246. nyco

    for now, actions is a new stuff, and it is not tracked, whether it is automated or not, that's not in question

  247. Guus

    I'm off. ttyl!

  248. nyco

    I'd rather say actions are a matter of (the sum of) individual capacities

  249. pep.

    Minutes look good to me now

  250. nyco

    yes, indeed, collective effort, that was my aim

  251. nyco

    I'd love that to continue

  252. nyco

    I'd love to avoid a truck/bus factor

  253. nyco

    I'd love not to miss any more Board minutes like we have been so good at :)

  254. pep.

    I did miss last week. Even if there wasn't any official meeting we did talk about $things.

  255. pep.

    Or even just to say there was no meeting

  256. nyco

    be my guest

  257. nyco

    the logs are available

  258. pep.

    Yeah, let me send that quickly.

  259. nyco

    thx a lot

  260. nyco

    minutes sent, thx all!

  261. pep.

    Sent last week as well.

  262. pep.

    Thanks nyco

  263. nyco

    thx pep. now there are two actions, none are tracked, one is not assigned

  264. pep.

    Better than no actions at all? :)

  265. pep.

    We can review past actions next week for sure.

  266. pep.

    And make that a habit

  267. edhelas


  268. dwd

    How did Mozilla, which employs a bunch of XMPP experts, end up choosing Matrix? Did anyone know this was being chosen?

  269. pep.

    They discarded XMPP early on

  270. Zash

    XMPP is not a product. They were looking for products.

  271. Daniel

    dwd: what xmpp experts do the employ?

  272. pep.

    and they're using the hosted versions the article says, ugh.

  273. dwd

    Daniel, Joe, Peter, Jack, M&M. Many aren't very active. But it's massively disappointing to me that XMPP isn't a serious competitor.

  274. MattJ

    What Zash said. Not surprising.

  275. MattJ

    XMPP is a protocol, Matrix is a stack from protocol up to official clients for all platforms.

  276. edhelas

    dwd the issue was not about XMPP, but the lack of client that "looks like" Mattermost/Riot/Slack…

  277. pep.

    dwd, what Zash said. Name a single viable product to compete with Matrix or Slack that is also free software

  278. Daniel

    dwd: thanks. I was just asking out of curiosity.

  279. Daniel

    To be fair. The open source tooling we have that you can just start using right now is kinda bad

  280. MattJ

    dwd, they were pretty open about this whole process (which has been going on for months), but I don't think there is any XMPP solution I would personally stand behind as meeting their requirements

  281. MattJ

    And I assume the same applies for everyone else who didn't submit a proposal to them

  282. larma

    They also use the modular.im hosted service instead of hosting theirselves. I guess they really just wanted slack, but not slack (= a fully-managed, cloud-hosted, mostly centralized chat solution with good web client)

  283. pep.


  284. pep.

    fwiw Matthew (Matrix) told me directly at POSS that they would work again on the XMPP bridge, so we'll see..

  285. larma

    literally everytime i have met any matrix fan or employee they were telling that 😀

  286. pep.


  287. Ge0rG

    and they immediately start the marketing machine: https://matrix.org/blog/2019/12/19/welcoming-mozilla-to-matrix/

  288. pep.

    Ge0rG, you surprised?

  289. Ge0rG

    pep.: not at all. I'm rather sad about the lack of a comparable machinery (or a /product/ to brag about) in xmpp land

  290. larma

    They worked hard for it for about 4 years, so obviously they are happy about the achievement 😀

  291. pep.

    Ge0rG, bring monies to the XMPP.

  292. larma

    https://discourse.mozilla.org/t/matrix-and-irc-mozillians-custom-client/2911/7 < completely neutral pros and cons there

  293. Ge0rG

    pep.: hey, that was my argument!

  294. Ge0rG

    pep.: so how much is an xmpp-based IM product that I can deploy in March 2020?

  295. pep.

    You'd need money from VCs!

  296. pep.

    Start now

  297. Zash

    MattJ: So how's that Hype Machine coming?

  298. MattJ

    It's hyper

  299. Ge0rG

    did you say it's hyped?

  300. Zash


  301. larma

    pep., Ge0rG, I think the main issue is rather that all XMPP clients have severely different feature sets and UX. Most of them are fine. Conversations is solid, Converse.JS also works pretty good. But both have features that the other one doesn't have, so you end up with the smalest common feature set and also the UI is completely different. Also conversations is more focused on private chat and less on organization chat (converse does a better job for the latter)

  302. Ge0rG

    larma: let me tell you about Riot for Android and RiotX ;)

  303. Ge0rG

    larma: but you are fully right of course. Which is why I've been pushing for Easy XMPP and Compliance Suite

  304. larma

    I don't really think compliance suite will help. It will always be the smalest common feature set everyone can agree on, and that won't be enough

  305. Ge0rG

    larma: the alternative is to have a team like Xabber or Tigase provide a set of apps for all major platforms

  306. edhelas

    i think it's also more about the UI

  307. edhelas

    having the same colors, buttons

  308. larma

    edhelas, true, also chat bubbles vs the other thingee (is there a name for it)

  309. Ge0rG

    edhelas: for corporate use, yes. for a community like mozilla, probably not so much

  310. larma

    Ge0rG, Tigase hardly has the same feature set across platform last time I checked

  311. Ge0rG

    the chat bubble has burst in 2004.

  312. Ge0rG

    larma: I'm sure that Xabber iOS will be the bestest of all XMPP clients, though.

  313. larma

    it will probably take the ugly parts of other iOS XMPP clients and combine it with the ugly parts of other Xabber clients 😀

  314. Daniel

    Conversations 3.0 will probably get rid of bubbles.

  315. Ge0rG

    larma: who am I to judge ugliness of xmpp clients?

  316. Daniel

    But yes not having an entity that can provide a unified product is a big hurdle

  317. Daniel

    And compliance suites and the so called easy xmpp wont solve that

  318. Zash

    What you need is to have a single well-funded company do everything.

  319. Ge0rG

    Daniel: speaking of easy xmpp, MattJ and Zash and me have a first prototype of XEP-0401 with minor protocol changes at https://gist.github.com/mwild1/088b89ea6073671ff33b4303f222a0e9 - would you mind adding that to conversations?

  320. Ge0rG

    Zash: (pep.) > Ge0rG, bring monies to the XMPP.

  321. Daniel

    Ge0rG: I currently have no plans for that

  322. Daniel

    But I am happy to see support for pre auth

  323. Ge0rG

    Daniel: it's also fixing your major issue with 0379 - the tokens are completely handled by the server

  324. edhelas

    small question, where can I store the password in Bookmark 2 ? I see it was removed

  325. MattJ

    You can't (in any standard way)

  326. Ge0rG

    store it in the JID :P

  327. Zash

    MUC Passwords considered harmful

  328. Ge0rG

    /join `pwgen`@chat.yax.im

  329. edhelas

    ok :D

  330. MattJ

    Ge0rG, but security!

  331. edhelas

    so I'll go with members based

  332. Ge0rG

    Zash: s/Passwords//

  333. Ge0rG

    edhelas: yeah, private, hidden, members-only

  334. Zash

    I can't remember seeing an actual password-protected MUC

  335. Ge0rG

    I'm still member in one.

  336. dwd

    Zash, That's because they're all hidden too.

  337. Ge0rG

    Unfortunately, all the other members have vanished.

  338. Zash

    We got a bug report about handling MUC passwords insecurely in Prosody. But we need to because they're supposed to be included in plain text in invites.

  339. Ge0rG

    if only we had invitation tokens. What about per-occupant-JID MUC passwords?

  340. Zash

    That might be doable without protocol changes?

  341. Ge0rG

    it totally is

  342. Ge0rG

    but you can't request an invitation to a members-only MUC

  343. dwd

    Ge0rG, Can't you?

  344. Zash

    Ge0rG, can you invite me to The Secret Room?

  345. Zash

    ^ see

  346. Ge0rG

    Zash: you and me are in the same MUC, and you know my JID and you know that I'm online right now.

  347. Ge0rG

    Zash: imagine a room with multiple admins of which you know none directly.

  348. dwd

    Ge0rG, I meant https://xmpp.org/extensions/xep-0045.html#register and https://xmpp.org/extensions/xep-0045.html#regapprove

  349. Ge0rG

    dwd: can you do that from the outside?

  350. Ge0rG

    I haven't seen an implementation of that anyway.

  351. Ge0rG &

  352. Zash

    The text seems to be specifically about that case.

  353. Zash

    I forget if the Prosody implementation of this allows it, can check.

  354. Zash

    Tho it was more focused on registering your nickname

  355. dwd

    Guus, Doesn't Openfire do that ^^ ?

  356. Zash

    Didn't know this was in 0045.

  357. Guus

    What what?

  358. Guus

    Registering yes. Regapprove, don't know

  359. emus

    > XMPP is a protocol, Matrix is a stack from protocol up to official clients for all platforms. Even more, there are more or less central instance in a decentral network which is in my view not there for xmpp unfortunately

  360. pep.

    I started this: https://wiki.xmpp.org/web/Category:Board. All these templates might not be useful ("Board" might be enough), but that's details

  361. Zash

    emus, I'm not sure that having a single central gigantic instance is a sign of health for a federated network/protocol. jabber.org being a half-dead zombie is in a way a sign of maturity for XMPP. We can go on without it (but it make make a comback!)

  362. Kev

    "Half-Dead Zombie" - in the sense of running reliably.

  363. Zash

    I mean more in how registration has been temporarily closed for years

  364. pep.

    reliably? Why did we recreate jdev@ on muc.xmpp.org again? :)

  365. Kev

    Lack of interest in upgrading it, I think.

  366. Kev

    That was because of the dhparams I think, wasn't it?

  367. pep.

    Yep. Which causes many people being inable to join

  368. pep.

    Yep. Which causes many people being unable to join

  369. Kev

    Sure, but that has nothing to do with reliability.

  370. pep.

    To me it is pretty much the definition of it (and we can go on like this for a long time as long as nobody gives a definition of that word. Just like people use "stable" for pretty much everything)

  371. Kev

    I think our understanding of English is probably different.

  372. Kev

    To me, functioning as intended, consistently, and not failing would be reliable.

  373. Kev

    But, regardless.

  374. emus

    > emus, I'm not sure that having a single central gigantic instance is a sign of health for a federated network/protocol. jabber.org being a half-dead zombie is in a way a sign of maturity for XMPP. We can go on without it (but it make make a comback!) Im sure you see that I dont want a gigantic instance, but a resonable guidance / landing boat with some kind of official manner. still I agree its a good point its working (technically) without it

  375. emus

    And back to the central thing. not every characterisitc of central organisation is bad

  376. emus

    for the beginning it can make thing easier. i think you get my point

  377. Zash

    Based on my hobby archeology, I'd say it was, back in 1999-2004.

  378. Zash

    Back when you had a single server, a few clients, the Jabber Software Foundation and Jabber Inc.

  379. Guus

    dwd I checked: no manual approvement of nickname registration in MUC in Openfire.

  380. Zash

    Can those things be done in MIX?

  381. Zash

    I think I've seen something similar in XEP-0060, ie subscription approval, so maybe.

  382. emus

    Zash: I mean for the beginning for newcomers and companies interested