jdev - 2022-08-14


  1. thomaslewis has left
  2. SouL has left
  3. Ingolf has joined
  4. eu has left
  5. eu has joined
  6. pulkomandy has left
  7. pulkomandy has joined
  8. Kev has joined
  9. Kev has left
  10. _root has left
  11. _root has joined
  12. inky has left
  13. FireFly has left
  14. xnamed has left
  15. TheCoffeMaker has left
  16. TheCoffeMaker has joined
  17. TheCoffeMaker has left
  18. TheCoffeMaker has joined
  19. thomaslewis has joined
  20. Kev has joined
  21. thomaslewis has left
  22. thomaslewis has joined
  23. thomaslewis has left
  24. TheCoffeMaker has left
  25. TheCoffeMaker has joined
  26. Mjolnir Archon has left
  27. Kev has left
  28. TheCoffeMaker has left
  29. marc0s has left
  30. marc0s has joined
  31. TheCoffeMaker has joined
  32. TheCoffeMaker has left
  33. TheCoffeMaker has joined
  34. FXTIA has left
  35. thomaslewis has joined
  36. thomaslewis has left
  37. Matrix Traveler (bot) has left
  38. homebeach has left
  39. homebeach has joined
  40. Matrix Traveler (bot) has joined
  41. FXTIA has joined
  42. Kev has joined
  43. FXTIA has left
  44. FXTIA has joined
  45. Kev has left
  46. antranigv has left
  47. FXTIA has left
  48. marc0s has left
  49. marc0s has joined
  50. FXTIA has joined
  51. hearty has left
  52. hearty has joined
  53. marc0s has left
  54. marc0s has joined
  55. Kev has joined
  56. jgart has left
  57. spiral has left
  58. spiral has joined
  59. selurvedu has left
  60. paul has left
  61. SouL has joined
  62. thomaslewis has joined
  63. thomaslewis has left
  64. marc0s has left
  65. marc0s has joined
  66. spectrum has joined
  67. al has joined
  68. paul has joined
  69. hearty has left
  70. hearty has joined
  71. Kev has left
  72. e-snail has left
  73. marc0s has left
  74. marc0s has joined
  75. emus has left
  76. Kev has joined
  77. Schimon has joined
  78. Kev has left
  79. mirux has joined
  80. al has left
  81. r4v3r23 has joined
  82. thomaslewis has joined
  83. Schimon has left
  84. Schimon has joined
  85. thomaslewis has left
  86. mirux has left
  87. Link Mauve adx, here is my recommendation: https://docs.modernxmpp.org/client/groupchat/#bookmarks
  88. mirux has joined
  89. wurstsalat has left
  90. antranigv has joined
  91. debacle has joined
  92. Kev has joined
  93. antranigv has left
  94. Mario Sabatino has joined
  95. r4v3r23 MattJ: would you want uncencrypted messages sent to you on signal?
  96. spiral has left
  97. r4v3r23 or any other encrypted messaging app?
  98. Link Mauve r4v3r23, would you want to be unable to have this present discussion? :)
  99. Kev has left
  100. wurstsalat has joined
  101. spiral has joined
  102. MattJ r4v3r23: it's not about what is sent to you - you can't control what people send you. It's about what to do after you receive something. There is no security gained by ignoring.
  103. MattJ r4v3r23: even Signal does this - their Android app at least supports receiving unencrypted SMS messages. They don't ignore them, and they even let you reply unencrypted.
  104. r4v3r23 MattJ: OK so imagine signal wasn't also an SMS app
  105. Matrix Traveler (bot) has left
  106. homebeach has left
  107. homebeach has joined
  108. Matrix Traveler (bot) has joined
  109. MattJ So, imagine that the basis of your argument existed 🙂
  110. MattJ The fact is, it's often helpful to be able to communicate with unencrypted/legacy users. It's how you could lead them to upgrade, for example.
  111. MattJ That's undoubtedly why Signal does it. Most people don't have Signal, so by supporting SMS they allow people to seamlessly upgrade when both parties support it.
  112. MSavoritias (fae,ve) has joined
  113. Kev has joined
  114. jubalh has joined
  115. FireFly has joined
  116. Stefan has joined
  117. Kev has left
  118. rom1dep has left
  119. rom1dep has joined
  120. xnamed has joined
  121. FireFly has left
  122. marc has joined
  123. Kev has joined
  124. xecks has joined
  125. spiral has left
  126. spiral has joined
  127. adx has joined
  128. Kev has left
  129. jgart has joined
  130. xnamed has left
  131. xnamed has joined
  132. Alex has left
  133. Alex has joined
  134. emus has joined
  135. FireFly has joined
  136. inky has joined
  137. r4v3r23 has left
  138. r4v3r23 has joined
  139. Kev has joined
  140. spiral has left
  141. spiral has joined
  142. serge90 has joined
  143. Dele Olajide has joined
  144. Kev has left
  145. antranigv has joined
  146. Laura has left
  147. r4v3r23 has left
  148. Mjolnir Archon has joined
  149. lovetox2 has joined
  150. lovetox2 has left
  151. lovetox2 has joined
  152. antranigv has left
  153. r4v3r23 has joined
  154. lovetox2 has left
  155. lovetox2 has joined
  156. Laura has joined
  157. lovetox2 has left
  158. Maranda has joined
  159. PapaTutuWawa has joined
  160. adx has left
  161. spiral has left
  162. r4v3r23 has left
  163. r4v3r23 has joined
  164. r4v3r23 MattJ: that's not my question, and you're not going to convince me
  165. r4v3r23 I wanted to know if an OMEMO based encrypted messenger was possible
  166. spiral has joined
  167. Kev has joined
  168. xnamed has left
  169. Mx2 has left
  170. Mx2 has joined
  171. mirux has left
  172. mirux has joined
  173. iink has left
  174. Kev has left
  175. xnamed has joined
  176. mirux has left
  177. mirux has joined
  178. kujiu has left
  179. Mx2 There has come a new app, those conversation forks are dead end
  180. Mx2 Still many common features aren't important enough it seema
  181. larma has joined
  182. jubalh has left
  183. jubalh has joined
  184. serge90 has left
  185. Alex has left
  186. mh has left
  187. Alex has joined
  188. nav has joined
  189. MattJ r4v3r23: Conversations already marks unencrypted messages with a strong red background. It would probably be no more than a few lines of code to hide those messages completely.
  190. MattJ It just has no advantage and nobody wants that
  191. mh has joined
  192. Kev has joined
  193. Kev has left
  194. kujiu has joined
  195. antranigv has joined
  196. Mx2 has left
  197. Mx2 has joined
  198. jubalh has left
  199. Laura has left
  200. Laura has joined
  201. mh has left
  202. antranigv has left
  203. nav r4v3r23: it might be a more productive use of your time if you stop to think about what other people are telling you rather than try to convince them that you have a good, practical and feasible idea. But to summarise the answer already given to your specific question, yes an end to end encrypted messaging application is possible (why specifically OMEMO though?) if you have very tight control over every aspect of the system and its environment. What you are presenting smells strongly of an XY problem though.
  204. mirux has left
  205. mirux has joined
  206. lovetox2 has joined
  207. lovetox2 has left
  208. lovetox2 has joined
  209. lovetox2 has left
  210. FireFly has left
  211. adx has joined
  212. SouL has left
  213. SouL has joined
  214. mirux has left
  215. mirux has joined
  216. pulkomandy has left
  217. pulkomandy has joined
  218. iink has joined
  219. Kev has joined
  220. Sam has joined
  221. lovetox2 has joined
  222. Sam So I was asking about chardata the other day and apparently was wrong that it wasn't allowed inside the top level of stanzas. Eg. <iq>\n\t<foo/>\n</iq> is acceptable. However, if that's allowed, wouldn't <iq>somemixedcontent<foo/></iq> also be allowed? That seems more of a problem
  223. lovetox2 has left
  224. lovetox2 has joined
  225. iink has left
  226. lovetox2 has left
  227. lovetox2 has joined
  228. lovetox2 has left
  229. jonas’ how was the conclusion that <iq>\n\t<foo/>\n</iq> is acceptable reached?
  230. lovetox2 has joined
  231. lovetox2 jonas’, nobody could cite a document that says otherwise
  232. jonas’ for which definition of "acceptable"?
  233. lovetox2 usage in xml streams
  234. jonas’ in xml streams, or in xmpp xml streams?
  235. lovetox2 xmpp
  236. Kev has left
  237. lovetox2 its obvious that this is valid xml
  238. lovetox2 the question is if xmpp has something that forbids it
  239. jonas’ well
  240. jonas’ you can at least not rely on support
  241. jonas’ for IQ stanzas, in particular, RFC 6120 describes exactly what's in an IQ stanza, and anything beyond that is not necessarily supported by all entities
  242. jonas’ https://www.rfc-editor.org/rfc/rfc6120#section-8.2.3
  243. jonas’ the enumeration on page 106
  244. jonas’ the enumeration on page 106--107
  245. lovetox2 that interpretation seems to be a stretch
  246. jonas’ why?
  247. lovetox2 the whole document is one level to high
  248. xnamed has left
  249. marc0s has left
  250. marc0s has joined
  251. jonas’ (replying with bad-request would be completely ok in such a case)
  252. antranigv has joined
  253. Sam That seems more reasonable to me too, but I was told multiple clients send formatted XML in the wild
  254. lovetox2 you are searching in a IQ definition for rules whats allowed in xml streams
  255. lovetox2 thats the stretch
  256. techmetx11 has left
  257. jonas’ Sam, ah, mixed content and "ignorable whitespace" are two different beast
  258. jonas’ Sam, ah, mixed content and "ignorable whitespace" are two different beasts
  259. jonas’ lovetox2, well, the rules don't need to be the same for <message/> etc.
  260. Sam No as far as XML is concerned
  261. jonas’ lovetox2, case in point: all the SASL nonzas
  262. lovetox2 But Sam is interested in the general case
  263. lovetox2 not for one particular stanza
  264. lovetox2 that maybe not clear from his example
  265. jonas’ in the general case you need to support everything
  266. jonas’ because, as I said, SASL.
  267. antranigv has left
  268. jonas’ (and XMPP extensibility)
  269. Sam So where does it say "chardata that is just whitespace is okay, anything else bad"? Seems like a major oversight if it's not
  270. Sam Except for sasl and starttls which ban it just in those places, of course
  271. Zash I tried checking the XML specification but can't for the life of me navigate to it on w3.org
  272. jonas’ Zash, https://www.w3.org/TR/REC-xml/#sec-white-space
  273. jonas’ I have bookmarks for those :-)
  274. Zash Thanks
  275. jonas’ #sec-white-space does not say that whitespace is ignorable on the XML layer, it needs to be defined by the application
  276. xnamed has joined
  277. Laura has left
  278. iink has joined
  279. Sam oh, so it is different. Now I have no idea what to do. I'll elide the rant about how there's apparently a magical attribute that nobody knows about or supports because XML can't decide if it's a document language or a data serialization format and is therefore bad at both.
  280. r4v3r23 nav: I was just curious of building a messenger with those properties was possible
  281. lovetox2 has left
  282. Sam I guess this really does mean that space should be passed through and other chardata should result in an error though? I really can't tell
  283. jonas’ Sam, everything should be passed through
  284. r4v3r23 instead I got comments of why enforced E2EE is stupid
  285. Sam jonas’: so if someone sends <iq>foo<bar/></iq> what does that even mean? IQs are only supposed to have one child, does this violate that rule?
  286. Sam Is it different for message/presence since they can have multiple children?
  287. jonas’ Sam, that violates the *schema*
  288. jonas’ which is different from what the XML layer does
  289. jonas’ (IQs can also have two children, mind, if one of them is an error)
  290. Sam Does it? I can't tell that it's banned anywhere according to this
  291. jonas’ (IQs can also have two children, mind, if exactly one of them is an error)
  292. Zash (or zero children, for type=result)
  293. Sam Sure, doesn't matter though, the question is still valid. I guess the answer is to go figure out what other things are doing because this is underspecified? I really have no idea.
  294. jonas’ goes to check how aioxmpp handles that
  295. jonas’ ah, drops unexpected character data by default
  296. Zash Prosody only cares about child tags
  297. jonas’ (everywhere)
  298. jonas’ in the true extensibility spirit of XMPP (ignoring unexpected/unknown stuff)
  299. mirux has left
  300. mirux has joined
  301. Sam I guess that's fine; feels weird to allow sending it in the first place, but I can't think how it could be abused
  302. pulkomandy has left
  303. Kev has joined
  304. Laura has joined
  305. jubalh has joined
  306. Sam I guess this is fine; no idea really 🤷 https://codeberg.org/mellium/xmpp/pulls/324
  307. Laura has left
  308. Alex has left
  309. Alex has joined
  310. PapaTutuWawa has left
  311. Kev has left
  312. techmetx11 has joined
  313. inky has left
  314. nik has joined
  315. Laura has joined
  316. PapaTutuWawa has joined
  317. Laura has left
  318. pulkomandy has joined
  319. nik has left
  320. iink has left
  321. raghavgururajan has left
  322. iink has joined
  323. iink has left
  324. xnamed has left
  325. MSavoritias (fae,ve) has left
  326. nik has joined
  327. iink has joined
  328. debacle has left
  329. raghavgururajan has joined
  330. Laura has joined
  331. lovetox2 has joined
  332. lovetox2 has left
  333. MSavoritias (fae,ve) has joined
  334. al has joined
  335. raghavgururajan has left
  336. Mx2 has left
  337. kikuchiyo has left
  338. nav r4v3r23: Yes it is possible. See Whatsapp for instance.
  339. nav As for the XMPP network, it might happen that one day some form of support for end to end encryption will be required (probably not OMEMO, given its unclear legal status), in the same form that RFC7590 already mandates support for TLS. It still doesn't mean that people *have* to use it. See also HTTP vs HTTPS.
  340. r4v3r23 has left
  341. r4v3r23 has joined
  342. jubalh has left
  343. Mx2 has joined
  344. techmetx11 nav: >unclear legal status
  345. techmetx11 elaborate
  346. techmetx11 please
  347. Kev has joined
  348. kikuchiyo has joined
  349. al has left
  350. xnamed has joined
  351. Kev has left
  352. lovetox2 has joined
  353. lovetox2 has left
  354. Sam has left
  355. nik has left
  356. xnamed has left
  357. jubalh has joined
  358. nav techmetx11: https://nextleap.eu/deliverables/deliverables-period1.zip See D3.3 & D3.6, for instance
  359. Sam has joined
  360. nav For some reason 3.6 is not in the zip. Here's an online copy: https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c208ad8b&appId=PPGMS
  361. nav Musiani goes in some more detail in this paper: https://hal.inria.fr/hal-01426845/document
  362. nik has joined
  363. nav The long and the short of it is that OMEMO (or rather the protocol called Axolotl) is not a standard, and apparently quite intentionally so, as that allows the IP rights holder to exercise control over it, and monetise it.
  364. jonas’ is that still an issue for omemo 0.8?
  365. nav Normally you would use patents for that kind of thing
  366. nav jonas’: I don't know. Hence the "unclear" qualifier.☺
  367. nav But I wouldn't want to be the next Wire.
  368. inky has joined
  369. Sam I don't think any of that is true; the original axolotl spec was published using creative commons IIRC, the implementation everyone relied on was GPL, and newer OMEMO versions aren't based on it anyways and are an XSF spec. That all seems pretty clear, unless I'm wrong about that?
  370. Sam (I did not download the zip file, so maybe it tells me why I'm wrong, but that seems unsafe so apologies if it's in whatever that is somewhere)
  371. MSavoritias (fae,ve) Yeah that seems like a baseless fear
  372. Dele Olajide has left
  373. lovetox2 has joined
  374. zawarudo has joined
  375. lovetox2 if a muc service does that merge multiple presences into one when connecting with different devices
  376. lovetox2 is there a way to break this?
  377. lovetox2 like can i break out of that as a device intentionally, maybe by changing nick or connecting to the muc in a certain way
  378. jonas’ I don't fully undesrtand what you mean by break yet
  379. jonas’ what's the goal?
  380. lovetox2 to join a muc with 2 different resources
  381. nav Sam: > newer OMEMO versions aren't based on it anyways I just checked https://xmpp.org/extensions/xep-0384.htm and it refers me straight onto https://xmpp.org/extensions/xep-0384.html#nt-idm45811904665168 for the actual implementation.
  382. lovetox2 and not get merged to one
  383. jonas’ lovetox2, then you need two different nicknames
  384. jonas’ (or two different accounts, then it'll complain to you about a nickname conflict if you attempt)
  385. lovetox2 i have devica A and device B of the same account
  386. lovetox2 i want to join a muc, with two different resources
  387. jonas’ then use two different nicknames
  388. lovetox2 or nicknames
  389. raghavgururajan has joined
  390. lovetox2 ok so the MUC merging depends on the user joining with the same nickname across devices
  391. lovetox2 ?
  392. jonas’ yes
  393. lovetox2 what if i change the nick from one device while im in the MUC
  394. lovetox2 will the MUC somehow tell my other device that my nick has changed?
  395. jonas’ it depends on the implementation
  396. Sam My mistake. Doesn't matter though, that specifically says "This document is hereby placed in the public domain."
  397. lovetox2 ok so i need to test it
  398. jonas’ in theory, an implementation has the folowing choices: - Reject the change (I think that's what old prosody did) - "split" the nickname: the changing device will see a successful nickname change *and* a join for the old nickname (for the other device), everyone else will see a join of the new nickname. - Force-change the nickname of the other device
  399. jonas’ in theory, an implementation has the folowing choices: - Reject the change (I think that's what old prosody did) - "split" the nickname: the changing device will see a successful nickname change *and* a join for the old nickname (for the other device), everyone else will see a join of the new nickname. - Force-change the nickname of the other device(s) alongside the one initiating the nick change
  400. jonas’ I think current prosody does the "split", because client support for the forced nickname change was questionable
  401. lovetox2 ahhh great info thanks
  402. lovetox2 thats what im seeing
  403. lovetox2 and i thought its a Gajim bug
  404. lovetox2 the splitting thing
  405. jubalh has left
  406. zawarudo has left
  407. zawarudo has joined
  408. zawarudo has left
  409. lovetox2 has left
  410. lovetox2 has joined
  411. Zash I'm not actually sure if you can do server-initated force-rename of someone
  412. jonas’ sending presence with code 110 and code 210 *may* work
  413. jonas’ (which is how servers can override your nickname choices, and I suppose client implementations need code for handling that anyway and as most MUC operations are asynchronous (presence instead of IQ, so not tracked), I *suppose* that it'd just work)
  414. Kev has joined
  415. Kev has left
  416. Zash While that may carry the appropriate semantics, I don't remember seeing any text about that case and when some clients had trouble with the server rewriting their nickname on join...
  417. Zash Worth testing I suppose
  418. jubalh has joined
  419. Mx2 has left
  420. Sam has left
  421. Sam has joined
  422. lovetox Gajim handles that
  423. lovetox the Status Code is in the XEP and it says what its for, service changed your nickname
  424. nav Sam: the papers I linked to explain why the (non-)specification and one implementation being publicly available don't matter, as Wire found out much to their disadvantage (incidentally, please note that the licensing status of the document in which it's written does not convey any rights over the specification itself). Have the XSF commissioned a legal review? If not, the Nextleap project (https://cis.cnrs.fr/nextleap/) is as close as it gets that I'm aware of.
  425. Sam nav: What happened to wire? Can you summarize the documents? As far as I know there is no patent on the algorithm and the spec and implementation are licensed in an open way, so this all just seems wrong.
  426. lovetox i never heard that there are patents, i doubt that highly
  427. jubalh has left
  428. MattJ No, their defence is based on copyright and trademark, not patents
  429. nav Sam: I just linked to all of that, why not get it from the horse's mouth? And the summary is: "legal status unclear".
  430. nav MattJ: Exactly.
  431. Sam I'm not downloading a random zip file and I don't really want to try and read a long PDF on my phone.
  432. Sam MattJ: Copyright and trademark of what? Who's defense? Sorry, didn't understand that
  433. nav Sam: that's fine, but then please consider not jumping to conclusions.
  434. Zash The thing where they put their trademark into a protocol constant?
  435. Mx2 has joined
  436. Sam I just asked you to summarize, I didn't jump to any conclusions
  437. MattJ Sam: copyright of their implementations and trademark of "Signal" and "Signal protocol"
  438. nav My apologies, I then misunderstood the meaning of "so this all just seems wrong."
  439. MattJ So don't violate the GPL and don't advertise your implementation as using the Signal protocol
  440. Sam The implementations are copyright but licensed GPL, so that seems fine as long as you use that license or write your own impl
  441. larma has left
  442. Sam You beat me to the next thing :) what Matt just said
  443. nav No.
  444. MattJ There was an issue that even if you create your own implementation from scratch, there are some constants (some say intentionally) embedded in the protocol that mention "Signal"
  445. Laura has left
  446. nav That's what got Wire in hot water.
  447. MattJ But this is not relevant in the latest version of OMEMO
  448. Sam There us zero chance you are violating a trademark if you gave a constant that says SignalProtocolv1 or whatever somewhere. Zero.
  449. Sam But as you said, doesn't matter anyways.
  450. MattJ Sam: they say different, and given that they make $$$ from licensing the protocol, they'll defend it too
  451. Sam nav: hot water how? You still haven't explained what happened to wire?
  452. Sam MattJ: oh, fair enough, if they're actually suing people over it it doesn't matter if it's technically okay or not, you still don't want to have to defend yourself
  453. debacle has joined
  454. Sam Do either of you have a link to an instance of them doing this? Searching "signal lawsuit" and the like is turning up nothing
  455. Sam Either way, none of this makes recent omemo legally gray area since that constant isn't used.
  456. nav Sam: I appreciate that you may not have access to a proper computer right not. If this is of interest to you, may I suggest coming back to it later when you do? You are jumping to pretty unwarranted conclusions.
  457. MSavoritias (fae,ve) has left
  458. Zash So, how's your MLS implementations coming along?
  459. Sam What conclusions? Just explain what you're talking about so I don't have to read a ton of papers
  460. Laura has joined
  461. nav > What conclusions? > none of this makes recent omemo legally gray area > doesn't matter anyways. > There us zero chance you are violating a trademark > so that seems fine …etc.
  462. nav It's your choice not to inform yourself, but please do not disinform others.
  463. nav As it stands now, I would be very wary of implementing XEP-0384 in anything that's not GPL licenced.
  464. mirux has left
  465. mirux has joined
  466. nav Note that this also includes MIT + BSD licences as well as closed source.
  467. nav Which makes that XEP non licence neutral.
  468. nav Which is not exactly the best state of affairs for an open protocol.
  469. MattJ Sam: there's not too much public about it, and I'm likewise not at my computer right now. But here's an overview: https://wireapp.medium.com/axolotl-and-proteus-788519b186a7
  470. jubalh has joined
  471. MattJ I might be able to find some other references later
  472. MattJ I see no problem with modern OMEMO
  473. raghavgururajan has left
  474. nav MattJ: How so?
  475. MattJ Because what would their argument be?
  476. Zash "See you in court for no reason!!!"
  477. lovetox nav, all this has been discussed and considererd on list when the XEP was made
  478. lovetox the opinion of the community is that is totally fine to implement under any license
  479. lovetox its not enoguth to say "hey maybe look at some links, maybe things are different"
  480. MattJ Other projects are also doing the same
  481. lovetox if you have concrete objection you need to formulate your argument in full
  482. MattJ It's not like OMEMO is the only one
  483. Laura has left
  484. moparisthebest Some in the community (like me) don't care if it's impossible to implement a non-gpl OMEMO client
  485. moparisthebest But it was determined that's not even the case so whatever :)
  486. nav > the opinion of the community is that is totally fine to implement under any license Was that the result of a legal review?
  487. nav As in, an actual IP lawyer being consulted?
  488. raghavgururajan has joined
  489. Laura has joined
  490. Zash You pay for a lawyer and find out
  491. nav Not that that would make things clear (nothing in law ever is), but at least would give some weight to the argument.
  492. atomicwatch has joined
  493. lovetox the spec is written in a way that you can implement it without looking at copyrighted material
  494. nav Zash: I'm not looking at implementing XEP-0384 in any context at the moment, but if that need ever comes up, I certainly will.
  495. lovetox so it follows if you do this, you dont need a lawyer that tells you that you didnt infringe copyright
  496. nav lovetox: Maybe I'm grossly misreading it, but the spec deals with the signalling rather than the underlying protocol (Axolotl) itself.
  497. lovetox of course if you look at copyrighted material, and copy it, then you are on your own
  498. nav > you dont need a lawyer that tells you that you didnt infringe copyright A lawyer will never tell you that.
  499. jubalh has left
  500. Sam has left
  501. nav > of course if you look at copyrighted material, and copy it, then you are on your own So do we agree that the legal status of OMEMO encryption is unclear, then?
  502. lovetox there is no omemo encryption in general
  503. lovetox there is YOUR implementation of it
  504. lovetox and yes im unclear of the status of YOUR implementation
  505. lovetox could be well that you infringed someones copyright while implementing it
  506. flow nav, the omemo xep uses https://signal.org/docs/specifications/doubleratchet/ as building block which is an open spec put in the public domain
  507. nav So you are saying that XEP-0384 is fine, as long as you do not implement it?
  508. lovetox as long as you infringe no ones copyright while implementing it
  509. flow Hence I am not sure how implementing omemo based on the XEP and the provided open specification brings you into any kind of legal trouble
  510. Sam has joined
  511. nav flow: That was discussed already. Would you be able to point out where it says that the specification is in "the public domain" (whatever that means for a specification)?
  512. flow https://signal.org/docs/specifications/doubleratchet/#ipr
  513. Laura has left
  514. nav Looking at https://signal.org/docs/specifications/doubleratchet/ it says "This document is hereby placed in the public domain."
  515. marc has left
  516. nav document ≠ specification
  517. Kev has joined
  518. flow hmm, not sure, given we talk about the document which specifies the protocol
  519. nav flow: you then are going to have to take my word for it, or get your own lawyer. ☺
  520. marc has joined
  521. nav At least one company have been sued (Wired) and another chose to pay hefty licensing fees (Whatsapp). Is this really something that should be promoted as an "open" standard?
  522. flow I have a philosophy of not conulting a lawyer for obvious things to me and wait for the cease and desist eltter first, which, worked out fine for me
  523. MSavoritias (fae,ve) has joined
  524. flow und I haven't heard of any laywers letter regarding OMEMO in the past
  525. lovetox nav, wired has been sued, and as a result changed nothing, there impl still is there, so what should tell us that?
  526. MSavoritias (fae,ve) has left
  527. flow I know about the Wired story
  528. lovetox disclaimer: My wired knowledge consists of the link MattJ posted earlier
  529. xnamed has joined
  530. flow But the Whatsapp things is new to me, and given that there are strong ties between Signal and Whatsapp it appears unlikely or highly likely that there is more to the story
  531. nav flow: I can share with you a copy of Romeo and Juliet just fine, but I cannot share with you my electronic copy of this https://www.penguin.co.uk/books/54572/romeo-and-juliet-by-shakespeare-william/9780141396477
  532. nav That's the difference.
  533. moparisthebest Was Wired GPL ?
  534. lovetox yes, according to the blog post
  535. flow nav, well, you could share the electronic copy of this if it was placed in the public domain, no?
  536. nav flow: if both the contents and the representation are out of copyright, yes.
  537. nav Please note: this is analogous to the discussion about "source available" and free and open source.
  538. flow so in the core of the wire article is this "but if you do an independent implementation, using the published reference documentation and background knowledge from having seen their code online, you can be accused of copyright infringement"
  539. flow which is true if your independent implementation is not GPL-derivate compatible licensed
  540. MattJ There is a third-party write-up here, with comment from Signal: https://www.forbes.com/sites/thomasbrewster/2016/05/11/wire-skype-sued-moxie-marlinspike-extortion/
  541. flow and I totally understand that Moxie would then ask for a license fee, if you don't want to put it under a GPL-derivate compatible license
  542. flow I would do the same
  543. flow *understandable
  544. nav flow: that is your choice, but in implementing an open protocol, other parties might have other interests at heart.
  545. flow I am sorry, but I fear I don't get what you are getting at :)
  546. MSavoritias (fae,ve) has joined
  547. flow and from reading the latest link MattJ just posted, especially the Update section with Moxie's response, the picture in my head that someone just tried to create a derivate work from the GPL licensed libsignal, whithout obeying the GPL, is just solidifying
  548. nav The situation here is somewhat analogous to what we've seen in the past with video codecs and such.
  549. nik has left
  550. raghavgururajan has left
  551. flow I can't comment on that because there haven been multiple situations with codes in the past decades that all are slightly different
  552. flow maybe not only even slightly different, but even completely different
  553. MSavoritias (fae,ve) has left
  554. raghavgururajan has joined
  555. MSavoritias (fae,ve) has joined
  556. Kev has left
  557. jubalh has joined
  558. Ingolf has left
  559. e-snail has joined
  560. nav flow: What I'm getting at was posted hours ago: the legal status of (implementing) OMEMO is unclear.
  561. nav Someone asked for clarification and I posted relevant references, which apparently some chose not to read but argue about them anyway.
  562. nav It has been pointed out that the underlying technology is licenced and that the licence is actively and aggressively enforced. XEP-0384 does not mention any of this.
  563. nav No legal review has taken place, and someone suggested that it is caveat emptor, yet XEP-0384 is silent on that too.
  564. flow nav, would you be so kind to re-post the references again? I have to admit that I did not read the complete backlog
  565. flow I am also not sure where it has been pointed out the the underlying technology has been licensed. the "reference" implementation, libsignal, is under an open source license, maybe that is what you mean? but the specification itself is in the public domain
  566. Ingolf has joined
  567. MattJ nav: XEP-0384 builds on top of public domain specifications published by Signal, it doesn't use anything they assert copyright over
  568. flow so if you don't look at the libsignal code, then you can create an implementation and put that implementation under whatever license you like
  569. nav flow: https://logs.xmpp.org/jdev/2022-08-14?p=h#2022-08-14-ceb48d4a212ed1ea
  570. nav flow: that's called reverse engineering. In theory you can (and I've done it, in a different domain). In practice, well…
  571. nav …the first thing you learn when you take a law class: "there is no true or false, no yes or no, no black or white".
  572. flow nav, what exactly is reverse engineering?
  573. MattJ In copyright matters the general term is a "clean-room implementation"
  574. flow nav, where exactly is (what?) reverse engineering?
  575. nav What MattJ says
  576. jubalh has left
  577. MattJ It's a well established practice for avoiding copyright issues
  578. nav Specifically, clean-room implementation is one form of reverse engineering, and what I was actually referring to. Thanks for the remark.
  579. flow ok I have multiple large PDF files in front of me
  580. PapaTutuWawa has left
  581. nav Note that you might still get sued though.
  582. flow I am not sure, even with the restrictions (D3.3?) you gave me, where it says that the technology that current omemo uses is licensed
  583. flow I am not sure why we are talking about reverse engineering now
  584. flow given that all of omemo can be implemented by just looking at open standards
  585. nav flow: did we not already discuss the Wire and Whatsapp *licensing* cases?
  586. flow yeah, but those where about the license of *software*, not of an standard
  587. flow It feels like you are not properly separating software licensing concerns and standard ones
  588. nav flow: already discussed, read the history log.
  589. Laura has joined
  590. flow I probably won't, but if you can give me a brief summary I'll read it
  591. nav Wire got accused of looking at OWS' libsignal source code to implement theirs.
  592. nav Which, it was argued, made theirs a derived work (this is a legal term of art, basically means we still kind of own some of it)
  593. nav According to Wire, you cannot implement Axolotl just be reading the "specification".
  594. flow I think you are also not considering the timeline here
  595. lovetox yes that was their opinion in 2015 or even earlier
  596. nav Which is in itself a well-known trick from patent writing.
  597. lovetox this is not the case anymore
  598. flow the double ratched specification only came end 2016
  599. nav Always leave out the one crucial detail.
  600. flow these days you can implement omemom without looking at libsignal
  601. flow these days you can implement omemo without looking at libsignal
  602. lovetox which is exactly what i wrote half an our ago
  603. flow I think multiple people stated by now that implementing omemo by just using the available open standards is not an issue
  604. nav flow: why are you trying to convince me that everything is fine with no evidence whatsoever? In the face of a proprietary protocol which, as has been established, the rights holder actively seeks to enforce licensing upon?
  605. lovetox nav, this gets old now
  606. nav > these days you can implement omemo without looking at libsignal Where should I look instead?
  607. lovetox your arguments is pointing to links, and if we bring a counter argument then you point again to the link
  608. lovetox either you take part in the discussion or not
  609. nav lovetox: I know it gets old. And I'm surprised at the reaction here.
  610. mh has joined
  611. flow nav, start with xep384, everything else is linked by that xep
  612. lovetox i wrote half an our ago > the spec is written in a way that you can implement it without looking at copyrighted material now you ask > Where should I look instead?
  613. MattJ So the summary of OMEMO's "legal status" is: 1) XEP-0384 references only public domain specifications published by Signal, 2) GPL implementations can leverage most of libsignal, 3) non-GPL(/compatible) implementations must use a clean-room implementation, 4) Signal themselves haven't sued anyone and deny extortion of Wire (whether this is true does not really matter)
  614. flow nav, start with xep384, everything else you need to know to implement is linked by that xep
  615. flow MattJ, +1
  616. flow (only that xep384 probably also references other open specifications, besides the one published by Signal, like the ones published by the XSF ;))
  617. nav MattJ: And XEP-0384 mentions none of that. I feel that at the very least 2) and 3) should be in there, as well as a note to the effect that the underlying technology might have IP restrictions which might prevent certain uses or implementations.
  618. nav And now for a question, does the XSF have any sort of legal counsel at all?
  619. r4v3r23 has left
  620. flow why should a XEP tell you how software licensing works?
  621. nav flow: do you know what an essential patent is?
  622. MattJ nav: you think "the underlying technology might have IP restrictions" is true? We basically just established that it isn't true.
  623. Link Mauve nav, you have GPL implementations of most XEPs, it’d be weird to have to mention in each of them that if your software isn’t compatible with this license you shouldn’t use those implementations.
  624. jubalh has joined
  625. inky has left
  626. flow nav, I don't
  627. nav Link Mauve: that's a different albeit related situation. There might indeed be other XEPs where the underlying technology is not freely available.
  628. jubalh has left
  629. Laura has left
  630. Kev has joined
  631. flow Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge
  632. Link Mauve nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.
  633. Link Mauve There might exist implementations under a different license too.
  634. Link Mauve I’ve never looked at OMEMO, so I can’t comment on that part.
  635. nav flow: the "essential patent" appellative refers to the practice of pledging to allow other parties use of someone else's IP without that someone else forfeiting their rights to that IP, in the context of implementing a standard.
  636. MattJ At least in 2016 they confirmed they had no patents on the protocol, and I fail to find any: https://news.ycombinator.com/item?id=11727870
  637. MattJ So... I'm not really sure what more there is to say
  638. nav For instance, I have a patent (or other claim) to X, and X is needed to implement RFC98938. I promise that I will not sue anyone who uses X to implement RFC98938.
  639. flow I am also not sure where to put the "essential patent" pice in the omemo picture
  640. r4v3r23 has joined
  641. goffi has left
  642. flow I just wondered if it would be a good idea to prominently mark XEPs that are only based on open standards as such
  643. nav MattJ: a patent is just one type of IP right. I did not say anything about Axolotl and patents. I was trying to establish flow's level of awareness of the general domain of intellectual property, since I (don't think I) know him personally, that's all.
  644. nav flow: > Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge That seems like a good idea to me.
  645. nav …that's why I mentioned essential patents, to introduce that aspect of the discussion.
  646. e-snail has left
  647. nav Also, I had somehow assumed that to be the case, as is already the case in other areas of technology, such as ISO standards.
  648. nav That's why I found XEP-0384 a bit of an outlier.
  649. thomaslewis has joined
  650. MattJ What makes it an outlier?
  651. nav But as Link Mauve pointed out, this probably (likely?) affects other XEPs as well.
  652. r4v3r23 has left
  653. Link Mauve nav, did I?
  654. Link Mauve I only mentioned that there are XMPP libraries licensed under a GPL license.
  655. nav Link Mauve: > nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.
  656. thomaslewis has left
  657. nav Yup, that's it.
  658. r4v3r23 has joined
  659. thomaslewis has joined
  660. MattJ We had a whole drama about it depending on a specific implementation which was GPL, and it got updated due to that (despite some disagreement)
  661. Link Mauve Speaking of which, the new https://xmpp.org/software/libraries/ doesn’t mention the license of a particular library, this should probably be fixed.
  662. nav MattJ: The fact that I was aware of the shenanigans concerning its licensing.
  663. MattJ What shenanigans?
  664. nav Link Mauve: 👍
  665. Link Mauve nav, but there are no shenanigans, that’s the conclusion of the past hour of discussion.
  666. nav Link Mauve: that's the conclusion only because seemingly nobody bothered to read the references that I posted.
  667. jubalh has joined
  668. mirux has left
  669. mirux has joined
  670. Link Mauve nav, it got debunked by Signal according to “19:25:45 MattJ> At least in 2016 they confirmed they had no patents on the protocol, and I fail to find any: https://news.ycombinator.com/item?id=11727870”
  671. nav Link Mauve: I never mentioned patents in the context of Axolotl.
  672. Kev has left
  673. MattJ What is the context of this discussion, if not Axolotl?
  674. nav And forgive me for giving more credibility to a CNRS researcher than to the main interested party and a blog post.
  675. nav MattJ: I never said anything about Axolotl being or not being patented. That's a red herring. What I did mention is that their approach to IP enforcement is *different* from patenting.
  676. MattJ OK. I missed that then.
  677. Matrix Traveler (bot) has left
  678. homebeach has left
  679. nav no probs
  680. homebeach has joined
  681. Matrix Traveler (bot) has joined
  682. nav But, to wrap it up: does the XSF have access to legal counsel? Is there any sort of legal review or involvement in the publication of XEPs, or is it completely caveat emptor?
  683. Laura has joined
  684. nav I'm asking because, again, when working to ISO standards one is reasonably clear of the conditions under which a standard may be implemented.
  685. MattJ The XSF does not have a permanent legal council for stuff like this. We would seek such counsel if deemed necessary, but there is no indication here that it is necessary.
  686. nav And I, perhaps foolishly, assumed it would be the same with XEPs.
  687. MattJ The XSF's IPR policy is on the site
  688. nav MattJ: Thanks. I just found it via Google.
  689. flow nav, I actually look at the PDFs, but couldn't find anything related
  690. flow related to the discussion
  691. flow but then again, those XEPs are big
  692. flow and, tbh, just because it is a academic publication shouldn't give it automatically credability
  693. jubalh has left
  694. flow even if it was peer reviewed, which I am not sure if this even was
  695. MSavoritias (fae,ve) Yep. Its basically the same coclusion we arrived half an hour ago. Read the XEP, look for an implementation that fit your license.
  696. MSavoritias (fae,ve) If a dev doesnt look at licenses that his thing
  697. MSavoritias (fae,ve) And the XEP has nothing to do with the libsignal implementation. Its an open standard
  698. flow for example you mention D3.3 and D3.6. D3.3 is "Problems of peer-to-peer instant messaging: from contact discovery to battery consumption", which does not seem to deal with license or IP issues. And I can't even find a D3.6
  699. r4v3r23 has left
  700. thomaslewis has left
  701. e-snail has joined
  702. nav flow: that must be a different D3.3. This one, of which I do not have access to an offline copy that I can share right now and for which the one online copy I was able to find was inside that ZIP file linked from https://nextleap.eu/deliverables.html is titled "Draft Decentralized Case Studies" (the direct link on that page 404, hence why the need to go to the ZIP). The discussion is on page 14 &ss.
  703. nav D3.6 is indeed missing from the archive but I shared a link above (https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c208ad8b&appId=PPGMS – PDF). Relevant discussion starts on page 16.
  704. inky has joined
  705. PapaTutuWawa has joined
  706. nav The authors have also published a number of papers on the subject, some of which are listed here: https://nextleap.eu/publications.html That's a bit heavier reading as you might expect and albeit interesting, probably do not add much to the discussion.
  707. flow nav, yes there is a whole D3.3DraftDecentralizedCaseStudis.pdf, which includes the § 3.3 I menionted
  708. Sam A giant list of papers on various topics indeed does not add anything to the discussion. If you can't even summarize it, and the only evidence you have is one or two papers that mention it in passing (possibly? In at least the one of them I just tried to look at I couldn't find anything related) then this discussion probably isn't going to go anywhere and I'd say the other side has presented a lot more evidence and should probably be trusted more.
  709. xecks has left
  710. flow but the D3.3 PDF does not really talk about license, leave alone license issues wrt to the omemo specification
  711. lovetox i read 3.6 its just a summary of the history of the signal protocol and everything we talked about
  712. flow and the D3.6 PDF essentially just states that libsignal is GPL licensed
  713. nav flow: > Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge https://xmpp.org/about/xsf/ipr-policy/#contrib-approval
  714. flow so nothing so far in the PDFs convinces me that there are any license issues with omemo
  715. xecks has joined
  716. flow nav, yeah, I assumed that we have something like this in our IPR, but wasn't sure :)
  717. mirux has left
  718. mirux has joined
  719. Kev has joined
  720. lovetox2 has left
  721. nav flow: that is clear and the goal is not to convince you. I just hadn't realised that there was no process or resources whatsoever to determine the licensing and availability status of technology underlying XEPs, that's all.
  722. Laura has left
  723. Laura has joined
  724. MSavoritias (fae,ve) nav: have you read the mailing list at the time of it being discussed? Because you have been told that there were. Who is the one spreading the "disinformation" as you say here
  725. Kev has left
  726. thomaslewis has joined
  727. thomaslewis has left
  728. Kev has joined
  729. nav MSavoritias (fae,ve): Nope, though I have been told earlier on that there is none with a legal background that gets consulted in the process of approving XEPs. Do you recall the approximate date when this discussion that you refer to would have taken place in the mailing list?
  730. flow I think there is such a proces, but we just don't call a laywer each time
  731. nav "I think there is such a process" doesn't sound terribly confidence-inspiring. 🤪 Surely it's documented somewhere?
  732. MSavoritias (fae,ve) nav: Probably around the time the XEP got posted. It should be in the bottom of the page in versions.
  733. nav First revision you mean?
  734. MSavoritias (fae,ve) Yeah
  735. MSavoritias (fae,ve) So around then: 2015-10-25
  736. nav 👍
  737. flow well, you can't really compare the XSF with the ISO
  738. Kev has left
  739. xnamed has left
  740. nav To be clear, personally I don't have an issue with things just being thrown out there without compliance review, especially since we're far from the heydays of XMPP (and the funding that goes with it), but as a suggestion, perhaps a disclaimer to the effect – or at least getting rid of § 3.2 of the intellectual property rights policy (since there is no active enforcement) might be in order?
  741. xnamed has joined
  742. FireFly has joined
  743. nav MSavoritias (fae,ve): Thanks. The discussion I found takes place around May 2017 but I found no mention of a legal review and crucially, one person there, a developer, seems to make the fatal mistake of mixing up the rights to the document with the rights to the standard (to be fair, a casual reading of the OWS document does lead one to make that mistake).
  744. MattJ I'm not really sure what you're expecting an alternative would be though. There's no such thing as an exhaustive IPR review (i.e. anyone at any time can claim anyone is infringing, regardless of whatever review has/hasn't been performed)
  745. MattJ I can understand why a standards org that charges for access may undertake IPR reviews on behalf of its members, but that's quite obviously beyond scope of the XSF. The IPR policy details our scope and expectations of contributors.
  746. nav MattJ: XSF IPR § 1.2 (https://xmpp.org/about/xsf/ipr-policy/#intro-role) on the part of OWS is what I would expect.
  747. nav There is no such statement from them, is there?
  748. antranigv has joined
  749. MattJ They explicitly decalare their specs as public domain, so yes
  750. Kev has joined
  751. antranigv has left
  752. antranigv has joined
  753. nav Where that? Here? https://signal.org/docs/specifications/doubleratchet/#ipr
  754. MattJ Exactly
  755. nav So no, sorry.
  756. MattJ ?
  757. nav We've been going back in circles and I got the information I wanted hours ago, so it's time to end this increasingly pointless discussion. Once again: "This document is hereby placed in the public domain." does not mean what you think it means. There is a reason why IPR § 1.2 is written the way it's written and the two are in no way equivalent.
  758. nav I have already said this: "this *document" … blah blah … public domain" means you're free to save a copy of that webpage to your hard drive, or post it on your own blog, or print it out, frame it and sell it. It does not give you any rights to the actual specification and most certainly does not mean "that in perpetuity any entity may independently, and without payment or hindrance, create, use, sell, distribute, or dispose of implementations of XMPP and of any XMPP Extension. "
  759. FireFly has left
  760. FireFly has joined
  761. antranigv has left
  762. MattJ The document is the specification
  763. nav Nope. The document is the document.
  764. jubalh has joined
  765. MattJ And the specification is...?
  766. FireFly has left
  767. nav Why would they (OWS) do that is not for me to guess, and I see how it's open to misinterpretation.
  768. FireFly has joined
  769. FireFly has left
  770. FireFly has joined
  771. MattJ I don't see any potential for misinterpretation. A specification is a type of document. I see no problem with saying "this document"
  772. nav MattJ: Really, ask a lawyer friend to explain this to you. I have already tried, and failed, by giving the example of an out of copyright work and a (forget what it's called now, a realisation?) of that work.
  773. xnamed has left
  774. Kev has left
  775. MSavoritias (fae,ve) Or we can just read all the sources that have been given to the contrary here
  776. MSavoritias (fae,ve) Including wire mixinp up licenses for the implementation
  777. nav Yes, you can do whatever you want. Feel entirely free.
  778. MSavoritias (fae,ve) *not* the specification. As far as i understood that example that was brought up
  779. nav has left
  780. xnamed has joined
  781. Mx2 So finally was messing with xml stream acknowledged?
  782. Mx2 I remember it pretty good
  783. jubalh has left
  784. MattJ ?
  785. Mx2 has left
  786. atomicwatch has left
  787. TheCoffeMaker has left
  788. mirux has left
  789. mirux has joined
  790. TheCoffeMaker has joined
  791. lovetox2 has joined
  792. lovetox2 has left
  793. lovetox2 has joined
  794. PapaTutuWawa has left
  795. PapaTutuWawa has joined
  796. goffi has joined
  797. lovetox2 has left
  798. lovetox2 has joined
  799. lovetox2 has left
  800. lovetox2 has joined
  801. Kev has joined
  802. lovetox2 has left
  803. lovetox2 has joined
  804. lovetox2 has left
  805. lovetox2 has joined
  806. lovetox2 has left
  807. lovetox2 has joined
  808. edhelas has left
  809. edhelas has joined
  810. lovetox2 has left
  811. lovetox2 has joined
  812. lovetox2 has left
  813. lovetox2 has joined
  814. lovetox2 has left
  815. lovetox2 has joined
  816. lovetox2 has left
  817. lovetox2 has joined
  818. lovetox2 has left
  819. Kev has left
  820. lovetox2 has joined
  821. lovetox2 has left
  822. lovetox2 has joined
  823. lovetox2 has left
  824. jubalh has joined
  825. pulkomandy has left
  826. zawarudo has joined
  827. pulkomandy has joined
  828. Alex has left
  829. lovetox2 has joined
  830. lovetox2 has left
  831. lovetox2 has joined
  832. lovetox2 has left
  833. Alex has joined
  834. Mario Sabatino has left
  835. thomaslewis has joined
  836. mirux has left
  837. mirux has joined
  838. thomaslewis has left
  839. jubalh has left
  840. Kev has joined
  841. larma has joined
  842. Kev has left
  843. FireFly has left
  844. FireFly has joined
  845. Mx2 has joined
  846. mirux has left
  847. marc0s has left
  848. marc0s has joined
  849. thomaslewis has joined
  850. thomaslewis has left
  851. thomaslewis has joined
  852. coleman has left
  853. thomaslewis has left
  854. debacle has left
  855. Kev has joined
  856. thomaslewis has joined
  857. xnamed has left
  858. Kev has left
  859. thomaslewis has left
  860. xnamed has joined
  861. marc has left
  862. PapaTutuWawa has left
  863. xnamed has left
  864. lovetox2 has joined
  865. thomaslewis has joined
  866. lovetox2 has left
  867. thomaslewis has left
  868. thomaslewis has joined
  869. xecks has left
  870. Ingolf has left
  871. marc has joined
  872. wurstsalat has left
  873. thomaslewis has left
  874. TheCoffeMaker has left
  875. TheCoffeMaker has joined
  876. marc0s has left
  877. marc0s has joined
  878. Kev has joined
  879. SouL has left
  880. MSavoritias (fae,ve) has left
  881. marc has left
  882. adx has left
  883. antranigv has joined
  884. Kev has left
  885. nicoco_ goffi: I have a question about prosody's mod_privilege which you authored I think, I hope here is an OK place to ask. if a component sends a chat message on behalf of another JID, is this chat message supposed to create a MAM entry? After a little playing with it, I *think* it does not. is this the expected behaviour?
  886. larma has left
  887. Mx2 has left
  888. atomicwatch has joined
  889. thomaslewis has joined
  890. marc has joined
  891. Ingolf has joined
  892. thomaslewis has left
  893. atomicwatch has left
  894. thomaslewis has joined
  895. emus has left
  896. Kev has joined
  897. marc0s has left
  898. marc0s has joined
  899. Schimon has left
  900. Kev has left