XSF logo XSF Discussion - 2017-09-14


  1. emxp has left
  2. SouL has left
  3. la|r|ma has left
  4. la|r|ma has joined
  5. la|r|ma has joined
  6. waqas has left
  7. ralphm has joined
  8. Guus has left
  9. goffi has left
  10. lskdjf has joined
  11. la|r|ma has joined
  12. SamWhited has left
  13. SamWhited has joined
  14. Tobias has joined
  15. Tobias has joined
  16. waqas has joined
  17. Vaulor has left
  18. jere has joined
  19. efrit has joined
  20. Yagiza has joined
  21. Guus has left
  22. Guus has left
  23. vanitasvitae has left
  24. Zash has left
  25. jere has left
  26. jere has joined
  27. Zash has left
  28. efrit has left
  29. efrit has joined
  30. efrit has left
  31. efrit has joined
  32. waqas has left
  33. waqas has joined
  34. Guus has left
  35. Guus has left
  36. efrit has left
  37. efrit has joined
  38. SamWhited has left
  39. uc has joined
  40. sezuan has joined
  41. mimi89999 has joined
  42. mimi89999 has left
  43. uc has joined
  44. uc has joined
  45. uc has joined
  46. mimi89999 has joined
  47. Valerian has joined
  48. waqas has left
  49. waqas has joined
  50. daniel has left
  51. daniel has joined
  52. jere has left
  53. moparisthebest has joined
  54. jcbrand has joined
  55. ralphm has joined
  56. Guus peter: Raja hi's you back. ;)
  57. daniel has left
  58. efrit has left
  59. Valerian has left
  60. sonny has joined
  61. Guus has left
  62. jcbrand has left
  63. waqas has left
  64. ralphm has joined
  65. sonny has joined
  66. waqas has joined
  67. fp-tester has left
  68. fp-tester has joined
  69. fp-tester has left
  70. ralphm has joined
  71. fp-tester has joined
  72. emxp has joined
  73. tux has left
  74. tux has joined
  75. Guus has left
  76. blabla has left
  77. ralphm has left
  78. Ge0rG has left
  79. Valerian has joined
  80. daniel has joined
  81. tim@boese-ban.de has joined
  82. Guus Can someone verify that we formally disbanded the Communiations Team and the Review Team?
  83. Guus dwd seems to think so - lacking any documentation, it'd be good to have a second person weighing in.
  84. Guus ah, I forgot that there was a discussion on a mailing list. I'll continue it there.
  85. jonasw is there an archive of board meeting minutes aside from the mailing list?
  86. Guus the website has them, but not after 2015
  87. Guus ah, no
  88. Guus those are council votes and member vote meeting minutes
  89. Guus not board
  90. Guus jonasw: you might know: can we configure the mailing list daemon to have mailing list archives, without accepting new messages? Close the list down, without removing the archive?
  91. jonasw Guus, yes
  92. jonasw there are a few ways. one would be to remove all members, another would be to set all members to moderated and add a matching moderation/rejection message
  93. jonasw that way the list formally continues to exist, anyone (who has permission) can read the archives, and if needed you can resume list operation at some ponit
  94. jonasw downside: the moderation/rejection notice thing can turn into backscatter quickly, but if simply discarding all messages is ok, that’d work too
  95. Guus tx
  96. jonasw all of this can be done via the webinterface
  97. edhelas has left
  98. jonasw my two cents is that removing the supposedly inactive teams from the website after two rather experienced members mentioned that they have shut down is probably fine
  99. jonasw if someone complains, git revert isn’t hard
  100. jonasw but I would probably wait it out too, if I was in your position ;-)
  101. Zash has joined
  102. Vaulor has joined
  103. Guus jonasw: I'm modifying the PR as we type, and pointing to that PR in a mail reply.
  104. Guus people can weigh in on that, and if they don't, we'll eventually merge the PR
  105. Guus (but the PR doesn't take care of the MUC/Mailinglist entities, if they're there, so a bit more work might be needed)
  106. sezuan has left
  107. Guus done / mailed.
  108. Guus also, I'm out for now
  109. Guus bye
  110. jonasw gl
  111. Guus has left
  112. edhelas has left
  113. edhelas has joined
  114. jonasw now I’m wondering whether it’d make sense to have loosly defined groups of occupants in MUCs which can be addressed with @foo, like @iteam. possible implementation: people who want to belong to a group publish <member xmlns="...">iteam</member> in their presence. their client will highlight on @iteam. other clients can show that @iteam refers to a specific group of people.
  115. Alex has joined
  116. Ge0rG jonasw: ITYM MIX.
  117. jonasw whatever
  118. edhelas has left
  119. edhelas has joined
  120. jonasw this is entirely independent of the relay as long as it publishes presence
  121. Ge0rG jonasw: I think that the idea has merit, but I'd rather use the affiliation mechanism for that.
  122. jonasw meh, probably breaks horribly with MSN
  123. jonasw but a JID can only have one affiliation, and affiliations also have influence on the permissions
  124. waqas has left
  125. Ge0rG Damn. We can't have nice things.
  126. Ge0rG jonasw: [xep 317] is there.
  127. jonasw (publishing this in presence has the advantage that things like CSI can act on that)
  128. Ge0rG Sigh. Bots?! https://xmpp.org/extensions/xep-0317.html
  129. intosi has joined
  130. jonasw ha
  131. Ge0rG Is there an XEP to require bots to respond with a link to [xep FOO]?
  132. jonasw that looks much like what I proposed
  133. Guus has left
  134. Guus has joined
  135. dwd jonasw, Hats were intended as ad-hoc role based access control (sorta).
  136. jonasw syntactically anyways
  137. dwd jonasw, You're after self-selecting groups, right?
  138. jonasw yupp
  139. dwd jonasw, Self-selecting groups sound like an interesting concept.
  140. jonasw (that XEP needs some wording on "MUC service supporting hats MUST NOT forward <hats/> payload in presences sent by clients"
  141. jonasw )
  142. jonasw dwd, thanks ☺
  143. jonasw essentially it’d be publishing a list of words your client highlights on
  144. Guus has left
  145. dwd jonasw, I think XEP-0317 might need killing with fire, if it weren't an amusing bit of XSF lore.
  146. Guus has joined
  147. dwd jonasw, Hmmm. Well. It's codifying a <reference/> system, that's for sure. Not so sure it'd be a simple text match, but maybe it would be in MUC.
  148. jonasw mmm, using reference for that is appealing
  149. Guus has left
  150. Guus has joined
  151. SouL jonasw, I would love that feature. I miss it at work, for example. But it is really useful I think.
  152. dwd jonasw, But anyway, it's a "publish a list in presence" thing, I think, if they're self-selecting, for MUC. For MIX, we could do something more formalised.
  153. jonasw dwd, MIX could simply gather that from presence into a pubsub node
  154. jonasw then clients don’t have to worry about things
  155. jonasw hm, then again, you probably don’t want to have the list to be the same in all rooms
  156. jonasw this would be a nice XEP to build on top of MUC, MIX and references.
  157. dwd jonasw, MIX occupants might not have any presence, though.
  158. jonasw dwd, yes, and there are other issues with that, so MIX indeed needs a different mechanism for this
  159. dwd jonasw, Oh, and yeah, MIX presence is just broadcast presence, isn't it?
  160. Ge0rG dwd: while we are on reference systems, were you able to get a grip on the reactions mechanism author?
  161. tux Good morning!
  162. jonasw exactly
  163. jonasw tux, good morning and congrats :)
  164. dwd Ge0rG, Sort of. Doesn't work as cleverly as I'd thought.
  165. tux jonasw: thanks :)
  166. dwd Ge0rG, But also our internal document describing it is 0 bytes. :-)
  167. tux I tried to find out what "SCAM" means in the XSF context, but could not really find anything. (Mostly a resources page on the XMPP wiki; Google is not really helpful here.) Could anybody please enlighten me? Or the newbies via members list? Am I just blind to the relevant paragraph/link?
  168. dwd tux, Summits Conferences And Meet-ups.
  169. jonasw tux, it is Summits, Conferences And Meetups team
  170. Ge0rG I think there are two important issues with hats/notify-strings/whatever in presence: 1. it helps a MUC service / user's server to determine "important" messages and to push them to CSI-inactive / Push enabled clients. 2. this is another data leak in E2EE scenarios
  171. tux Ah, thanks :D
  172. dwd tux, Outreach work team, basically.
  173. Ge0rG tux: https://wiki.xmpp.org/web/XSF_Summits_Conferences_And_Meetups_workgroup
  174. jonasw Ge0rG, don’t do it with E2EE unless you can encrypt whole stanzas *shrug*
  175. Ge0rG jonasw: you know my position on E2EE :P
  176. jonasw :)
  177. jonasw I indeed do
  178. tux That page even mentions "SCAM", but Wiki search for SCAM only returns this page: https://wiki.xmpp.org/web/SCAM/Material
  179. Ge0rG so, "jonasw> Ge0rG, don’t do it with E2EE" - full stop.
  180. jonasw Ge0rG, E2EE in MUC contexts is not my department
  181. Ge0rG tux: there is also a wiki category "SCAM". Somebody should add a descriptive text to it.
  182. tux Ge0rG: if its fine with you I'd just add the link for now
  183. dwd Ge0rG, Thanks for volunteering, Somebody.
  184. tux (link to scam team page)
  185. jonasw Ge0rG, can you rename and redirect the "XSF_Summits_Conferences_And_Meetups_workgroup" page to "Summits, Conferences And Meetups (SCAM) workgroup" or something?
  186. jonasw then it’d turn up in the search more reliably
  187. jonasw (I heard you have wiki powers)
  188. Ge0rG dwd: I was trying to motivate our new member, actually
  189. dwd Also, it's a "Work Team", which has a formal meaning within our bylaws.
  190. jonasw Ge0rG, ah, then while renaming fix it to Work Team too :)
  191. Vaulor has left
  192. Valerian has left
  193. Valerian has joined
  194. dwd We should probably create a parallel "Special Interest Group", too, in order to have an open group without executive powers.
  195. Valerian has left
  196. stefandxm has left
  197. Ge0rG dwd: we should watch out that we don't end up with more groups than we have active members.
  198. tux I've just done this for now: https://wiki.xmpp.org/web/SCAM/
  199. jonasw tux, good start, but trailing slashes are uncommon in wiki URLs
  200. jonasw also, try a #REDIRECT instead (<https://www.mediawiki.org/wiki/Help:Redirects>)
  201. Flow has joined
  202. tux (Why does the wiki engine not remove the trailing slash from the URI? -.-)
  203. Ge0rG tux: because you added one?
  204. Ge0rG /es are kind of funny in mediawiki
  205. Valerian has joined
  206. jonasw / is just another character to mediawiki
  207. jonasw it doesn’t care
  208. jonasw while it cares way too much about capitalisation
  209. Guus has left
  210. Guus has joined
  211. tux I see.
  212. Guus has left
  213. Guus has joined
  214. stefandxm has joined
  215. Guus has left
  216. Guus has joined
  217. tux Okay ,I should have moved the SCAM/ page instead of creating another one
  218. tux the SCAM redirect is done, but I cannot get rid of SCAM/
  219. Guus has left
  220. jonasw you might need Ge0rGs superpowers to remove SCAM/
  221. Guus has joined
  222. jonasw yes, &action=delete gives a permissions error
  223. tux Ge0rG: can you please remove SCAM/ ?
  224. Zash has left
  225. tux is off to a meeting
  226. Ge0rG tux: done as requested
  227. tux Ge0rG: thanks :)
  228. edhelas would it be possible to add https://wiki.xmpp.org/web/T-DOSE_2017 to SCAM ?
  229. goffi has joined
  230. Zash has joined
  231. edhelas has left
  232. edhelas has joined
  233. Ge0rG edhelas: at your service
  234. edhelas Guus, you just got a mail from Jean-Paul Saman to know what is the status
  235. edhelas if there is people that lives in Belgium, NL or Europe in general and are interested about a nice little event in Eindhoven in November please have a look at the T-DOSE 2017 page on the wiki :)
  236. SouL Guus, regarding the logo, if you check this: https://xmpp.org/images/promo/xmpp_server_guide_2017.pdf it looks OK there. Are there two versions of the logo or the author of that PDF updated the logo himself?
  237. Martin has joined
  238. la|r|ma has joined
  239. tim@boese-ban.de has left
  240. jabberatdemo has joined
  241. Guus SouL: unsure
  242. SouL I was sure that I saw the logo like you say on Github, but didn't want to say anything until I could find a proof
  243. jabberatdemo has left
  244. jabberatdemo has joined
  245. Guus has left
  246. Guus has joined
  247. Guus has left
  248. Guus has joined
  249. Guus SouL: I'm traveling. Please comment in github
  250. lskdjf has joined
  251. jabberatdemo has left
  252. sonny has left
  253. sonny has joined
  254. sonny has left
  255. sonny has joined
  256. Steve Kille has left
  257. Guus has left
  258. Guus has joined
  259. Steve Kille has left
  260. stefandxm has left
  261. stefandxm has joined
  262. Steve Kille has left
  263. Steve Kille has joined
  264. jubalh has joined
  265. pep. has left
  266. lumi has joined
  267. edhelas hi, I'm working on my PR for pubsub#multi-items in the 0060
  268. edhelas what do you think of "The service supports the storage of multiple items per node and requires the pubsub#max_items configuration item to be exposed to the user, and allow sensible values."
  269. Martin has left
  270. Valerian has left
  271. Martin has joined
  272. Tobias has joined
  273. goffi edhelas: I don't see how max_items can indicate that there is no maximum (unlimited items)
  274. goffi I think it's missing
  275. edhelas should we add that feature as well ?
  276. edhelas what about setting it to zero ?
  277. goffi it it's made mandatory with multi-items, it should be there for sure
  278. goffi also max_items use underscore (_) while multi-items uses dash (-), should be made coherent
  279. goffi hum it's max_items which is not coherent with others, too late to change probably
  280. goffi max_items is not even in https://xmpp.org/extensions/xep-0060.html#features with others :(
  281. edhelas should I add it ?
  282. edhelas I'll add it
  283. goffi edhelas: max_items is not enough by the way ? If I have max_items > 1 I have multi-items right?
  284. goffi I guess you should yes
  285. goffi it will be reviewed by council anyway
  286. edhelas yes but it's a feature exposure
  287. edhelas if you have max-items exposed, I don't know if you can support more than 1
  288. edhelas multi-items ensure that
  289. goffi edhelas: if max-items = 10 we know that we can support 10, and we should have a value for unlimited
  290. edhelas or basically we change max-items and we say that it should be here if the server doesn't support more than one
  291. goffi looks like redundant to me, but I may be missing something
  292. edhelas goffi, what if the node is not even configured, or not existant ?
  293. edhelas how can I know if the service can handle more than one ?
  294. goffi edhelas: oh you want this to be exposed by the service, not the node, OK
  295. goffi max_items don't make sense for a service indeed
  296. goffi or maybe it does, not sure actually
  297. edhelas ralphm, here ?
  298. edhelas goffi, afaik, max-items is not a feature exposed by the service, but just a configuration variable
  299. edhelas that's why it's max_items and not max-items
  300. edhelas multi-items actually tell that info to the user and force max_items to be set above 1
  301. goffi edhelas: but we need to know how many items, if it's multi-items but with 2 items max, it's not useful for e.g. a blog
  302. edhelas this is something different, I'm talking about the service features again here
  303. goffi that doesn't change the point
  304. jonasw Guus, your logo thing is a cannot unsee
  305. edhelas what you are requestion is exposing max_items to the node metadata, like the title or the number of subscribers
  306. edhelas *requesting
  307. edhelas goffi, I'll add that in the metadata
  308. goffi edhelas: it's also a service thing, if I create a new node, I need to know if I can store more that 5 items for instance
  309. edhelas this all "authorisation" thing is quite buggy in the 0060
  310. edhelas "if I create a new node" => there's no way to know if you are even allowed to create a new node, or publish in it
  311. edhelas 0060 is based on a "fail to try" pattern
  312. Wiktor has left
  313. Wiktor has joined
  314. edhelas this would require to expose the access model
  315. la|r|ma has joined
  316. daniel has left
  317. goffi I don't see harm in that
  318. edhelas https://github.com/xsf/xeps/pull/500/files
  319. goffi edhelas: it's missing a way to indicate "no limit"
  320. Guus has left
  321. edhelas goffi, https://github.com/xsf/xeps/pull/500#issuecomment-329440142
  322. goffi edhelas: OK good
  323. Guus jonasw: welcome in my world of cannot unsee.
  324. Valerian has joined
  325. Link Mauve “16:08:43 SamWhited> Because we have a lot of different clients and servers and enough interoperability problems without denying every element that has some clients proprietary extension in it.”, funny you say that, I’ve found a bunch of bugs in various implementations by doing exactly that. ^^
  326. Link Mauve Not that I would use it in release mode, but for debug it’s a fantastic tool.
  327. tim@boese-ban.de has left
  328. Martin has left
  329. Wiktor has left
  330. Tobias has joined
  331. Wiktor has joined
  332. dwd has joined
  333. dwd has joined
  334. jabberatdemo has joined
  335. jere has joined
  336. jabberatdemo has left
  337. Wiktor has joined
  338. la|r|ma has joined
  339. goffi Link Mauve: what are you talking about? Looks interesting (I have not message from SamWhited in my logs, but I may be missing a part)
  340. Holger goffi: http://logs.xmpp.org/xsf/2017-09-12/#15:05:02
  341. Link Mauve goffi, it was about making a strict XMPP parser, which checks that no foreign element or attribute is set on known elements.
  342. Link Mauve https://hg.linkmauve.fr/xmpp-parsers
  343. Link Mauve I already found many issues in many different implementations, both clients and servers.
  344. jonasw Astro
  345. jonasw the world’s small
  346. jonasw Link Mauve, do you do your DNS yourself?
  347. Holger has left
  348. Link Mauve jonasw, no, I use the domain crate.
  349. jonasw I see, anyways, I PM’d you with some issues I found, you may want to raise them with your provider
  350. Link Mauve Also, xmpp-parsers itself doesn’t handle any connection, it only parses XML into Rust structures.
  351. jonasw ahhhh
  352. jonasw different thing
  353. jonasw I was talking about DNS for linkmauve.fr
  354. Link Mauve Oh, then yes I do. ^^
  355. la|r|ma has joined
  356. Wiktor has joined
  357. Wiktor has joined
  358. Ge0rG The author of https://www.bleepingcomputer.com/news/security/this-spam-service-will-charge-25-to-stop-spamming-you/ seems to be very interested in XMPP <https://www.bleepingcomputer.com/author/catalin-cimpanu/> I wonder if we should contact him and involve him a bit in SPAM.
  359. Link Mauve Fixed, I forgot to bump my SOA, so my secondary didn’t receive the newer revision.
  360. SouL Ge0rG, sounds like a very great idea! Nice to read this also "the easiest way to reach Catalin is via his XMPP/Jabber address at campuscodi@xmpp.is."
  361. Guus has left
  362. jere has left
  363. jere has joined
  364. Ge0rG SouL: yeah, I was positively impressed.
  365. Yagiza has joined
  366. stefandxm Iam making a protocol for time series data. I am seeking feedback to see if I should make an XEP of it. It is available at http://opensource.clayster.com/lwtsd/Communications/lwtsd/
  367. jonasw Ge0rG, yes we should
  368. jonasw will you do it?
  369. stefandxm (it is work under progress)
  370. stefandxm or in progress :-)
  371. dwd stefandxm, The best way to seek such feedback is to submit it to the XSF as a protoXEP.
  372. daniel has left
  373. stefandxm dwd, yeah. but its quite a lot of work to rewrite it to xep format so I'd like some comments before committing to that
  374. intosi stefandxm: I note you added an element starting with xml (xmlschema), which is generally reserved for the XML spec itself (see XML 1.0 §3)
  375. stefandxm ty. ill fix that
  376. intosi Marv!
  377. stefandxm iam also struggling with my xml schema expertise in specifying "type" information. i tried to use xs:facet as xsd itself is doing but i couldnt get it through the parser
  378. Link Mauve stefandxm, ugh, your server (opensource.clayster.com) doesn’t support HTTPS. :/
  379. stefandxm but the parser seems broken in mono so it might be valid
  380. stefandxm link mauve, i know.
  381. Ge0rG jonasw: I will after reading all his articles
  382. jonasw stefandxm, I’m having a hard time to figure out what the specifciation does and how it works in the end. A few examples would be useful
  383. stefandxm jonasw, did you check the graphs in http://opensource.clayster.com/lwtsd/Communications/lwtsd/#operations-overview ?
  384. Valerian has left
  385. Valerian has joined
  386. jonasw yes, but those don’t show me why you’d use that specification for what
  387. stefandxm but yes, examples are coming
  388. jonasw and what those resources are etc.
  389. stefandxm they are abstract so it may be that ;-)
  390. jonasw possibly :)
  391. jonasw examples would be great
  392. stefandxm yeah. coming
  393. intosi Work in progress, thanks for sharing this early!
  394. stefandxm also, in the protocol definition it doesnt make sense to "sell in" the protocol itself. but its a bit tough to read from scratch i know that
  395. stefandxm in the commercial side we make tutorials and stuff for the protocols but it doesnt make sense to add to the protocol itself
  396. jonasw generally it sounds like something I could use myself, but I’m having a hard time to get a quick grasp on what it does
  397. stefandxm but xml examples is coming
  398. stefandxm its a generic data manipulation for time series data ie data that has a originated time. like sensor data
  399. stefandxm it has operations for write and read and subscriptions
  400. stefandxm the subscriptions work with triggers (and filters to be in another namespace). but it doesnt push the data it only informs new data is available
  401. stefandxm then the consumer needs to re-subscribe within a read to get new notifications
  402. jonasw in general, it may be sensible to look at RSM (<https://xmpp.org/extensions/xep-0059.html>), maybe you can re-use some syntax from there
  403. stefandxm i dont see how i can apply it in a generic sense
  404. stefandxm i want to support paginating in both total data set and within resource data set
  405. stefandxm since each resource may include n points
  406. intosi That's where RSM is generally useful, provided you have stable ids for every data point within a set.
  407. stefandxm it wont
  408. stefandxm you may also consider the data as being volatile
  409. intosi Then how will you do pagination?
  410. stefandxm by seeking and time frames
  411. intosi Time range?
  412. jonasw stefandxm, if you treat the exact timestamp as ID, you have what you need for RSM, afaict
  413. stefandxm but there may be many points on exact same timestamp
  414. intosi ^ what jonasw said
  415. intosi Not inherently ordered then?
  416. stefandxm so the source will have to store them as unique. which is not impossible but then you get modification/upsert hell
  417. intosi (within the same timestamp)
  418. stefandxm so the id will most likely not be an id in real life scenario
  419. stefandxm for me an id should be an id and not a seek index
  420. stefandxm so for say a schema where the schema has not changed the id solution makes sense to me
  421. stefandxm but not for the data points were ids are not required
  422. intosi Fair enough, which is also why MAM has separate start / end timestamps to be used in conjection with RSM
  423. intosi conjunction
  424. stefandxm the "volatileness" of the data in the data source makes it imo impossible to make seeking/pagination 100% without overhead. but in an application that can be addressed
  425. stefandxm but ive never seen a generic approach that works for all applications
  426. stefandxm unless you want to remove the "volatileness". which is often doable but not always (demands a lot more resources/memory in the data source)
  427. stefandxm btw. this is a moving forward from our side to replace the retracted xeps by peter waher named sensor data, control and the numberless iot events
  428. stefandxm and make it more generic and suitable for applications not using "iot"
  429. stefandxm the biggest challenge i see with this protocol is making the schema for resources easy to be implement but still extendable. thats why there is a simplified schema and a xmlschema (the element i will rename)
  430. Flow If i'm not mistaken the major concern with peter's IoT XEPs was them not being very XMPP idiomatic
  431. stefandxm personally i have many concerns with them
  432. stefandxm but since they are history its no point to argue about them imo
  433. Flow course, that's more a thing of preventing history repeating itself
  434. Valerian has left
  435. Flow stefandxm: what is a "schema for resources"?
  436. stefandxm yeah and thats why we are not sure if going via xsf is the perfect fit. but as long as we try to do it generic and xmpp-ish iam willing to give it a try :)
  437. stefandxm flow, describing data types and capabilities
  438. stefandxm ie if a resource is an int or a string and if you can read it, write to it and what filters it supports to reduce noise in subscriptions
  439. Flow I don't see the challenge exchanging data without prior knowledge about the structure, amount and type of the data
  440. Flow And I assume by "capabilities" you mean something like "remote control"? If so, that's also mostly solved by ad-hoc commands I'd guess
  441. stefandxm nah, just the stuff i wrote above really
  442. stefandxm but they may be done by writes with user specified types
  443. stefandxm for me data schematics is always a challenge :-)
  444. stefandxm but imo i managed to get it rather neat. but i am not sure everyone will agree hehe
  445. Martin has joined
  446. jere has joined
  447. stefandxm ok. i believe i updated the xml* thing with new names (now extended schema)
  448. Zash has left
  449. Zash has left
  450. Zash has joined
  451. tux has left
  452. moparisthebest are there security concerns with loading up unknown/untrusted schemas that you get sent?
  453. moparisthebest I don't really know anything about it, but I'm wondering if you could maliciously replace some XMPP schemas or something
  454. Ge0rG jonasw: "Consistent Color Generation" --> "Consistent Nickname Color Generation"
  455. Ge0rG or "User"
  456. jonasw Ge0rG, there are other use cases for that, such as roster groups
  457. Ge0rG jonasw: as it is, the name lacks context.
  458. Valerian has joined
  459. jonasw Ge0rG, comment on that on-list, so I don’t forget when I prepare an update
  460. Ge0rG jonasw: I think that having a too-specific qualifier beats no qualifier.
  461. moparisthebest I saw it as more generic, like you said, roster entries, bookmarks, etc
  462. moparisthebest but yea name doesn't matter
  463. Ge0rG moparisthebest: names DO matter.
  464. moparisthebest xep names don't matter that much to me
  465. Ge0rG moparisthebest: they matter to client devs
  466. moparisthebest just curious now, why?
  467. Ge0rG moparisthebest: it is already hard enough to find relevant XEPs
  468. stefandxm mop: there are concerns with dtd schemas
  469. stefandxm mop, so they are defaultly prohibited by most parsers
  470. moparisthebest stefandxm, are those the type of schemas you are talking about sending or not?
  471. stefandxm these are not
  472. stefandxm these are XML Schemas (xsd)
  473. stefandxm but if you chose to follow dtds then you may have problems
  474. moparisthebest what if I send a schema for, uh, MAM or something but that I maliciously changed, would that overwrite the correct MAM schema?
  475. stefandxm i guess that should be a topic yes
  476. stefandxm how to properly localize the namespace to the session
  477. moparisthebest and that might even be specific to XML libraries or whatever
  478. stefandxm or rather just not allow it to replace any existing schemas known to the client
  479. stefandxm and only use them for the session
  480. moparisthebest just might need to be considered
  481. stefandxm yes
  482. stefandxm very good suggestion
  483. stefandxm i shall fix
  484. moparisthebest I guess the only danger is if there is not a safe way to do this with any library or XML in general, then the design is inherently insecure and you can't be sending schemas around
  485. moparisthebest I would think there is a safe way but I just don't know at all
  486. stefandxm there is secure ways
  487. stefandxm tbh i never considered someone would do it an non-secure way
  488. stefandxm but i think it should be clarified
  489. stefandxm in any way this is a more secure way than following URIs
  490. stefandxm as long as the xmpp server is secured
  491. stefandxm and you only use the schema in the entity to entity session
  492. tux has left
  493. SamWhited has joined
  494. SamWhited has joined
  495. Wiktor has joined
  496. Tobias jonasw, you know about http://tools.medialab.sciences-po.fr/iwanthue/ ?
  497. jonasw Tobias, you linked that, yes
  498. Tobias ah..k :)
  499. daniel has left
  500. Ge0rG Yay, it looks like the psi and psi+ devs got resurrected and released a new version last month!
  501. stefandxm moparisthebest: ive added a note on it now
  502. moparisthebest Excellent :)
  503. stefandxm problem with xml schemas are basically the same as the xml itself. its vulnerable to parse it and its vulnerable not to use it hehe
  504. uc has left
  505. daniel has joined
  506. stefandxm another thing along these lines; ive been thinking about the maxOccours in the schemas
  507. stefandxm it would make sense to add a sensible max rather than having unbounded
  508. stefandxm esp in the requests
  509. jere has left
  510. jere has joined
  511. stefandxm this way its possible for the server to protect the receiver. but it also would mean that basically the clients should tell the server what namespaces they want to filter
  512. stefandxm today for instance ejabberd has a max stanza size but its impractical to have it statically defined
  513. stefandxm having it defined on say namespace level and client would be a solution
  514. stefandxm or namespace, entity (jid) and namespace
  515. dwd jonasw, That's weird. I was talking about the existence of this algorithm about an hour and a half before you submitted that.
  516. Ge0rG the coloring algorithm?
  517. Ge0rG It was discussed in here several times over the last months
  518. dwd Yes, I know.
  519. dwd I was demonstrating the difference between Gajim and another XMPP client, and Gajim colourizes - I mentioned there was this algorithm knocking about as well.
  520. Ge0rG I hope that the proto-XEP will ignite discussion. Hope dies last.
  521. Ge0rG I think that jonasw is aiming at a Ph.D. in sensible XMPP client design.
  522. stefandxm iam missing the [] Compensate for f.lux on the site
  523. jonasw stefandxm, compensating for flux/redshift is definitely out of scope ;-)
  524. jonasw (a) that’s time dependent and (b) tricky
  525. daniel has left
  526. Ge0rG I think that f.lux compensation should be done display-wide, not in an XMPP client.
  527. jonasw dwd, ha, so I can count on your +1 ;)
  528. Ge0rG Unless there is an XMPP client that can go back into 1955.
  529. stefandxm am i the only one finding it confusing to talk about IM UIs as "xmpp clients"? :)
  530. Ge0rG stefandxm: those are different things!
  531. mimi89999 has left
  532. Ge0rG Jabber client is the right term, of course.
  533. stefandxm i remember the discussion from the summit this spring. i still find it confusing to have a protocol organ for a message bus discussing/voting on UI matters
  534. jonasw re-instate the JSF to discuss IM-specific matters for maximum confusion!!!k
  535. emxp has joined
  536. mimi89999 has left
  537. stefandxm and i cannot see how the expertise can be shared between systems protocols and ui design
  538. stefandxm so far ivent met a single proffesional ui designer than can do system protocols and vice versa
  539. Guus has left
  540. Ge0rG stefandxm: which is a very pointed explanations of why all Jabber clients suck.
  541. stefandxm i think the clients can be good but not all uis
  542. stefandxm adium has a great ui but sucky xmpp client
  543. Ge0rG stefandxm: I'm not a professional UI designer, but I know a little bit about UX and I am pondering about jabber client design a great deal of time
  544. uc has joined
  545. daniel has joined
  546. Ge0rG jonasw: "Jabber Software Alliance" or "Business Jabber Alliance" or some such.
  547. stefandxm swift im has a horrid ui but a great xmpp client
  548. Ge0rG stefandxm: now you made me curious, what's wrong with swift?
  549. stefandxm it only supports one account and its ugly :)
  550. Zash Incorrect and subjective.
  551. stefandxm incorrect in what way?
  552. Zash It supports multiple accounts
  553. stefandxm oh?
  554. Zash Hidden away tho
  555. stefandxm how?
  556. stefandxm haha speaking of uis
  557. Zash Command line flag iirc
  558. Ge0rG stefandxm: I think that "ugly" is highly subjective and only a very small influence on the UX
  559. stefandxm it doesnt have a "help" either
  560. jonasw I’m confident that JabberCat will be awesome ;-)
  561. stefandxm georg, an ui that doesnt follow the native look will always be ugly in my book
  562. jonasw +1 stefandxm
  563. Ge0rG stefandxm: web is the new native.
  564. Zash stefandxm: no --help ? whats this then https://q.zash.se/f445feffd14b.txt
  565. stefandxm zash was talking about the ui
  566. jonasw Ge0rG, noooo
  567. Zash stefandxm: I think the goal is to be simple enough to not need a built in help
  568. Ge0rG my point is: the look of widgets is secondary to proper usability.
  569. stefandxm Number of accounts to open windows for (unsupported)
  570. stefandxm multiple windows?
  571. stefandxm not a shared contact list?
  572. jonasw Ge0rG, the look yes, but the feel not
  573. Ge0rG jonasw: true.
  574. Ge0rG But I'd rather have a Qt-based client on windows that doesn't drop messages than a native one that can't fulfil basic IM expectations
  575. jonasw Qt is close to native on any platform
  576. jonasw closer than any web client at least
  577. Zash jonasw: Always close, but always feeling slightly off
  578. jonasw Zash, but over the uncanny valley, I thnik
  579. daniel has left
  580. Zash As someone who grew up with GTK+, all Qt apps look off to me
  581. stefandxm on linux iam ok with Qt looking app. on osx its horrid
  582. Ge0rG stefandxm: I also think that multi-account support is a power user feature only needed by 1% of Zimpies.
  583. stefandxm georg, i dont think tahts true :)
  584. Wiktor has left
  585. Ge0rG stefandxm: but having support for multiple accounts makes the UI much more complex
  586. moparisthebest if you really need it you can always use a xmpp->xmpp transport right? :)
  587. stefandxm i dont know anyone that has only one im account
  588. jonasw Ge0rG, multi-account is tricky, but I think I found a reasonable UX solution for jabbercat
  589. stefandxm Ge0rG, sure. but adium does it neatly
  590. jonasw stefandxm, I know a lot, all my non-nerd friends
  591. daniel has joined
  592. lovetox has joined
  593. stefandxm jonasw, they dont have google etc?
  594. SouL What? I feel I'm a normie now, with just one XMPP account.
  595. jonasw stefandxm, google doesn’t have any usable XMPP anymore
  596. stefandxm i run google hangout, work jid, private jid and icq through one im client
  597. stefandxm jonasw, yes they do
  598. SouL All my gmail contacts appear as offline
  599. stefandxm not mine
  600. stefandxm i use it daily
  601. SouL How? Is still usable on the gmail page?
  602. Ge0rG SouL: gmail f***ed xmpp.
  603. stefandxm SouL, yes and with hangout app (included in android)
  604. Ge0rG stefandxm: you are the power user.
  605. SouL Whaat? That's new to me.
  606. stefandxm its been like this since ever
  607. SouL Your contacts had to do something, or what, stefandxm?
  608. stefandxm they never removed xmpp support
  609. jonasw SouL, don’t let yourself be fooled, gmail federation is broken-ish
  610. stefandxm SouL, no
  611. stefandxm federation is not working no
  612. Ge0rG I need a gmail-xmpp using volunteer please, for testing https://github.com/pfleidi/yaxim/issues/201
  613. stefandxm but its still xmpp and works great for chatting
  614. Zash I may have a multilple accounts, but I only use one, the rest are for testing and stuff.
  615. Zash Most of my friends only have one too.
  616. SouL Ah man, there's no federation... Then there's nothing new :)
  617. stefandxm Ge0rG, you may add me if you want. stefan@skogome.net
  618. Ge0rG stefandxm: is that gmail-hosted?
  619. stefandxm yes
  620. Ge0rG stefandxm: thanks, give me a minute to boot my other android.
  621. stefandxm but you need to be friends
  622. stefandxm so its traditional xmpp
  623. Ge0rG stefandxm: I don't have a mac unfortunately, so I can't check adium.
  624. stefandxm pidgin also works
  625. stefandxm i run pidgin on linux for same reasons as i run adium on mac
  626. Ge0rG but pidgin!
  627. stefandxm pidgin is great ui. but sucky xmpp client =)
  628. Ge0rG all xmpp clients suck. Especially the Jabber ones.
  629. Zash Which one(s) suck less?
  630. Ge0rG mutt. Oh, wait.
  631. stefandxm i havent been able to start swift im on linux
  632. stefandxm dependency hell
  633. jonasw Ge0rG, mutt with that french xmpp<->imap gateway?
  634. stefandxm (and it didnt compile)
  635. Ge0rG jonasw: I don't even want to imagine _that_.
  636. jonasw :D
  637. jonasw Ge0rG, heard of deltachat?
  638. jonasw .oO(deltachat in front of imap<->xmpp gateway :-O)
  639. Holger stefandxm: https://github.com/swift/swift/blob/master/BuildTools/InstallSwiftDependencies.sh
  640. Zash IMAP is pretty cool, why else would they be trying to kill and replace it with some JSON garbage?
  641. Holger ... works for me.
  642. jonasw for extra fun
  643. stefandxm Holger, i dont use any of those distros
  644. stefandxm so would give Unsupported system if i tried
  645. daniel has left
  646. stefandxm or wait, it had a || there
  647. jonasw I always find it odd when people who use interesting exotic distributions complain about difficulties building and installing software :)
  648. stefandxm it might work now then
  649. stefandxm but last time it didnt
  650. stefandxm jonasw, why?
  651. moparisthebest wait there is an imap/xmpp gateway?
  652. stefandxm jonasw, i think the more you know about linux the more problem you will have with dependencies
  653. Zash I must know nothing then.
  654. moparisthebest stefandxm, just curious, which distro?
  655. stefandxm linux mint kde on this one
  656. stefandxm quite horrible tbh
  657. moparisthebest that's just ubuntu with some extra repos pretty sure?
  658. stefandxm but i gave up on debian experimental after the third broken upgrade in a year >D
  659. stefandxm moparisthebest, true and not true
  660. moparisthebest oh, actualy, Holger 's script has a LinuxMint entry, same as Ubuntu
  661. stefandxm i know
  662. stefandxm i commentented on it above :)
  663. stefandxm but linux mint versions are not interchangeable
  664. stefandxm same as with debian of course
  665. Zash Isn't the purpose of Debian experimental to be horribly broken?
  666. tux +1
  667. stefandxm sure is
  668. stefandxm but only way to get updated packages
  669. tux has relatively good experience with debian unstable, if you know what you are doing
  670. moparisthebest yea, I used Kubuntu for about 10 years but 16.04 broke everything so bad I switched to Arch and have been rather happy with that for a year
  671. moparisthebest breaks less than debian unstable from what I gather, but still newest everything
  672. stefandxm tux, me too.. for a long while =)
  673. Ge0rG there are three flavors of debian: rusty, stale and broken.
  674. daniel has joined
  675. SouL Did you consider KDE Neon, moparisthebest?
  676. tux by the way: I just verified that a current PSI+ can be built with Debian Stable. I'll do a backport pacakge in the near future.
  677. jonasw tux, you’re a debian developer?
  678. moparisthebest SouL, ah KDE neon, I tried it and it was still a bit too broken, and that was before they discovered they didn't enable PGP package signing and also left their package repo open for anyone to upload files to... :)
  679. moparisthebest SouL, that would be https://www.kde.org/info/security/advisory-20161114-1.txt
  680. tux jonasw: nope, never really got around to do that, but I know how to build debian packages
  681. SouL moparisthebest, I downloaded it two months ago and it is what I'm using, since I was using Kubuntu too, before.
  682. moparisthebest did they start signing packages with PGP yet?
  683. moparisthebest otherwise I'd stay far away just for security reasons
  684. moparisthebest glad it works well now though, I tried around July 2016
  685. emxp has joined
  686. lovetox has left
  687. mimi89999 has left
  688. intosi has left
  689. intosi has joined
  690. Ge0rG Gmail is weird. it reflects my own presence to me.
  691. daniel has left
  692. daniel has joined
  693. Holger Isn't that standard behavior?
  694. Ge0rG Holger: I mean the presence of my own full JID, not of my other sessions
  695. tim@boese-ban.de has left
  696. Holger Ge0rG: "The user's server MUST also send the presence stanza to all of the user's available resources (including the resource that generated the presence notification in the first place)."
  697. Martin has left
  698. Holger Or am I missing something?
  699. Ge0rG Holger: whoops. Then it's just the first time I notice this. Thanks for clarifying
  700. nyco hey SCAM team members, we have a booth at the POSS, Paris Open Source Summit
  701. nyco http://www.opensourcesummit.paris/
  702. nyco the stand will be on V29
  703. nyco Guus, Daniel...
  704. nyco europeans, join!
  705. jjrh has left
  706. jjrh has left
  707. jonasw has left
  708. Holger has left
  709. jjrh has left
  710. Valerian has left
  711. Tobias has joined
  712. Flow has left
  713. tux Interesting, this afternoon I thought about how nowadays one must also take the hash colour into account when creating a nick name, then I thought about how to ensure that every colouring scheme is identical and now there is this: https://xmpp.org/extensions/inbox/colors.html
  714. tux Though I have mixed feelings about the color inversion - maybe have to try this out on a demonstrator.
  715. Flow has joined
  716. tux Or maybe the luminosity (Y) should be adapted instead.
  717. tux Is it customary to reply to the XMPP extension proposals?
  718. jonasw tux, sure, feel free
  719. jonasw adapting luminosity would be more a heuristic, mixing with the inverse does work, I have sapmles
  720. tux ack
  721. jonasw (esp. adapting Y doesn’t work for coloured backgrounds)
  722. tux I just felt more natural to do these conversions in the YCbCr colour space
  723. jonasw that’s quite tricky I’m afraid
  724. jonasw because YCbCr is not additive
  725. jonasw RGB is, which is why the inversion-and-mixing thing works
  726. tux true
  727. intosi has left
  728. intosi has joined
  729. tux jonasw: in 5.4 the formulas don't give values for KR and KB
  730. jonasw tux, no mixing: https://sotecware.net/files/persistent/colors-xep/unmixed-bg.svg mixing: https://sotecware.net/files/persistent/colors-xep/mixed-bg.svg
  731. stefandxm i am curious when this is wanted at all?
  732. stefandxm does people want nick name colorization in chats?
  733. jonasw stefandxm, yes, they do
  734. tux uses that feature
  735. jonasw and also for avatars its great
  736. Zash Are there any algorithms for identifying words with similar 'shape'?
  737. stefandxm wont it just be a huge christmas tree?
  738. tux jonasw: I see, thanks for the sample :)
  739. stefandxm i remember i tried it on irc back in the days and it was dreadful
  740. jonasw Zash, I doubt it
  741. jonasw stefandxm, the xep also specifies that there MUST be a switch to turn it off, so...
  742. moparisthebest stefandxm, well persistence and standardization would help, all my clients color nicks, but differently across clients and even in the same chat, sometimes
  743. jonasw tux, you can mention the missing constants on-list
  744. tux stefandxm: Setting a good luminosity is key.
  745. jonasw they’re easy to find anywhere on the internet though
  746. tux jonasw: ack
  747. Zash stefandxm: looks fine to me: https://www.zash.se/upload/28QwkNpsRR5s.png
  748. stefandxm thats horrible to me :)
  749. tux maybe, but in a "we want to ensure everybody does the same thing" specification they should be mentioned.
  750. stefandxm because when you apply highlights and notifications they get drowned our have to be even more shouty (as in your example)
  751. moparisthebest so yesterday, to avoid highlighting them needlessly I'll change the name, gajim set both Buus and Be0rG to the same color and on glance I was confusing them
  752. jjrh has left
  753. jjrh has left
  754. jonasw moparisthebest, with XEP-XXXX, you can at least be sure that it will always happen, if it happens ;)
  755. SamWhited has left
  756. jonasw doesn’t happen though, they have very different xorred crc32 values
  757. jjrh has left
  758. tux has left
  759. jjrh has left
  760. jjrh has left
  761. jjrh has left
  762. Martin has joined
  763. fp-tester has left
  764. fp-tester has joined
  765. tim@boese-ban.de has joined
  766. moparisthebest jonasw, that might be interesting, have sample color lists for say, this muc?
  767. moparisthebest or maybe #archlinux on freenode, some concrete real-life examples
  768. jonasw moparisthebest, can do
  769. jonasw may do soon
  770. jonasw I have it implemented for avatar surrogates in my client, but I obviously can’t easily show you a screenshot of my roster ...
  771. Ge0rG We really need some easy-to-setup test account with fake roster entries and fake presence.
  772. jonasw has left
  773. tux The discussion on whether there should be nick coloring is not really relevant, though. The thing is happening and the best reaction is IMHO to give it a good direction early on. (As with the proposed XEP.)
  774. moparisthebest also I'm a little colorblind so I hesitate to comment on actual colors, but I'll be able to tell if they look different enough for me, and others can look as well
  775. tux The decision is only if there should be a common scheme or if things just go wild.
  776. moparisthebest well, things are going wild right now
  777. jonasw moparisthebest, uuuuh
  778. moparisthebest this optionally adds a common scheme :)
  779. jonasw if you’d be willing to see how the color blind profiles work, let me know
  780. jonasw if you’d be willing to see how well the color blind profiles work, let me know
  781. jonasw until now I only have one sample (with a red/green blind person)
  782. moparisthebest sure jonasw , I'm not sure what I have is exactly called, but I see like, certain browns as army green, not positive
  783. jonasw that could be a light red/green defiency
  784. jonasw we should talk later, I’ll be off for half an our or something
  785. moparisthebest yep, I looked up the exact word one day but have forgotten :)
  786. stefandxm has left
  787. stefandxm has joined
  788. jubalh has left
  789. Tobias has left
  790. tim@boese-ban.de has joined
  791. Tobias has joined
  792. jere has joined
  793. xnyhps has joined
  794. xnyhps has left
  795. goffi has left
  796. Lance has joined
  797. jere has joined
  798. xnyhps has left
  799. Guus has left
  800. Steve Kille has left
  801. jere has left
  802. jere has joined
  803. Guus has joined
  804. Lance has left
  805. Guus has left
  806. Guus has joined
  807. Martin has left
  808. waqas has joined
  809. Steve Kille has joined
  810. jonasw back
  811. Vaulor has joined
  812. ralphm has left
  813. lumi has joined
  814. moparisthebest has joined
  815. lovetox has joined
  816. Guus has left
  817. lumi has joined
  818. waqas has left
  819. Guus has joined
  820. stefandxm has left
  821. valo has left
  822. Steve Kille has left
  823. efrit has joined
  824. stefandxm has joined
  825. emxp has joined
  826. Tobias has joined
  827. ralphm has joined
  828. tim@boese-ban.de has left
  829. tim@boese-ban.de has left
  830. jonasw moparisthebest, https://sotecware.net/files/noindex/users.svg
  831. tim@boese-ban.de has joined
  832. Guus has left
  833. Guus has joined
  834. jonasw moparisthebest, refreshed with three color columns, which are: plain, red/green-blindness corrected, blue-blindness corrected
  835. pep. I'm blue/purple-ish!
  836. pep. jonasw, how many colors is this?
  837. mimi89999 jonasw: I don't get that thing...
  838. pep. jonasw, why do you care for color-blindness? It's just to quickly identify people right? you don't care if color-blind people don't see the same color as others?
  839. pep. It's not like people were going to compare colors
  840. pep. Or am I missing something?
  841. waqas has joined
  842. intosi Colour rotating nickname sets, that will be a thing.
  843. mimi89999 intosi: 👍
  844. Tobias has joined
  845. Yagiza has left
  846. stefandxm has left
  847. intosi has left
  848. tim@boese-ban.de has joined
  849. jonasw pep., the issue is that the deficiencies affect different ranges of the color space differently, so we can do better by avoiding those ranges
  850. jonasw pep., I don’t understand the question "how many colors"
  851. jonasw it’s as many colors as there are names
  852. jonasw up to 2^16 (due to folding crc32 into an unsigned 16 bit integer)
  853. pep. ok
  854. Guus has left
  855. Guus has joined
  856. edhelas has left
  857. nyco has left
  858. valo has joined
  859. jonasw mimi89999, what’s your question?
  860. mimi89999 jonasw: What is that svg about?
  861. jjrh has left
  862. jonasw mimi89999, it shows the colors the ProtoXEP which was announced on standards@ generates for the nicknames in this room
  863. jonasw in three variants, from left to right: "normal", "corrected for red/green-deficiency", "corrected for blue-deficiency"
  864. efrit has left
  865. efrit has joined
  866. ralphm has joined
  867. efrit has left
  868. efrit has joined
  869. fp-tester has left
  870. fp-tester has joined
  871. efrit has left
  872. efrit has joined
  873. emxp has joined
  874. Guus has left
  875. Guus has joined
  876. efrit has left
  877. efrit has joined
  878. jonasw Ge0rG, I agree. I already thought about how to set that up. maybe some prosody docker image with pre-configured accounts
  879. jonasw I have a testbed, but it’s rather small, not large enough to effectively test the coloring things
  880. tux How about scraping sth like Twitter for a nickname set?
  881. SouL Aren't there libraries like faker for python? For stuff like that
  882. moparisthebest jonasw, thanks so, those columns, and again, I don't know if I'm seeing what you are seeing
  883. jonasw SouL, you still need to set up accounts etc.
  884. moparisthebest the middle column, is mostly pink/orange
  885. jonasw and add clients
  886. moparisthebest jonasw, you, kev, la|r|ma have *identical* orange colors, in the middle column
  887. goffi has joined
  888. moparisthebest is that what you see or no
  889. jonasw yes, that’s in all columns the case
  890. moparisthebest oh, right
  891. jonasw doesn’t matter that much really
  892. moparisthebest the middle seems the worst to me though, almost everyone is pink
  893. jonasw moparisthebest, interesting, and possibly bad
  894. moparisthebest is that what you see or not? :)
  895. jonasw yes-ish
  896. jonasw there are some oranges in there
  897. moparisthebest it's subtely different shades of pink, but, mostly pink
  898. jonasw moparisthebest, reload
  899. moparisthebest maybe better, I was going to say all shades of green, but that's mostly at top
  900. moparisthebest no actually I think that is far better
  901. Guus has left
  902. jonasw I think too
  903. moparisthebest again just for my eyes might be worse for everyone else who knows
  904. jonasw no, I think that makes sense
  905. jonasw in case of doubt is green easier on the eyes compared to pink
  906. jonasw simply because one is evolutionary more used to green tones and we can distinguish more shades of green
  907. moparisthebest above my head, seems to make sense though
  908. Guus has joined
  909. moparisthebest out of those 3 profiles I prefer middle for sure, I preferred left before
  910. jonasw moparisthebest, prefer it visually, or from being able to distinguish colors?
  911. moparisthebest seems more distinguishable yes
  912. jonasw moparisthebest, great :-)
  913. jonasw \o/
  914. moparisthebest the left has a bunch of 2 or 3 in a row of almost identical shades
  915. jonasw can you reload once more?
  916. moparisthebest more blue-ish than green-ish ?
  917. jonasw maybe, not sure
  918. Steve Kille has left
  919. jonasw anyways, thanks for your input
  920. moparisthebest Bunneh, and next two, I hate highlighting random people
  921. moparisthebest the green sticks out more there, to me
  922. jonasw more than the shades on the left?
  923. moparisthebest no not in that case
  924. daniel has left
  925. moparisthebest it does seem to have groups of the same color in a row, like groups of 2 and sometimes 3
  926. moparisthebest for alphabetical names that's bad, not sure if there is a solution though
  927. jonasw moparisthebest, I thnik that may be a property of CRC32 :/
  928. daniel has joined
  929. moparisthebest jonasw, what if you used something else, md5, Adler-32, Fletcher-32 ?
  930. Flow has left
  931. jonasw adler32 is worse on those short inputs
  932. jonasw (tried it)
  933. jjrh has left
  934. jonasw 18:43:19 jonasw> crytographic hash functinos are generally a bit better 18:44:36 jonasw> but people complain that those are hard to implement / have high overhead 18:44:50 jonasw> and even in those cases there are still close nicknames which aren’t ideal
  935. tim@boese-ban.de has left
  936. jjrh has left
  937. daniel has left
  938. daniel has joined
  939. jonasw ahh, salting the CRC32 with 256 bits does something good
  940. jonasw moparisthebest, care to reload?
  941. moparisthebest I'm not sure md5 is hard or has high overhead :/
  942. moparisthebest yea hang on
  943. moparisthebest I think that's worse, look at tu-x and next 3
  944. moparisthebest next 2 I mean, also it still has the every few being the same
  945. Zash That graph says otherwise ;)
  946. jonasw moparisthebest, I don’t think that’s a bad thing in that special case. they differ by their first letter, so your brain generally can distinguish them well
  947. jonasw moparisthebest, re performance: https://sotecware.net/images/dont-puush-me/9n701UwrIuU2NFuTexy7rFpu3Auf7zbQlVsEyFTVqAM.png
  948. jonasw so md5/sha1 are an order of magnitude slower than CRC32 on those input sizes
  949. moparisthebest are we talking about the difference in 0.01s and 0.02s for all participants in a typically sized muc ?
  950. moparisthebest because, who cares
  951. jonasw moparisthebest, first, implementations may not always be able to cache the colors (daniel brought that up)
  952. moparisthebest I think it might even be less than that?
  953. jonasw it’s a factor of three in that region
  954. jonasw lowering slowly to 2.5 at the right edge of the reasonable range for nicknames and such
  955. jjrh has left
  956. moparisthebest 3 times slower than a millionth of a second?
  957. Guus Link Mauve, you here?
  958. daniel Well maybe we should try md5. If it looks better we might want to live with it
  959. jonasw daniel, it does, but salting CRC32 with 64 bytes does the trick
  960. jonasw and is still fast
  961. Vaulor has left
  962. moparisthebest unless I'm reading the graph wrong, 3/1,000,000s is technically 3x slower than 1/1,000,000s, but still well within the no one cares range
  963. jonasw moparisthebest, reload for md5-based colors
  964. jonasw I don’t think it does a lot of good
  965. moparisthebest hmm disappointing I agree it's basically the same issue
  966. moparisthebest sha1 doesn't do better either?
  967. moparisthebest is it not fixable based on low bytecount or can we just throw algorithms at it until one sticks :)
  968. jonasw moparisthebest, I think it’s not fixable due to the low amount of colours we can distinguish
  969. jonasw but indeed, we need to specify a salt input for CRC32, that improves things massively
  970. ralphm has joined
  971. lumi has joined
  972. lumi has joined
  973. Valerian has joined
  974. pep. has joined
  975. Valerian has left
  976. stefandxm has joined
  977. waqas has left
  978. goffi has left
  979. ralphm has joined
  980. jubalh has joined
  981. waqas has joined
  982. mimi89999 has joined
  983. lovetox has left
  984. daniel has left
  985. daniel has joined
  986. tim@boese-ban.de has joined
  987. jere has joined
  988. jere has joined
  989. jonasw has left
  990. uc has joined
  991. jonasw has left
  992. Guus has left
  993. Zash has left
  994. SamWhited has left
  995. ralphm has joined
  996. Guus has left
  997. Guus has left
  998. daniel has left
  999. daniel has joined
  1000. Tobias has joined
  1001. jere has joined
  1002. jere has joined
  1003. pep. has left
  1004. blabla has left
  1005. jjrh has left
  1006. jjrh has left
  1007. fp-tester has left
  1008. fp-tester has joined
  1009. mimi89999 has joined
  1010. efrit has left
  1011. blabla has joined
  1012. jjrh has left
  1013. jjrh has left
  1014. moparisthebest has joined
  1015. la|r|ma has left
  1016. pep. has joined
  1017. fp-tester has left
  1018. Alex has left
  1019. tim@boese-ban.de has joined
  1020. daniel has left
  1021. ralphm has joined
  1022. tim@boese-ban.de has joined
  1023. jjrh has left
  1024. jjrh has left
  1025. ralphm has joined
  1026. pep. has joined
  1027. sonny has left
  1028. sonny has joined
  1029. lskdjf has joined
  1030. tux jonasw: is there a reason you're using crc instead of sha?
  1031. tux Ah, nvw. Just read your answer to the question.
  1032. tux Though I think that the processing time is not relevant here.
  1033. emxp has joined
  1034. Guus has left
  1035. uc has joined
  1036. jjrh has left
  1037. uc has joined
  1038. moparisthebest tux: I don't think processing speed matters either here but md5 also wasn't any better so :(
  1039. jjrh has left
  1040. jjrh has left
  1041. jjrh has left
  1042. jubalh has joined
  1043. jubalh has left
  1044. jubalh has joined
  1045. waqas has left
  1046. jjrh has left
  1047. Tobias has joined
  1048. Link Mauve Guus, now I am.
  1049. jjrh has left
  1050. lskdjf has left
  1051. lskdjf has left
  1052. jere has left
  1053. jere has joined
  1054. waqas has joined
  1055. pep. has left
  1056. la|r|ma has joined
  1057. jere has left
  1058. jere has joined
  1059. nyco has left
  1060. lumi has joined