XSF Discussion - 2019-06-20


  1. karoshi has left

  2. neshtaxmpp

    moparisbest

  3. neshtaxmpp

    my friend server has serious access from 127.0.0.1, brute force from sshd here is log: https://bgzashtita.es/tefter/raw/VbNthqzNKV can someone help.

  4. wurstsalat has left

  5. neshtaxmpp

    my friend don't connect from 127.0.0.1, something illegaly connect from 127.0.0.1 and brute force my friend server for my friend password. maybe it is from sslh. can you comment how to compile latest sslh and show when ip is connecting in apache2 to show real ip and stop 127.0.0.1 from internet try connect my friend server.

  6. dwd has left

  7. dwd has joined

  8. dwd has left

  9. lnj has joined

  10. eevvoor has left

  11. dwd has joined

  12. lumi has joined

  13. marc_ has left

  14. mr.fister has left

  15. moparisthebest

    neshtaxmpp, lol 127.0.0.1 is localhost, ie your friends own computer

  16. moparisthebest

    but also every ssh on the internet that accepts password auth is bruteforced 100% of the time, fact of life

  17. moparisthebest

    neshtaxmpp, set up this https://linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/

  18. mr.fister has joined

  19. dwd has left

  20. dwd has joined

  21. lumi has left

  22. dwd has left

  23. dwd has joined

  24. lnj has left

  25. pdurbin has joined

  26. neshtaxmpp

    moparisthebest: my friend server dont connect to him from 127.0.0.1. something from my friend server is using sshd to someone connecr from 127.0.0.1 do you know how to investigate what make 127.0.0.1: here is log: https://bgzashtita.es/tefter/VbNthqzNKV

  27. neshtaxmpp

    here is other logs: https://bgzashtita.es/tefter/

  28. moparisthebest

    neshtaxmpp: and did you follow the link

  29. moparisthebest

    IP doesn't matter ignore it

  30. neshtaxmpp

    my friend dont want use with certificate. my friend want to use with password. he is ok if they try with they real ip. but he is not ok " he dont like " 127.0.0.1 to be used from sshd. moparisthebest you comment " 127.0.0.1 is his own server " so this is serious issue. do you know how can help my friend investigate and block 127.0.0.1 becouse you confirm 127.0.0.1 is his server. thanks

  31. moparisthebest

    Well then your friend is an idiot

  32. moparisthebest

    Hope he has a good password set up

  33. moparisthebest

    Read sslh docs if you want transparent forwarding with real IP

  34. pdurbin has left

  35. neshtaxmpp

    moparisthebest: do you have manuals that can work for debian... like compilong, what is necessary, what permission after compile, what directory, what plugins and etc. so it after make install work. ivan dont speak english so i translate him.

  36. moparisthebest

    Nope just sslh docs

  37. neshtaxmpp

    moparisthebest: some comands to investigate why and how 127.0.0.1 is connecting, when this 127.0.0.1 is for home access. official nobody outside my friend server can't connect from 127.0.0.1, then how is that possible.

  38. moparisthebest

    How many ways can I repeat myself

  39. moparisthebest

    Sslh docs

  40. moparisthebest

    Transparent forwarding

  41. moparisthebest

    Read docs from sslh

  42. moparisthebest

    Sslh documentation, have a look

  43. neshtaxmpp

    moparisthebest: How many ways can I repeat myself I dont understand them so i cant explain to him..

  44. moparisthebest

    Then I guess you are shit outta luck my friend

  45. lskdjf has left

  46. Yagiza has joined

  47. mimi89999 has left

  48. dwd has left

  49. dwd has joined

  50. dwd has left

  51. Yagiza has left

  52. mimi89999 has joined

  53. pdurbin has joined

  54. pdurbin has left

  55. lumi has joined

  56. lumi has left

  57. dwd has joined

  58. Nekit has joined

  59. dwd has left

  60. dwd has joined

  61. dwd has left

  62. Douglas Terabyte has left

  63. Douglas Terabyte has joined

  64. dwd has joined

  65. jonas’

    moparisthebest, don’t you have an IRC->XMPP gateway running?

  66. kokonoe has left

  67. kokonoe has joined

  68. Douglas Terabyte has left

  69. pdurbin has joined

  70. Kacper has joined

  71. rion has left

  72. rion has joined

  73. rion has left

  74. rion has joined

  75. goffi has joined

  76. valo has left

  77. pdurbin has left

  78. marc_ has joined

  79. COM8 has joined

  80. COM8 has left

  81. valo has joined

  82. Tobias has left

  83. Tobias has joined

  84. dwd has left

  85. dwd has joined

  86. sezuan has joined

  87. dwd has left

  88. valo has left

  89. valo has joined

  90. wurstsalat has joined

  91. sezuan has left

  92. sezuan has joined

  93. intosi has left

  94. intosi has joined

  95. intosi has left

  96. intosi has joined

  97. karoshi has joined

  98. dwd has joined

  99. edhelas

    what are the requirements to be part of the organization on Github ? https://github.com/orgs/xsf/people

  100. jonas’

    edhelas, asking nicely, probably

  101. alameyo has left

  102. alameyo has joined

  103. edhelas

    would it be possible to be added to be member of the XSF organisation on Github :3 ?

  104. COM8 has joined

  105. COM8 has left

  106. pdurbin has joined

  107. COM8 has joined

  108. Kacper has left

  109. Kacper has joined

  110. valo has left

  111. valo has joined

  112. COM8 has left

  113. Ge0rG

    edhelas: it would probably help to commit to some task, so that nobody gets an impression that you are doing it for the sake of having an organization badge on your profile.

  114. Ge0rG

    I'm sure the Editor team always needs a helping hand

  115. debacle has joined

  116. lnj has joined

  117. Tobias has left

  118. Tobias has joined

  119. pdurbin has left

  120. Steve Kille has left

  121. Kev has left

  122. Steve Kille has joined

  123. Steve Kille has left

  124. Steve Kille has joined

  125. Kev has joined

  126. Steve Kille has left

  127. Steve Kille has joined

  128. Kev has left

  129. Kev has joined

  130. edhelas

    I could have a look at the tasks yeah :)

  131. valo has left

  132. valo has joined

  133. Daniel has left

  134. Daniel has joined

  135. Tobias has left

  136. Tobias has joined

  137. dwd has left

  138. dwd has joined

  139. eevvoor has joined

  140. rtq3 has joined

  141. dwd has left

  142. goffi has left

  143. goffi has joined

  144. Daniel has left

  145. Daniel has joined

  146. dwd has joined

  147. karoshi has left

  148. karoshi has joined

  149. sezuan has left

  150. Kacper has left

  151. dwd has left

  152. dwd has joined

  153. Kacper has joined

  154. Syndace has left

  155. dwd has left

  156. Syndace has joined

  157. sezuan has joined

  158. dwd has joined

  159. rtq3 has left

  160. Kacper has left

  161. rtq3 has joined

  162. Daniel has left

  163. Daniel has joined

  164. dwd has left

  165. dwd has joined

  166. pdurbin has joined

  167. dwd has left

  168. Kacper has joined

  169. Syndace has left

  170. wurstsalat has left

  171. Syndace has joined

  172. dwd has joined

  173. dwd has left

  174. dwd has joined

  175. wurstsalat has joined

  176. dwd has left

  177. Syndace has left

  178. dwd has joined

  179. Syndace has joined

  180. andy has joined

  181. Syndace has left

  182. Syndace has joined

  183. Tobias has left

  184. Tobias has joined

  185. dwd has left

  186. dwd has joined

  187. lskdjf has joined

  188. dwd has left

  189. DebXWoody has left

  190. DebXWoody has joined

  191. dwd has joined

  192. winfried has left

  193. winfried has joined

  194. dwd has left

  195. dwd has joined

  196. kokonoe has left

  197. kokonoe has joined

  198. pep.

    vanitasvitae, I'm not sure I understand the discussion with disco for SCE?

  199. pep.

    Why would you need that. You'll have <eme/> with a namespace, and that namespace will tell you what encryption mechanism, and the encryption mechanism will be a profile of SCE, no?

  200. dwd has left

  201. lskdjf has left

  202. pep.

    let's try to formulate that in the email

  203. lskdjf has joined

  204. jonas’

    yes, the editor team could use helping hands

  205. lovetox

    pep., its not about detection if you receive a message

  206. lovetox

    its about sending a message

  207. lovetox

    you cant know if the recipient supports full stanza encryption or not

  208. pep.

    I think that's not the right question

  209. dwd has joined

  210. pep.

    You can know if somebody supports $encryptionMechanism, because they will be a dicovery mechanism for it most likely, just as OX and OMEMO have their key published

  211. lovetox

    there is none

  212. lovetox

    thats what the discussion is about

  213. pep.

    And all you care about is if somebody supports $encryptionMechanism, that will use SCE. You don't need to know about SCE itself

  214. pep.

    lovetox, well there is none because nobody is using SCE atm

  215. lovetox

    yeah and the email is about how one can discover if a client can use SCE or OMEMO V2 or whatever

  216. pep.

    I wouldn't use SCE itself

  217. pep.

    what for?

  218. pep.

    You only need to know if somebody supports OMEMO2, that uses SCE

  219. lovetox

    because you cant decrypt my message if you dont support sce

  220. pep.

    But that's an implementation detail knowing about SCE

  221. pep.

    If you support OMEMO2 you will support SCE

  222. lovetox

    and how do i know if someone supports omemo2?

  223. pep.

    Because they publish their keys?

  224. lovetox

    so you saying putting the info into pubsub for every device

  225. pep.

    urn:xmpp:omemo:0

  226. Tobias has left

  227. lovetox

    thats what the discussion is about

  228. Tobias has joined

  229. lovetox

    and its not as bad as in disco info, but still bad

  230. pep.

    Skimming through the thread though I really feel like it's not focusing on the right questions

  231. pep.

    how is that bad?

  232. pep.

    "Hey you want to talk to me, you know where to check for my keys. If there's nothing there, maybe I don't do $encryptionMechanism then"

  233. lovetox

    because there are multiple devices

  234. zach has left

  235. pep.

    sure, well that's already an issue with any e2ee thing

  236. lovetox

    you need to determine a overall state, from all devices, implement logic according to it

  237. pep.

    Or any feature at all

  238. lovetox

    and then you have to think about X cases

  239. lovetox

    what if one device only supports X

  240. pep.

    You don't want to do that because as mentioned, carbons etc.

  241. lovetox

    and the other only >

  242. lovetox

    Y

  243. pep.

    And then MAM..

  244. lovetox

    yes so its useless that there is one device publishing that it is omemo2 capable

  245. pep.

    You don't care if only one device supports it because there's no way of knowing

  246. lovetox

    you just said we CAN know with pubsub

  247. pep.

    Do you need to know though?

  248. lovetox

    so what is it now

  249. lovetox

    omg

  250. lovetox

    pep. this discussion makes me a bit tired :D

  251. pep.

    hmm?

  252. pep.

    I'm sorry it's the first time I go through this myself, I have seen it before though

  253. lovetox

    yeah i noticed :) just think about it from the point of a developer wants his users to have a flawless conversion to a new standard

  254. lovetox

    in this case there is no easy way

  255. lovetox

    either you make a hard cut someday

  256. lovetox

    or you implement lots of hacky logic that depends on multiple things, and will fail from time to time

  257. pep.

    I think if you want "perfect" you need to control the whole ecosystem

  258. pep.

    It's just not possible here

  259. lovetox

    yeah i would propose all clients impl read support for omemo with sce

  260. lovetox

    and in a year we switch to send support

  261. pep.

    I'm sorry I'll repeat but "omemo with sce" doesn't mean anything

  262. pep.

    sce is but an implemntation detail

  263. pep.

    "omemo:0" that will be, I guess :)

  264. lovetox

    or that :)

  265. dwd has left

  266. dwd has joined

  267. pep.

    (to clarify a bit, "384 with sce" doesn't mean anything*, is what I wanted to say)

  268. dwd has left

  269. dwd has joined

  270. COM8 has joined

  271. COM8 has left

  272. lumi has joined

  273. vanitasvitae

    pep.: the main point is, that xmpp has a lot of features. A client implementing sce would need to be able to properly handle all the features it supports additionally in an encrypted context.

  274. pep.

    What I'm saying is, a client won't implement sce by itself

  275. vanitasvitae

    Therefore it may be desirable to negotiate features like "i understand sce, but only for body, chat state and feature xyz"

  276. pep.

    hmm?

  277. pep.

    oh, wow

  278. pep.

    I wasn't even thinking about that, but now I'm confused

  279. vanitasvitae

    If you receive a message with a chat state notification, you want to know if it was contained inside a sce element or not.

  280. vanitasvitae

    (If it was encrypted or not)

  281. pep.

    "you want to know"?

  282. pep.

    You will know, by decrypting it, right?

  283. vanitasvitae

    Yes

  284. vanitasvitae

    Yeah but all your listeners need to be modified to differentiate between a protected message correction and a plain one.

  285. vanitasvitae

    As you probably want to communicate that to the user somehow

  286. vanitasvitae

    Like "watch out, this message correction was not encrypted"

  287. pep.

    Yeah no that was the part I didn't really understand, and even now that I have this missing piece of info, I still find this overkill

  288. pep.

    Sure you can do that already without discovering anything

  289. pep.

    There's no need for protocol support here

  290. pep.

    A client parsing a e2ee payload using sce will know what is and what isn't in the container

  291. pep.

    *an

  292. vanitasvitae

    That was my initial impression as well, but some people suggest it may be more complicated

  293. vanitasvitae

    Take smack for example. Literally all listeners in smack need to be rewritten to carry some sort of security information that tell the user how the triggering element was encrypted.

  294. pep.

    that's.. weird

  295. pep.

    Maybe the API is just not what it should be

  296. vanitasvitae

    For that reason it may be good to gradually start an implementation with just a subset of the features.

  297. vanitasvitae

    The thing is, that an sce message can contain encrypted and unencrypted elements at the same time

  298. pep.

    With slix I don't need all that

  299. vanitasvitae

    How does slix do listening for elements?

  300. pep.

    I mean I don't have an implementation of a container, but I see more or less how I could do it

  301. pep.

    "listening for elements"?

  302. vanitasvitae

    Hehe

  303. pep.

    You don't, you have a Message object and you lookup what you want to

  304. vanitasvitae

    Ah so slix works rather different to smack

  305. vanitasvitae

    in smack the user registers listeners for certain events and gets notified when a stanza for that event is received

  306. pep.

    There are also signals sent if your message contains X or Y, but most likely in a client you'll want to ignore these, and only use the helpers from the library

  307. vanitasvitae

    like for example if a chat state arrived, that will cause a listener to be fired

  308. vanitasvitae

    ah okay

  309. pep.

    Yeah you could also do that in slix, but I don't like it

  310. pep.

    Because then if I fire an event for "message" and an event for "eme" with the same message, now I have to have more global state in my app to know these are the same messages

  311. lumi has left

  312. vanitasvitae

    I see

  313. vanitasvitae

    So you suggest that SCE should be coupled to a new OMEMO namespace which then infers that the client knows how to handle any element inside the SCE content?

  314. Nekit has left

  315. pep.

    Maybe I'm missing some part of the picture, but I think SCE should be used by itself. It should be like 373/374, be used as profiles

  316. vanitasvitae

    I'll have to think about that 😀

  317. pep.

    For the encryption mechanism. What tag then goes inside is up to the sending client I guess?

  318. vanitasvitae

    what tag do you mean?

  319. Nekit has joined

  320. pep.

    payload, body, replace, etc. etc.

  321. vanitasvitae

    ah

  322. lumi has joined

  323. vanitasvitae

    ideally the sending client would put all elements inside the content, that do not concern the server.

  324. pep.

    sure

  325. pdurbin has left

  326. pep.

    The receiving client will know what's inside the encrypted payload, and can accordingly display a warning or not.

  327. vanitasvitae

    hm i think i like the idea of profiles.

  328. pep.

    There's a bit of handwaving here I agree

  329. vanitasvitae

    How would you signal what profiles a client supports?

  330. vanitasvitae

    I think the best way is to couple that information with the published keys somehow.

  331. lovetox

    vanitasvitae, there should only one single profile for omemp

  332. bitumani has joined

  333. lovetox

    really we should not get into the situation that one resource supports X and another Y

  334. pep.

    yeah, it'll be urn:xmpp:omemo:0, that is a profile of SCE

  335. vanitasvitae

    Aggreed

  336. vanitasvitae

    But what about ox? :P

  337. vanitasvitae

    OX:1?

  338. pep.

    sure

  339. vanitasvitae

    Alright

  340. vanitasvitae

    Sounds reasonable

  341. lovetox

    and yeah except for a gajim plugin there is no support in the wild for OX, so i think OX is easy to update

  342. lovetox

    ah and your smack impl, but i dont know if you published it

  343. rion has left

  344. bitumani has left

  345. bitumani has joined

  346. bitumani has left

  347. rion has joined

  348. dwd has left

  349. dwd has joined

  350. dwd has left

  351. Kacper has left

  352. Kacper has joined

  353. Yagiza has joined

  354. nyco

    t-1 min

  355. nyco

    ding

  356. Seve

    Dong

  357. nyco

    \o/

  358. Guus

    hi

  359. nyco

    where's the gavel?

  360. Guus eyes ralphm

  361. ralphm

    Sorry, I was distracted.

  362. ralphm bangs gavel

  363. Guus mentions MattJ

  364. ralphm

    0. Welcome + Agenda

  365. ralphm

    MattJ has sent regrets.

  366. nyco

    :)

  367. Guus

    ah ok

  368. Guus

    nothing for the agenda for me. I neglected to read up the chat logs for the last three meetings (that I missed)

  369. ralphm

    For the record, there was no meeting. Instead I discussed infra with MattJ.

  370. ralphm

    (last week, I mean)

  371. lumi has left

  372. ralphm

    1. Minute taker

  373. Guus

    oh, from trello, I'm missing something

  374. nyco

    I've missed meetings as well, sorry, and did not read minutes

  375. Guus

    The M-Sec project email. Was that resolved?

  376. Guus

    I'll do after-the-fact minutes of this meeting

  377. Seve

    Doesn't look like

  378. kokonoe has left

  379. dos has left

  380. kokonoe has joined

  381. ralphm

    2. Compliance Badges

  382. ralphm

    Where are we on this?

  383. nyco

    we should vote

  384. nyco

    board-only? members?

  385. nyco

    board-only is fast but non-democratic members is longer, but safer meaning collective intelligence

  386. ralphm

    I don't think a members vote is needed.

  387. Guus

    ... Did I sent a call for feedback, as I promised on this?

  388. Guus

    (if so, it didn't get any feedback. If I neglected, shame on me)

  389. nyco

    it's visual design, the more people the better

  390. ralphm

    Guus: you did on May 23

  391. Guus

    I _did_ sent that request, on Thu, 23 May

  392. nyco

    small subset for qualitative feedback large set for quantitative

  393. ralphm

    I haven't seen any feedback

  394. Guus

    we've got no feedback. I'm unsure if asking for a vote would result in any meaningful feedback, tbh.

  395. COM8 has joined

  396. alameyo has left

  397. Guus

    Design shouldn't be a democratic endeavor, I think.

  398. Guus

    Ge0rG - did you happen to have more on this?

  399. dwd has joined

  400. nyco

    design process, agree design decision: the masses decide, one way or another (adoption vs rejection)

  401. jonas’

    I think a poll from the members to get an impression should be done

  402. jonas’

    if I may humbly say so from the floor

  403. jonas’

    the members voted for the XMPP logo (IIRC?), and I think that should also happen for the CS badges

  404. Guus

    not a hill for me to die on.

  405. COM8 has left

  406. ralphm

    I am ok with a poll.

  407. ralphm

    But I wouldn't make a big deal on this.

  408. ralphm

    I.e. we could reiterate the request for feedback. If there is no response, again, we can just choose a design as Board.

  409. nyco

    good

  410. Guus

    Ge0rG suggested requesting for feedback, rather than 'picking one', to improve the existing designs (as a prelude to choosing one) iirc

  411. neshtaxmpp has left

  412. Guus

    but, sure. Who wants to create a poll?

  413. ralphm

    A good suggestion, but it seems no one so far has cared to provide any.

  414. Seve

    So do we choose a design already?

  415. ralphm

    :-) it seems so

  416. Daniel has left

  417. ralphm

    From what I've seen, the proposals in Guus' mail are all work in progress. I have a clear preference for the direction suggested by mray (https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels)

  418. Seve

    Me as well

  419. Guus

    Note that there's a good chance that we've lost his attention span

  420. Guus

    I have no significant preference.

  421. nyco

    the two others follow the de facto standard for badges formats

  422. Guus

    I badly want to avoid us taking the rest of this meeting discussing this though. Can we do this out-of-band?

  423. nyco

    yep

  424. nyco

    feedback request followup, then poll

  425. ralphm

    WFM

  426. ralphm

    Guus: can you send that reminder?

  427. Seve

    +1

  428. Guus

    Can someone else please?

  429. nyco

    I will

  430. ralphm

    Thanks

  431. nyco

    for the poll, which tool?

  432. nyco

    (fast answer or none, so we go to the next agenda item)

  433. ralphm

    not sure. maybe memberbot

  434. ralphm

    3. Fabian Sauter to join SCAM

  435. Guus

    If google forms can include pictures, that might be handy.

  436. ralphm

    from an earlier meeting I remember that we'd ask him for his motivation to join, beyond just wanting to

  437. ralphm

    Seve?

  438. Guus

    I don't recall this, but it seems sensible. Did we relay that request to him?

  439. Daniel has joined

  440. Seve

    I had the task to reach to him

  441. ralphm

    ralphm: Seve can you ask him to expand on what he wants to do on SCAM? Seve: Yes, I will try to reach to him

  442. ralphm

    (from 6-6)

  443. rion has left

  444. rion has joined

  445. Seve

    I didn't send him an email unfortunately, I will do that right after the meeting, my bad.

  446. ralphm

    I moved the item to the left

  447. ralphm

    4. Roadmap page

  448. ralphm

    Also discussed on the 6-6 meeting

  449. Nekit has left

  450. Nekit has joined

  451. ralphm

    I'll send an e-mail to ask Council what they'd want to do with this.

  452. jonas’

    6-6 meeting?

  453. Guus

    Although I'd be happy for Council's feedback, i feel that this is a Board thingy

  454. ralphm

    2019-06-06, as a date

  455. ralphm

    Guus: given that Council is the body regarding our core business, standards development, and the current page lists mostly items concerning those, I think it more than just a Board thingy.

  456. Seve

    We can decide on XSF topics, but I wonder if we can put ourselves some roadmap for XEPs

  457. ralphm

    Seve: and that, too

  458. Seve

    So I guess it depends on what kind of roadmap are we talking about

  459. nyco

    not a XEP-only roadmap please

  460. ralphm

    A goal could be, for example, to get more of our specification to move forward in the process, with a focus on certain (groups of) XEPs.

  461. ralphm

    The original topic is whether we want to link to the Roadmap page, and the question then became two-fold: 1) do we still want a formal roadmap, 2) what should be on it, if so.

  462. Guus

    The XMPP Council is the technical steering group that approves XMPP Extension Protocols. It can have it's own goals, but the XSF roadmap should, in my opinion, be driven by Board - with backing from the community / membership, of which Council is an important part.

  463. Guus

    I think we should want one, but I fear we currently lack momentum to follow through on it.

  464. Guus

    As long as it takes us months to decide on something simple as a badge design, I fear that formalizing a roadmap is a bridge to far.

  465. ralphm

    The point I tried to make, and I think Seve, too, is that we don't, as an organization, *create* standards. We take proposals from the community, and then foster their standardization, weighing them against other similar proposals, and the existing set of specifications.

  466. nyco

    1/ yes, absolutely, we want, they want a roadmap, gives a general idea on our direction, no need to be precise though 2/ we should put non-tech-only content, but also maybe community, business, communication, whatever, I d'ont know yet, knowing that tech is our main thing

  467. Guus

    I'm pressed for time, and this meeting is running over.

  468. nyco

    me too, sorry

  469. ralphm

    Ok, Let's pick this one up next week. Please all think about what, if anything, *concretely* could be on here, but I'm with Guus that I'm not optimistic about us getting anywhere with it.

  470. nyco

    anyway, our currently online roadmap is outdated, I suggest to start from here and revise it

  471. Seve

    We may want to put it offline in the meantime, while a decision is being made.

  472. Guus

    we should prevent this turning into the 'setting priorities' thingy from last year.

  473. ralphm

    5. AOB

  474. Guus

    Vacation is upon us

  475. jonas’

    what is a 6-6 meeting?

  476. ralphm

    jonas’: it is date!

  477. ralphm

    a date

  478. Seve

    Haha

  479. ralphm

    on the calendar

  480. jonas’

    in the past

  481. Guus

    do we need to account for absence?

  482. ralphm

    jonas’: yes, a reference to what was discussed before

  483. jonas’

    I see

  484. jonas’

    nevermind me then

  485. ralphm

    I'm here next week

  486. ralphm

    But this is AOB

  487. jonas’

    (I somehow thought it was board+council, but that doesn’t make sense now because we’re just 5 people each)

  488. Guus

    I ment it as AOB 🙂

  489. ralphm

    oh, well, generally we just keep the calendar going. If we don't have quorum, no meeting.

  490. Guus

    ok

  491. ralphm

    6. Date of Next

  492. ralphm

    +1W

  493. nyco

    ok

  494. ralphm

    7. Close

  495. ralphm

    Thanks all!

  496. ralphm bangs gavel

  497. nyco

    thx all

  498. Seve

    Thank you guys :)

  499. Guus

    Thanks

  500. Nekit has left

  501. Nekit has joined

  502. moparisthebest

    I don't currently run it jonas’ but https://github.com/moparisthebest/xmpp-ircd

  503. moparisthebest

    it "works", no authentication (like nickserv) is the reason I currently don't run it

  504. moparisthebest

    but also before I touched it again I'd rewrite in Rust, so, have at it :)

  505. Andrew Nenakhov has left

  506. Andrew Nenakhov has joined

  507. Daniel has left

  508. pdurbin has joined

  509. Daniel has joined

  510. pdurbin has left

  511. lnj has left

  512. lnj has joined

  513. Daniel has left

  514. j.r has joined

  515. COM8 has joined

  516. j.r has left

  517. Daniel has joined

  518. COM8 has left

  519. COM8 has joined

  520. COM8 has left

  521. COM8 has joined

  522. COM8 has left

  523. COM8 has joined

  524. COM8 has left

  525. j.r has joined

  526. COM8 has joined

  527. COM8 has left

  528. COM8 has joined

  529. COM8 has left

  530. COM8 has joined

  531. COM8 has left

  532. COM8 has joined

  533. COM8 has left

  534. COM8 has joined

  535. COM8 has left

  536. oli

    moparisthebest: do it (rewrite in Rust) ;)

  537. moparisthebest

    it's pretty far down on my list, ETA "years to never" :/

  538. j.r has left

  539. j.r has joined

  540. oli

    wait for MIX and ircv3 ;)

  541. pep.

    And add another few years to the ETA?

  542. rtq3 has left

  543. oli

    never + a few years = never

  544. pep.

    I knew it! (*does the gesture*)

  545. j.r has left

  546. j.r has joined

  547. moparisthebest

    yea so you could say it's got the same ETA as MIX >:)

  548. Zash

    Any Decade Now™

  549. COM8 has joined

  550. waqas has joined

  551. COM8 has left

  552. kokonoe has left

  553. kokonoe has joined

  554. dwd has left

  555. dwd has joined

  556. dwd has left

  557. waqas has left

  558. alameyo has joined

  559. Wojtek has joined

  560. dwd has joined

  561. Wojtek has left

  562. rtq3 has joined

  563. Lance has joined

  564. igoose has left

  565. igoose has joined

  566. goffi has left

  567. pdurbin has joined

  568. Syndace has left

  569. igoose has left

  570. igoose has joined

  571. dwd has left

  572. dwd has joined

  573. pdurbin has left

  574. dwd has left

  575. Douglas Terabyte has joined

  576. dwd has joined

  577. Nekit has left

  578. Nekit has joined

  579. Douglas Terabyte has left

  580. COM8 has joined

  581. COM8 has left

  582. COM8 has joined

  583. Kacper has left

  584. dwd has left

  585. dwd has joined

  586. Kacper has joined

  587. Douglas Terabyte has joined

  588. Kacper has left

  589. dwd has left

  590. COM8 has left

  591. COM8 has joined

  592. COM8 has left

  593. Kacper has joined

  594. COM8 has joined

  595. COM8 has left

  596. dwd has joined

  597. andy has left

  598. COM8 has joined

  599. murabito has left

  600. murabito has joined

  601. Kacper has left

  602. Douglas Terabyte has left

  603. COM8 has left

  604. COM8 has joined

  605. COM8 has left

  606. dwd has left

  607. dwd has joined

  608. Kacper has joined

  609. alameyo has left

  610. alameyo has joined

  611. Tobias has left

  612. dwd has left

  613. Lance has left

  614. Tobias has joined

  615. Lance has joined

  616. dwd has joined

  617. COM8 has joined

  618. COM8 has left

  619. oli has left

  620. andy has joined

  621. oli has joined

  622. sezuan has left

  623. goffi has joined

  624. Damien has joined

  625. sezuan has joined

  626. Damien has left

  627. sezuan has left

  628. Tobias has left

  629. Tobias has joined

  630. sezuan has joined

  631. sezuan has left

  632. sezuan has joined

  633. sezuan has left

  634. sezuan has joined

  635. murabito has left

  636. murabito has joined

  637. lumi has joined

  638. sezuan has left

  639. Nekit has left

  640. Seve

    Guus, thank you for the minutes

  641. Wojtek has joined

  642. Wojtek has left

  643. Damien has joined

  644. Syndace has joined

  645. Guus

    Np

  646. Zash

    Hm, when unblocking a JID per XEP-0191 it says you should send the JID your current presence (assuming they're allowed to see it)

  647. Zash

    However it doesn't say anything about the previously blocked JIDs presence

  648. Zash

    Is it implied that you probably wanna re-probe or somesuch?

  649. Damien has left

  650. Damien has joined

  651. j.r has left

  652. dwd has left

  653. dwd has joined

  654. dwd has left

  655. Damien has left

  656. j.r has joined

  657. dwd has joined

  658. sezuan has joined

  659. sezuan has left

  660. sezuan has joined

  661. sezuan has left

  662. sezuan has joined

  663. goffi has left

  664. Damien has joined

  665. McKael has joined

  666. McKael has left

  667. debacle has left

  668. Damien has left

  669. Damien has joined

  670. kokonoe has left

  671. dwd has left

  672. dwd has joined

  673. kokonoe has joined

  674. dwd has left

  675. Yagiza has left

  676. sezuan has left

  677. sezuan has joined

  678. pdurbin has joined

  679. sezuan has left

  680. sezuan has joined

  681. sezuan has left

  682. debacle has joined

  683. Douglas Terabyte has joined

  684. rtq3 has left

  685. rtq3 has joined

  686. pdurbin has left

  687. Kacper has left

  688. Kacper has joined

  689. Daniel has left

  690. pdurbin has joined

  691. Kacper has left

  692. Kacper has joined

  693. Kacper has left

  694. dwd has joined

  695. Kacper has joined

  696. 404.city has joined

  697. 404.city has left

  698. Nekit has joined

  699. pdurbin has left

  700. lnj has left

  701. pdurbin has joined

  702. Nekit has left

  703. pdurbin has left

  704. igoose has left

  705. igoose has joined

  706. rtq3 has left

  707. rtq3 has joined

  708. rtq3 has left

  709. rtq3 has joined

  710. murabito has left

  711. murabito has joined

  712. kokonoe has left

  713. kokonoe has joined

  714. Lance has left

  715. Douglas Terabyte has left

  716. frainz has left

  717. frainz has joined

  718. Damien has left

  719. Douglas Terabyte has joined

  720. debacle has left

  721. david has left

  722. david has joined

  723. neshtaxmpp has joined

  724. david has left

  725. david has joined

  726. andy has left

  727. Daniel has joined

  728. wurstsalat has left

  729. lovetox has left

  730. pdurbin has joined

  731. neshtaxmpp has left

  732. pdurbin has left

  733. rtq3 has left

  734. winfried has left