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


  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’


  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’


  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’


  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


  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’


  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


  346. techmetx11


  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’


  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


  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


  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


  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)


  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


  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