XSF logo XSF Discussion - 2019-01-02


  1. Half-Shot has left
  2. jjrh has left
  3. jjrh has left
  4. neshtaxmpp has left
  5. neshtaxmpp has left
  6. Half-Shot has left
  7. nyco has left
  8. UsL has left
  9. UsL has joined
  10. jjrh has left
  11. jjrh has left
  12. Half-Shot has left
  13. jjrh has left
  14. jjrh has left
  15. jjrh has left
  16. jjrh has left
  17. Half-Shot has left
  18. Half-Shot has left
  19. jjrh has left
  20. Half-Shot has left
  21. lskdjf has joined
  22. Half-Shot has left
  23. Half-Shot has left
  24. Half-Shot has joined
  25. Neustradamus has left
  26. Neustradamus has joined
  27. l has left
  28. lovetox has left
  29. ThibG has left
  30. ThibG has joined
  31. Half-Shot has left
  32. l has joined
  33. neshtaxmpp has joined
  34. Half-Shot has joined
  35. Andrew Nenakhov has left
  36. Andrew Nenakhov has joined
  37. lskdjf has joined
  38. Half-Shot has left
  39. 404.city has joined
  40. lnj has left
  41. lnj has joined
  42. lnj has left
  43. lnj has joined
  44. lnj has left
  45. lnj has joined
  46. lnj has left
  47. lnj has joined
  48. lnj has left
  49. lnj has joined
  50. sezuan has left
  51. UsL has left
  52. UsL has joined
  53. lumi has joined
  54. pep. has joined
  55. UsL has left
  56. UsL has joined
  57. oli has joined
  58. Zash has left
  59. alacer has joined
  60. Marc Laporte has joined
  61. Marc Laporte has left
  62. igoose has left
  63. igoose has joined
  64. Marc Laporte has joined
  65. ThibG has left
  66. ThibG has joined
  67. 404.city has left
  68. !xsf_Martin has joined
  69. lnj has left
  70. alacer has left
  71. daniel has joined
  72. alacer has joined
  73. nyco has joined
  74. vinx55 has joined
  75. steven has left
  76. mimi89999 has joined
  77. vinx55 has left
  78. vaulor has joined
  79. steven has joined
  80. alacer has left
  81. alacer has joined
  82. Marc Laporte has left
  83. !xsf_Martin has joined
  84. ralphm has left
  85. l has joined
  86. alacer has left
  87. alacer has joined
  88. genofire has left
  89. oli has joined
  90. Steve Kille has left
  91. !xsf_Martin has joined
  92. alacer has left
  93. Steve Kille has joined
  94. alacer has joined
  95. l has left
  96. l has joined
  97. labdsf has left
  98. alacer has left
  99. labdsf has joined
  100. alacer has joined
  101. Ann has joined
  102. oli has left
  103. oli has joined
  104. igoose has left
  105. igoose has joined
  106. frainz has left
  107. frainz has joined
  108. genofire has left
  109. genofire has joined
  110. mrDoctorWho has left
  111. mightyBroccoli has left
  112. genofire has left
  113. genofire has joined
  114. alacer has left
  115. ThibG has joined
  116. ThibG has joined
  117. l has joined
  118. moparisthebest has left
  119. mightyBroccoli has joined
  120. ThibG has left
  121. ThibG has joined
  122. alacer has joined
  123. Yagiza has joined
  124. Seve has left
  125. vaulor has left
  126. ralphm has left
  127. alacer has left
  128. mightyBroccoli has left
  129. mightyBroccoli has joined
  130. alacer has joined
  131. pep. has left
  132. labdsf has left
  133. 404.city has joined
  134. 404.city has left
  135. tux has left
  136. labdsf has joined
  137. l has joined
  138. valo has joined
  139. valo has joined
  140. !xsf_Martin has left
  141. !xsf_Martin has joined
  142. alacer has left
  143. alacer has joined
  144. lnj has joined
  145. lskdjf has joined
  146. alacer has left
  147. Ann has left
  148. Ann has joined
  149. Ann has left
  150. Ann has joined
  151. oli has joined
  152. oli has joined
  153. daniel has joined
  154. Half-Shot has joined
  155. Zash has left
  156. alacer has joined
  157. goffi has joined
  158. marc_ has joined
  159. !xsf_Martin has left
  160. alacer has left
  161. alacer has joined
  162. vaulor has joined
  163. l has joined
  164. Neustradamus has left
  165. thorsten has left
  166. thorsten has joined
  167. l has left
  168. l has joined
  169. Neustradamus has joined
  170. Neustradamus has left
  171. Neustradamus has joined
  172. alacer has left
  173. alacer has joined
  174. Neustradamus has left
  175. Ge0rG has left
  176. lumi has joined
  177. !xsf_Martin has joined
  178. Neustradamus has joined
  179. Andrew Nenakhov has left
  180. !xsf_Martin has left
  181. ThibG has left
  182. ThibG has joined
  183. frainz has left
  184. frainz has joined
  185. Neustradamus has left
  186. lskdjf has joined
  187. alacer has left
  188. Neustradamus has joined
  189. lovetox has joined
  190. Andrew Nenakhov has joined
  191. Nekit has joined
  192. frainz has left
  193. frainz has joined
  194. mightyBroccoli has left
  195. mightyBroccoli has joined
  196. frainz has left
  197. frainz has joined
  198. igoose has left
  199. igoose has joined
  200. daniel has left
  201. lskdjf has joined
  202. alacer has joined
  203. daniel has joined
  204. ThibG has left
  205. ThibG has joined
  206. frainz has left
  207. frainz has joined
  208. alacer has left
  209. erkanfiles has joined
  210. erkanfiles ralphm: I just finished the minutes for 2018-12-20... Could you check this before I submit? This is my first try...
  211. erkanfiles Or anybody else?
  212. Ge0rG erkanfiles: I can review as well if you wish. You need somebody to forward them to the lists anyway.
  213. Ge0rG (I'm not on board, but on members)
  214. moparisthebest has joined
  215. moparisthebest has left
  216. moparisthebest has joined
  217. Ge0rG > This server could not prove that it is logs.xmpp.org; its security certificate is from xmpp.org *sigh*
  218. waqas has left
  219. waqas has joined
  220. Yagiza has left
  221. moparisthebest has joined
  222. moparisthebest has joined
  223. freddo has joined
  224. mightyBroccoli has left
  225. benpa has joined
  226. benpa has joined
  227. _purple_bot has joined
  228. _purple_bot has joined
  229. Matthew has joined
  230. Matthew has joined
  231. uhoreg has joined
  232. uhoreg has joined
  233. jjrh has left
  234. Ge0rG has left
  235. benpa has joined
  236. uhoreg has joined
  237. _purple_bot has joined
  238. Matthew has joined
  239. lnj has left
  240. Zash has left
  241. benpa has joined
  242. _purple_bot has joined
  243. Matthew has joined
  244. uhoreg has joined
  245. jjrh has left
  246. jjrh has left
  247. mightyBroccoli has joined
  248. jjrh has left
  249. benpa has joined
  250. uhoreg has joined
  251. _purple_bot has joined
  252. Matthew has joined
  253. lukkec has joined
  254. waqas has left
  255. lukkec has left
  256. lukkec has joined
  257. jjrh has left
  258. lukkec has left
  259. lukkec has joined
  260. erkanfiles has joined
  261. lukkec has left
  262. lukkec has joined
  263. lukkec has left
  264. lukkec has joined
  265. lukkec has left
  266. lukkec has joined
  267. lukkec has left
  268. lukkec has joined
  269. lukkec has left
  270. lukkec has joined
  271. Holger has left
  272. lukkec has left
  273. lukkec has joined
  274. lukkec has left
  275. lukkec has joined
  276. moparisthebest has left
  277. moparisthebest has joined
  278. lukkec has left
  279. lukkec has joined
  280. lukkec has left
  281. lukkec has joined
  282. lukkec has left
  283. lukkec has joined
  284. lukkec has left
  285. frainz has left
  286. lukkec has joined
  287. lukkec has left
  288. lukkec has joined
  289. frainz has joined
  290. lukkec has left
  291. lukkec has joined
  292. lukkec has left
  293. lukkec has joined
  294. lukkec has left
  295. lukkec has joined
  296. lukkec has left
  297. lukkec has joined
  298. ralphm has left
  299. lukkec has left
  300. lukkec has joined
  301. lukkec has left
  302. lukkec has joined
  303. redditor has joined
  304. lukkec has left
  305. lukkec has joined
  306. lukkec has left
  307. lukkec has joined
  308. lukkec has left
  309. lukkec has joined
  310. lukkec has left
  311. j.r has joined
  312. Yagiza has joined
  313. krauq has left
  314. krauq has joined
  315. mightyBroccoli has left
  316. jjrh has left
  317. jjrh has left
  318. !xsf_Martin has joined
  319. l has left
  320. mightyBroccoli has joined
  321. pep. has left
  322. lskdjf has left
  323. Seve has joined
  324. jjrh has left
  325. redditor has left
  326. redditor has joined
  327. redditor has left
  328. redditor has joined
  329. winfried has joined
  330. winfried has joined
  331. Ann has left
  332. Ann has joined
  333. j.r has joined
  334. dos has left
  335. UsL has joined
  336. Lance has joined
  337. mightyBroccoli has left
  338. Steve Kille has left
  339. Steve Kille has left
  340. mimi89999 has joined
  341. mrDoctorWho has joined
  342. mightyBroccoli has joined
  343. l has joined
  344. Steve Kille has joined
  345. waqas has joined
  346. l has left
  347. Alex has joined
  348. redditor has left
  349. redditor has joined
  350. ralphm has left
  351. Zash has left
  352. pep. https://wiki.xmpp.org/web/Main_Page somebody added "Quickstart for developers" on the main page, but it points nowhere. There's also "Modern Login Procedure" that points nowhere. Even if that can be a good idea I vote to remove them while they're empty.
  353. j.r has joined
  354. l has joined
  355. mightyBroccoli has left
  356. mightyBroccoli has joined
  357. ta has joined
  358. l has left
  359. redditor has left
  360. redditor has joined
  361. tux has joined
  362. krauq has left
  363. Syndace We had a discussion about OMEMO key cross-signing and without giving any further context it seems like revocation is the biggest problem which needs some smart ideas. If we do it the GPG-way we need some sort of revocation-cert. The problem is where to upload the revocation cert to, because a malicious admin could block uploading those or remove them from PEP/whatever.
  364. Wiktor has left
  365. valo has left
  366. valo has joined
  367. Lance has left
  368. Lance has joined
  369. Lance has left
  370. Lance has joined
  371. erkanfiles has joined
  372. j.r has joined
  373. j.r has joined
  374. Wiktor Syndace, why is cross signing intermixed with revocations? As far as I understand cross signing is for extending trust to new keys. If the device is not used for some time it's "revoked" automatically in current design already. That'd cover common scenarios like device migration.
  375. Syndace What do you mean by "current design"?
  376. Syndace Revocation is for when you loose a device or you know the keys have been compromised.
  377. Wiktor I mean by what Conversations do hehe, if you lose a device then after some time the client will stop encrypting for that decide
  378. Wiktor Device*
  379. Syndace Okay, that does not use cross-signing though ^^
  380. Wiktor Yes but it's already working for "revocations" so no need to invent anything new here
  381. Ann has left
  382. Wiktor Just keep the same rules for cross signed devices, no need for extra revocations
  383. Syndace I'm sorry but those are two completely different things. One is publishing cryptographic signatures to tell others that you trust a certain key and the other is some client-side timeout logic that is not specified or cryptographically backed at all
  384. ta has left
  385. Wiktor I'd keep it lightweight, like in Matrix, the cross signing signature should be created by already trusted device and add trust only once, then the trusted device should be treated like any other.
  386. Wiktor If not you risk reimplemening OpenPGP and that's a lot of stuff.
  387. blackmarket has joined
  388. ta has left
  389. genofire has left
  390. blackmarket has left
  391. Syndace Yes that's the goal. The thing is that revocation cannot be ignored really. You need a mechanism to tell people that a key is not trustworthy any more. Otherwise an attacker could use compromised keys to cross-sign as many malicious devices as he likes to.
  392. ta has left
  393. Wiktor Yep, but distributing revocations is a problem. That's why OpenPGP has keyservers to make it hard to remove revocations.
  394. ta has joined
  395. genofire has joined
  396. Wiktor Actually I had an idea how to use OpenPGP (on Android through OpenKeychain) to distribute trusted devices set. But that's including OpenPGP in the solution...
  397. pep. Wiktor, if you implement a way to say "I trust this device" to others, you will also need a way to say "I don't trust this device anymore", I don't think there's any need for arguing that one is not needed
  398. pep. And indeed that can be easily blocked by the server
  399. Wiktor And all that has already been solved by OpenPGP, I just warn that there is a risk of reimplemening square wheel here
  400. pep. That point is clear. That's not what I was replying to
  401. pep. You talked about Matrix, do you have any insight on how they handle this?
  402. Wiktor OpenPGP also has signature expiry, you can use that to automatically expire signatures and require re signing if the device is used
  403. Wiktor Nope, I'm not involved in Matrix that much, the blog post I read only mentioned cross signing by already trusted devices
  404. pep. Right, I read that one as well
  405. redditor has joined
  406. waqas has left
  407. Yagiza has left
  408. redditor has joined
  409. Ann has left
  410. Ann has left
  411. uhoreg The (work-in-progress) proposal for cross-signing in Matrix is at https://github.com/matrix-org/matrix-doc/pull/1756, which uses a master key for signing device keys, rather than having devices sign each other and trying to navigate an arbitrary trust graph. And rather than revocations, we're just nuking the master key and replacing it with a new one.
  412. uhoreg It does depend on the server being somewhat trustworthy, but I don't think there's much you can do about it.
  413. Syndace Trusting the server is not acceptable for OMEMO I'd say.
  414. uhoreg If you can figure out a way to do it without having to trust the server to distribute things properly, I'd be very interested in seeing it. It would be very desirable to have that property, but I haven't been able to figure it out yet.
  415. Ann has left
  416. pep. Yeah I'm also doubtful, even if that's also a property I would like, in the context of e2ee
  417. redditor has left
  418. redditor has joined
  419. jonas’ has left
  420. j.r has joined
  421. redditor has joined
  422. steven has left
  423. lovetox also omemo is relying on the server already
  424. pep. Yes it is. A server can just refuse publishing keys
  425. lovetox if you remove a device from your devicelist, to broadcast to others that its not in use anymore
  426. lovetox then this could be just not broadcasted, and other contacts will never know that you dont use the device anymore
  427. Syndace It is relying on the server but the only thing the server can do is block OMEMO overall or attempt to MITM.
  428. lovetox no as i just described
  429. Syndace Or that, righr
  430. lovetox it can block "revocation" of devices
  431. jonas’ the only use of which would be to attempt MITM, right?
  432. lovetox you cant MITM omemo
  433. lovetox its simply not possible as of to date
  434. Syndace well if the admin got hands on one of your devices it would make sense for him to block the unpublishing
  435. lovetox but you can steal a device
  436. Syndace why is it not
  437. lovetox and then block that this device is revoked
  438. lovetox but thats not MITM
  439. pep. lovetox, you can mitm? and it can easily _not_ be detected, (who even reads the list of fingerprints)
  440. pep. Ah hmm
  441. pep. Not MITM
  442. pep. Add yourself in the device list
  443. jonas’ yeah, you’re not in the middle, but ... I’d still call this mitm
  444. lovetox sorry if you dont verify the fingerprint, then its also not a MITM attack, its a I hope this user doesnt know what he does attack
  445. jonas’ the effects (can read and inject(?) messages) and the mitigations (validate your bloody fingerprints) are the same
  446. Ann has left
  447. pep. jonas’, inject yes, the original account doesn't even have to know
  448. pep. If OMEMO is based on the fact that the server is not trusted, this is pretty much a fail
  449. lovetox pep., i cant agree with you on that
  450. lovetox you seem to think you can just add a device and then everyone is starting to encrypt all his messages to that
  451. krauq has joined
  452. pep. Because it's not true?
  453. lovetox this is simply not possible if you configure your client correctly
  454. lovetox you cant with Gajim
  455. pep. Right, you have a big assumption right there
  456. lovetox there will be a popup that tells you, NEW DEVICE do you want to trust?
  457. lovetox otherwise it will never encrypt to that device
  458. lovetox there is no attack as a malicious server, that does not depend on the user actively ignoring to verify fingerprints
  459. jonas’ lovetox, and the average user will just accept
  460. lovetox but thats true for every encryption
  461. pep. Yes
  462. lovetox this has nothing to do with omemo
  463. pep. Well, yes and no. It has to do how it's designed, and what type of users it's targetting
  464. pep. People come to us saying "OMEMO is the #1 feature I want. I don't consider a client otherwise" and they don't understand what it means
  465. lovetox I could easily write a client that encrypts only to QR code scanned devices
  466. lovetox then every device is physically verified
  467. lovetox this is a client UI decision, and is not a fail in the protocol
  468. pep. True, you could. I doubt you'd manage to market that
  469. lovetox yeah of course, lets make compromises, because the thread model is not NSA prove
  470. lovetox the thread model is, lets encrypt 99% of my data in a way that 99% of people cant decrypt it
  471. lovetox *profe
  472. pep. proof :)
  473. lovetox *proof
  474. lovetox damn it
  475. lovetox didnt write that for a long time, and it seemd wrong :D
  476. j.r has joined
  477. lovetox no im all for looking into this stuff, but signal protocol or whatever you want to call it, is pretty pretty good
  478. lovetox there is really not much left to make better
  479. Ge0rG > lets encrypt 99% of my data in a way that 99% of people cant decrypt it I don't want 99% of people to decrypt my data! Only a selected subset of a few persons!
  480. Ge0rG the challenge is to build a usable client around the signal protocol.
  481. Ge0rG actually, no. The challenge is to build a usable client around any encryption primitive.
  482. lovetox i agree thats the challenge
  483. Half-Shot has left
  484. Ge0rG I think that OpenPGP has better UX than OMEMO, and Matrix seems to agree. A per-account master key that is the root of all trust for a user is so much more transparent and usable than N device keys on your side and M device keys on each of your contact's side with NxM trust relationships
  485. Ge0rG But what do I know.
  486. lovetox and in my opinion what we have now, specially in Gajim there is lots of room for improvement before i go and criticise the protocol
  487. Ge0rG if the protocol did it right, you wouldn't have a forest of possible fuckups to solve in your client.
  488. lovetox Ge0rG, i also wrote a already usable openpgp plugin for the current Gajim version, works fine, i didnt impl the secret key transfer yet
  489. lovetox and you can also make openpgp hard to use
  490. steven has left
  491. pep. lovetox, I just tested with conversations and dino, none tell me I've added a new device
  492. Ge0rG But we only ever specify the wire format, no need to tell developers how to solve the really complicated UX problems.
  493. pep. So I guess that's already a nice set of users not checking
  494. lovetox pep., because blind trust is activated in C by default maybe?
  495. Ge0rG Except that for encryption, a UX fail might kill people.
  496. pep. lovetox, of course it is
  497. pep. That's the whole point of Conversations
  498. lovetox to actually have conversations :D
  499. lovetox not care about encryption
  500. pep. I disagree here
  501. lovetox i agree with that to be honest, lets concentrate less about that crypto mania and more about usable clients
  502. Ge0rG Let's not implement OMEMO.
  503. pep. mod_omemo_mitm when
  504. pep. Just to prove a point
  505. Ge0rG If you are a political dissident, don't use xmpp. It will get you killed.
  506. waqas has joined
  507. Ge0rG Also there is no strong binding between the JID and the keys, so OMEMO ends up being an encryption overlay with opaque rules (superset of device IDs of all the participant JIDs) on top of a message routing overlay with opaque rules on top of a federated client - server - server - client overlay on top of TCP IP
  508. ta Ge0rG: just out of couriosity, what's your recommendation for endangered persons?
  509. Ge0rG ta: depends on who's after you. NSA - don't use Smartphones. Russians - don't use Telegram. Other countries - use Apple devices and Signal with a burner number from an American VoIP service
  510. sezuan has left
  511. mimi89999 has left
  512. Ge0rG ta: I'm not an endangered person, so I didn't do thorough research.
  513. Half-Shot has joined
  514. vaulor has joined
  515. pep. Tbh I understand the "privacy by default" bits and I agree with that. I would want to reach a level where people still have some margin to do their research when they suspect they're being targeted. Atm it's probably to late when you reach this conclusion
  516. ta Mw neither, but i am interested in that topic. To secure your privacy yoi almost have to act like a "wanted" person.
  517. ta I am aware that XMPP is not ideal for that matter either.
  518. pep. I don't think any solution out there is tbh, you can use bits and pieces of some solutions, but the most effective one is certainly to act as a commoner
  519. ta And configuring mobile devices to leak as little information as possible is a fight against windmills.
  520. mightyBroccoli has left
  521. lorddavidiii has joined
  522. ta I can not act like most commoners, i don't want to use closed Software (dont get me started on hardware, its a pity). So i always stand out of the masses. That's why i like to encrypt stuff. Since i would stand out my bitstreams sourroubding me shall not be plaintext. Like i dont run around with Information about me printed on my clothes.
  523. Tobias has left
  524. Tobias has joined
  525. ta Some real p2p solution routed through some onion protocol, verified only in person and used on fully encrypted devices with plausible deniabillity is probably the safest way to not leak content of your Conversation, but will be obvious as hell to agencies.
  526. lorddavidiii has left
  527. lorddavidiii has joined
  528. ta has left
  529. tux has left
  530. lorddavidiii has left
  531. mightyBroccoli has joined
  532. jjrh has left
  533. jjrh has left
  534. oli so xmpp was a great idea some time ago, but post snowden...
  535. j.r has joined
  536. pep. Because pre-Snowden wasn't as bad?
  537. oli for irc like groups use matrix. for one to one use something p2p
  538. pep. I'd be interested to know if matrix actually helps here, or if it's more or less the same issues and you have to trust the server somewhat
  539. pep. hint: I don't think it changes much
  540. ta Depends on your needs
  541. Half-Shot has left
  542. pep. We already specified the need in the discussion above. "You don't trust your server"
  543. lorddavidiii has joined
  544. Guus has left
  545. redditor has left
  546. l has joined
  547. l has joined
  548. j.r has joined
  549. lorddavidiii has left
  550. erkanfiles has joined
  551. rion has joined
  552. lorddavidiii has joined
  553. rion Hi. I'm looking at "6.3 Stream Feature" of caps xep. It's nice. But is there something similar for services list (disco#items) and their versions? I mean I'd like to cache not just jabber.ru but conference.jabber.ru, upload.jabber.ru and other services of my server.
  554. lovetox but how do you get the info about the version of the disco items?
  555. lovetox with normal contacts, we exchange presence and we have to do this anyway so we add the version there and save a query
  556. Alex has left
  557. lovetox but you exchange nothing with a MUC or component where you could add the version and save the query
  558. lovetox the first every contact is the disco query, so you get to know what that thing is in the first place
  559. l has joined
  560. rion lovetox: no idea how to do this properly. for example if caps computation of jabber.ru would also include conference.jabber.ru that would be enough for me.
  561. lovetox to answer your question, no we dont have something like that for server components
  562. rion btw about muc. ejabberd already can compute caps for it and send them early on join.
  563. lovetox thats too late
  564. lovetox you have to know if a jid is a muc before you join
  565. rion well yes. but it's better than nothing
  566. rion is there a place where I can write my wishes for xep improvements?
  567. lovetox hm its only useful if you dont use MAM
  568. lovetox yes the standards mailing list
  569. lovetox standards@xmpp.org
  570. lovetox oh rion i spoke too soon
  571. lovetox there is an experimental xep who does what you want i think
  572. lovetox at least in part
  573. lovetox https://xmpp.org/extensions/xep-0390.html#usecases-stream-feature
  574. rion 390?
  575. lovetox thats would be also the place to comment for improvements because its experimental
  576. lovetox 115 will never change
  577. lovetox also for the MUC case there is another problem
  578. lovetox the MUC component has caps but they are not that useful
  579. lovetox because every MUC jid itself can have different caps
  580. rion interesting
  581. lovetox yeah but also here again, server caps yeah nice
  582. lovetox but what you even more need are your account caps
  583. waqas has left
  584. lorddavidiii has left
  585. lorddavidiii has joined
  586. lorddavidiii has left
  587. l has left
  588. Ann has left
  589. thorsten has left
  590. jjrh has left
  591. redditor has joined
  592. !xsf_Martin has joined
  593. redditor has left
  594. redditor has joined
  595. !xsf_Martin has joined
  596. lskdjf has joined
  597. Ann has left
  598. Ann has left
  599. yomane has joined
  600. yomane has left
  601. yomane has joined
  602. yomane has left
  603. yomane has joined
  604. moparisthebest has joined
  605. rion well I just sent the email about xep-0390 updates. I hope it's not lost since I don't have any notifications about its destiny :)
  606. lovetox yeah takes some minutes until it shows up
  607. l has joined
  608. lovetox you registered on the list though?
  609. rion nope..
  610. yomane has left
  611. lovetox em yeah i maybe should have mentioned that ^^^^
  612. yomane has joined
  613. lovetox dont know if it allows to post for unregistered users
  614. lovetox https://mail.jabber.org/mailman/listinfo/standards
  615. rion should I send "register" or something ?
  616. rion ok
  617. lovetox hm rion no mom
  618. lovetox seems you dont need to register
  619. lovetox the registration is for subscribing
  620. yomane has left
  621. lovetox here you can look if it is posted
  622. lovetox https://mail.jabber.org/pipermail/standards/
  623. yomane has joined
  624. lovetox ah damn rion
  625. lovetox it says it
  626. lovetox Note: To cut down on spam, you must be subscribed to this list in order to post!
  627. yomane has left
  628. yomane has joined
  629. rion I see. I'll resend :)
  630. rion just subscribed
  631. yomane has left
  632. yomane has joined
  633. yomane has left
  634. yomane has joined
  635. yomane has left
  636. yomane has joined
  637. jjrh has left
  638. rion it's there now
  639. l has joined
  640. lovetox gratz on your first post :D
  641. rion =))
  642. thorsten has joined
  643. ThibG has left
  644. ThibG has joined
  645. tux has left
  646. lnj has left
  647. ralphm has left
  648. ralphm has joined
  649. Half-Shot has joined
  650. rion has left
  651. vanitasvitae has left
  652. Half-Shot_ has joined
  653. Half-Shot_ has left
  654. !xsf_Martin has left