07:55:50 RRSAgent has joined #dap 07:55:50 logging to http://www.w3.org/2016/09/19-dap-irc 07:55:52 RRSAgent, make logs world 07:55:52 Zakim has joined #dap 07:55:54 Zakim, this will be DAP 07:55:54 ok, trackbot 07:55:55 Meeting: Device and Sensors Working Group Teleconference 07:55:55 Date: 19 September 2016 07:59:26 Tomoyuki has joined #dap 08:00:16 Present+ Anssi_Kostiainen 08:01:39 kotakagi has joined #dap 08:03:28 Hiroki_ has joined #dap 08:06:41 tomoyuki has joined #dap 08:08:43 kenneth_ has joined #dap 08:08:57 Hi! 08:09:09 bigscreen has joined #dap 08:09:19 kaorumaeda has joined #dap 08:09:29 Maryammjd has joined #dap 08:10:24 zkis has joined #dap 08:12:28 Gloria has joined #dap 08:13:47 TOPIC: Introductions 08:13:53 Dom: staff contact for DASWG, also for the WebRTC WG 08:14:09 present+ Zoltan_Kis 08:14:43 present+ Kenneth_Christiansen 08:15:01 Present+ Dominique_Hazael-Massieux 08:15:49 present+ Mikhail_Pozdnyakov 08:15:55 present+ Alexander Shalamov 08:16:12 Present+ Tomoyuki_Shimizu 08:16:18 s/present+ Alexander Shalamov/present+ Alexander_Shalamov 08:16:21 riju has joined #dap 08:16:40 Present+ Dong Ji (Gloria) 08:16:45 present+ Koichi Takagi 08:17:43 Works at Intel, worked on web platform since around 2006. Growing interest around IoT and sensors on mobile devices makes one standardized API more important, which is why I am here 08:18:39 present + Maryam Mehrnezhad, from Newcastle University, UK, interested in security and privacy issues 08:18:58 Present+ Hiroki Endo 08:19:09 present+ Kaoru_Maeda 08:19:28 Anssi Kostiainen from Intel, spec editor (sensors recently) and acting chair for this meeting, other interests e.g. Second Screen, WebVR 08:21:54 present+ Rijubrata_Bhaumik 08:21:57 present Maryam_Mehrnezhad 08:22:01 s/Koichi Takagi/Koichi_Takagi/ 08:22:26 present+ Maryam_Mehrnezhad 08:22:30 Zakim, who's here? 08:22:30 Present: Anssi_Kostiainen, Zoltan_Kis, Kenneth_Christiansen, Dominique_Hazael-Massieux, Mikhail_Pozdnyakov, Alexander, Shalamov, Tomoyuki_Shimizu, Dong, Ji, (Gloria), Koichi, 08:22:33 ... Takagi, Hiroki, Endo, Kaoru_Maeda, Rijubrata_Bhaumik, Maryam_Mehrnezhad 08:22:33 On IRC I see riju, Gloria, zkis, Maryammjd, kaorumaeda, bigscreen, kenneth_, tomoyuki, Hiroki_, kotakagi, Zakim, RRSAgent, anssik, shalamov, dom, mikhail, tobie, Josh_Soref, 08:22:34 ... mounir, Mek, trackbot 08:23:25 Present- Alexander 08:23:28 Alexander Shalamov from Intel, implementing sensors based on Generic Sensor API specification for chromium 08:23:28 Present- Shalamov 08:23:35 Present+ Alexander_Shalamov 08:23:39 Zakim, who's here? 08:23:39 Present: Anssi_Kostiainen, Zoltan_Kis, Kenneth_Christiansen, Dominique_Hazael-Massieux, Mikhail_Pozdnyakov, Tomoyuki_Shimizu, Dong, Ji, (Gloria), Koichi, Takagi, Hiroki, Endo, 08:23:41 Zoltan Kis @ Intel, I design/implement node-style IoT Web APIs for constrained runtimes. Interested in API consolidation with browser APIs. Also, editor for Web NFC, member of Web Bluetooth and Web of Things. 08:23:42 ... Kaoru_Maeda, Rijubrata_Bhaumik, Maryam_Mehrnezhad, Alexander_Shalamov 08:23:43 On IRC I see riju, Gloria, zkis, Maryammjd, kaorumaeda, bigscreen, kenneth_, tomoyuki, Hiroki_, kotakagi, Zakim, RRSAgent, anssik, shalamov, dom, mikhail, tobie, Josh_Soref, 08:23:43 ... mounir, Mek, trackbot 08:25:11 s/Hiroki Endo/Hiroki_Endo/ 08:25:26 Present+ Ningxin_Hu 08:26:19 Ningxin: introduction, working for Intel, from Shanghai, working on Crosswalk Project, Depth Camera, interested in SIMD.js 08:27:48 ScribeNick: dom 08:27:53 Topic: Agenda review 08:27:57 Anssi: Today, generic sensors 08:28:07 ... tomorrow, looking at concrete sensors 08:28:10 ... with demos of implementations 08:28:34 ... Concrete sensors come with specific needs on privacy & security for instance 08:30:12 ... tomorrow afternoon will look at the other deliverables of the group, vibration API 08:30:34 ... with possible new needs for vibration around VR 08:30:51 ... Then battery status, currently in CR (back from PR due to privacy concerns) 08:31:21 ... finally wake lock — we can look at the TAG feedback 08:31:55 ... and we'll finish with joint meetings with WoT IG, possibly Geo 08:32:48 ... the Geo WG is not meeting this week; they have been working on the Geolocation API and the Device Orientation API 08:33:06 ... the latter is a high level sensor fusing together gyroscope, accelerometer, and magnetometer 08:33:37 ... We took the approach of decomposing this in lower level APIs, which is required for advanced use cases in VR or AR 08:33:42 Kenneth: or even regular games 08:34:01 Anssi: the Web Platform has historically exposed high level APIs as it is often easier from a privacy & security perspective 08:34:09 ... but it has also limitations 08:34:19 ... there is a whole spectrum of options among the two extremes 08:34:54 Kenneth: also, high level sensors are harder to get right from an interop perspective as show in device orientation 08:35:03 Anssi: I think it's a matter of finding the common ground 08:35:19 ... if you go too low, the API ergonomics can be difficult 08:35:39 ... From KDDI, what's your perspective on the level of abstraction on the GPIO API? 08:36:24 Zlotan: from a constrained environment perspective, I have had to adapt the API a bit 08:36:39 Koichi Takagi@KDDI/CHIRIMEN Open Hardware Community, investigating low level APIs such as WebGPIO, WebI2C and so on. The software (and hardware) was released as open source last April on https://chirimen.org/ . Please review the API on https://github.com/browserobo/ 08:37:03 Riju: Android will preview dynamic sensors with a connected / disconnected state 08:37:18 Maryam: what do we consider as a sensor and what we don't? 08:37:31 ... e.g. camera / mike aren't considered as sensor in this group 08:38:04 Anssi: very good question; there is one definition in the generic sensor document 08:38:10 definition of a sensor: https://w3c.github.io/sensors/#concepts 08:39:10 Maryam: currently, sensors like accelerometer are categorized very differently 08:40:41 Anssi: the camera API is clearly different, partly for historical reasons since it predates the sensor framework 08:41:16 Dom: the camera API has shown needs for higher level API, both for ergonomics & security policy 08:41:46 Maryam: still, it's confusing that there is no clear hierarchy or common models for sensors, especially as the platforms nowadays associate more and more sensors 08:41:59 ... e.g. the Android sensor hub associates camera with other sensors 08:42:33 Kenneth: right now, our approach has been to advance pragramatically with what can be easily exposed and what can be achieved more quickly 08:43:23 https://arxiv.org/pdf/1605.05549v1.pdf 08:43:43 Riju: the boundary for the generic sensor is Micro-electric-mechanical sensors per the spec 08:43:49 https://en.wikipedia.org/wiki/Microelectromechanical_systems 08:44:36 Maryam: the Generic Sensor API covers a lot of the movement sensors 08:45:02 ... see last page of https://arxiv.org/pdf/1605.05549v1.pdf showing the type of sensors available in mobile devices today 08:45:22 Kenneth: a lot of these sensors would fit there (temperature, barometer) 08:45:33 ... others like bluetooth or fingerprint seems very different 08:47:21 guys have a look for an intro to generic Sensors : https://01.org/chromium/blogs/riju/2016/generic-sensor-api-javascript-powered-platforms 08:50:52 zakim, who's here? 08:50:52 Present: Anssi_Kostiainen, Zoltan_Kis, Kenneth_Christiansen, Dominique_Hazael-Massieux, Mikhail_Pozdnyakov, Tomoyuki_Shimizu, Dong, Ji, (Gloria), Koichi, Takagi, Hiroki, Endo, 08:50:55 ... Kaoru_Maeda, Rijubrata_Bhaumik, Maryam_Mehrnezhad, Alexander_Shalamov, Ningxin_Hu 08:50:55 On IRC I see riju, Gloria, zkis, Maryammjd, kaorumaeda, bigscreen, kenneth_, tomoyuki, Hiroki_, kotakagi, Zakim, RRSAgent, anssik, shalamov, dom, mikhail, tobie, Josh_Soref, 08:50:55 ... mounir, Mek, trackbot 08:52:27 -> https://www.w3.org/2009/dap/ Device & Sensors WG home page 08:53:32 Kenneth: there is something weird about the naming of specs - in some case we name the thing measured, some time the things that is measuring 08:53:41 Present+ Tobie_Langel 08:55:09 Anssi: [introducing Tobie] 08:55:11 ningxinhu has joined #dap 08:56:35 Tobie: some of the long term issues brought up by the TAG (e.g. exposing sensors in workers) will likely need time 08:56:40 ... also permission management 09:00:17 Tobie: I created 3 buckets for the issues so that we can ship a first version of the API at some point 09:00:49 ... not sure at this point if we want a distinct level 1 / 2 or merge them 09:00:55 ... esp in light of TAG feedback 09:01:05 ... combined with implementors feedback 09:03:29 Dom: the guiding principle is that we need to find a consistent set of features that will ship in 2 or more browsers 09:03:49 Anssi: let's look at a reasonable l1 + l2 scope 09:04:23 Tobie: the TAG feedback that having this in the main thread will be a massive blocker from a performance perspective 09:05:10 i/Tobie: some/Topic: Generic Sensor 09:06:13 -> https://github.com/w3ctag/spec-reviews/110 TAG feedback on Generic Sensor API 09:07:02 https://github.com/w3ctag/spec-reviews/issues/115 09:07:15 s/110/issues\/110/ 09:08:03 maryammjd has joined #dap 09:08:11 -> https://github.com/w3ctag/spec-reviews/issues/115 Feedback on Ambient Light Sensor API 09:09:05 -> https://github.com/w3ctag/spec-reviews/issues/115#issuecomment-236365671 Alex' feedback on jank & sensor sampling 09:09:32 Tobie: we wouldn't want this potential performance issue to block shipping 09:09:53 Anssi: so exposing this to Worker seems more urgent based on that feedback 09:10:08 Tobie: but workers have a more complex permission-ing problem 09:10:54 Riju: from a performance perspective, the sensor is done in another thread 09:11:37 Kenneth: but the problem is not for implementations, but for developers doing lots of sensors, the risk is to make Web app slow 09:12:21 Yves has joined #dap 09:12:28 present+ 09:12:33 Riju: the problem is combining workers and permissions 09:12:58 Tobie: push uses permissions in service workers 09:13:14 ... I think we need to look back at this and see how hard the problem space is 09:13:44 Riju: note that sensors only react when the page is visible 09:13:50 ... not sure how that work with workers 09:17:26 Dom: it seems to me that sensors provide lots of data with possible lots of computation needed on it 09:17:42 ... some at least in mid-term, having that done in workers seems like the right thing 09:17:50 ... but yeah, the permission story might be difficult 09:18:09 ... also, we need to distinguish normal worker vs a service worker which enables background processing 09:19:07 Anssi: we have issues #106/73 for background service worker, and issue #12 for worker/shared worker 09:20:32 ... it seems like providing sensors in a worker is an easier problem than exposing it in service worker 09:20:40 https://github.com/w3c/sensors/issues/12 09:21:17 Zlotan: the spec says its agnostic about fusion or low level api sensor 09:21:30 ... do you distinguish between remote or bluetooth-connected device vs wired devices? 09:21:42 Tobie: we've punted on this; we only consider "on-device" sensors 09:21:55 ... but that will likely need to be widened 09:22:24 ... this also depends on where Web Bluetooth goes 09:22:35 ... or automotive or WoT IG 09:22:48 ... hard distinction to make between a sensor vs a server 09:23:24 Zlotan: the transport is not necessarily as important as the privacy/security difference among sensors 09:23:37 Tobie: there is a big difference depending on whether this is handled by the OS vs the browser 09:24:12 Zlotan: but I think that aspect should be mentioned in the spec 09:24:18 Tobie: I think I have something there 09:24:28 Zlotan: it says "remote sensors are out of scope" 09:25:15 Tobie: some things make sense for a local sensor (e.g. sampling frequency), less so for a mile-away remote sensor 09:25:38 Kenneth: it's great to have it in workers, but it should not be workers-only 09:25:57 ... e.g. in cases where the UI is mostly based on sensor input 09:26:12 ... like a compas or a game 09:26:17 s/compas/compass/ 09:27:08 Kenneth: Maybe we need a SensorWorklet 09:28:08 Anssi: so the main take away from the TAG review is worker & permission 09:29:08 Tobie: on frequency, you should cap, not fail 09:29:34 Kenneth: OK, so there is a bug in the chromium impl which currently fails without giving you info 09:30:22 Tobie: Android & iOS don't provide direct info on available frequencies; we could ask the UA to do it, but that seems costly for something that dev can do on their own with timestamp 09:31:25 ... The main reason to go higher than the display rate is to lower the latency for display 09:32:14 ... e.g. for VR 09:34:19 Kenneth: what happens if the execution time of processing an event is greater than the frequency of sensor reading? 09:34:28 Tobie: can't remember if we have something for this, but we might 09:35:01 https://w3c.github.io/sensors/#sensor-reading-timestamp 09:35:01 Dom: do we have a clear mapping between the TAG feedback and our spec issue list? 09:35:08 Tobie: not yet, it's on my near-feature TODO list 09:37:09 Dom: it sounds like we might need to enable different back-pressure mechanisms 10:04:58 kaorumaeda has joined #dap 10:08:03 anssik has changed the topic to: F2F agendahttps://www.w3.org/2009/dap/wiki/LisbonF2F2016#Agenda 10:08:27 Hiroki has joined #dap 10:08:35 i/Koichi Takagi/Koichi_Takagi 10:10:13 present- Hiroki Endo 10:10:22 preesnt+ Hiroki_Endo 10:10:33 zkis has joined #dap 10:10:42 present+ Tobie Langel 10:10:50 rrsagent, generate minutes 10:10:50 I have made the request to generate http://www.w3.org/2016/09/19-dap-minutes.html kaorumaeda 10:12:27 tomoyuki has joined #dap 10:13:43 Scribe: zkis 10:14:26 Topic: Generic Sensor API issues 10:14:29 Anssi: topic: looking at open issues; we want to merge level 1 and 2 10:14:29 Kazuo_Panasonic has joined #dap 10:15:05 Anssi: feasibility is important 10:15:55 Anssi: let us cherry-pick key issues for group discussion 10:16:25 https://github.com/w3c/sensors/issues/125 10:16:27 hwlee has joined #dap 10:16:32 ... level 1 things: #125 10:18:02 Tobie: #125 is basically resolved; 10:18:14 Riju: it is related to #126 10:18:24 maryammjd has joined #dap 10:19:19 Tobie: what "resolved" means: we know what to do about the issue, it will be fixed soon 10:20:39 https://github.com/w3c/sensors/issues/103 10:21:03 Tobie: where the data should be: on sensor object or through the event 10:21:35 ... should the event tell you that smth changed on the object, or hold the new data 10:21:43 ... both have different issues and benefits 10:21:58 ... so far we have both on the object and on the event 10:23:01 Zoltan: what about different data representations 10:23:14 Tobie: we have different objects for different data representations 10:23:43 Dom: why did we need it on the event at all 10:24:04 Anssi: let's take the ambient light sensor for example 10:24:21 ... it is stored on the object 10:25:31 Tobie: we'll handle representations from constructors init 10:26:00 ... where you show the payload depends on how it works with cached data vs one-shot events 10:26:24 ... on the object you have a timestamp 10:26:34 ... question: how do we cache a reading 10:26:45 ... this needs more thinking 10:27:10 Anssi: can we layer this on top of the existing API 10:27:51 Tobie: not sue at this point; if we add it somewhere we can't remove it later; 10:27:58 s/sue/sure 10:28:21 Tobie: simple events make it easier to spec 10:28:44 ... we also want to make sure this is the right thing 10:28:56 ... avoid developers make wrong assumptions 10:29:23 Kenneth: it's nice to be able to ask for latest data 10:29:36 ... so expose it on the other object 10:29:44 Tobie: privacy concerns with that? 10:29:58 anssik has changed the topic to: F2F agenda: https://www.w3.org/2009/dap/wiki/LisbonF2F2016#Agenda 10:30:13 Dom: why this would create different privacy? 10:30:25 Tobie, Maryam: cross-context issues 10:31:50 Tobie draws: the problem with one-shot method: we had it on the constructor, not the instance. With start() method this is no longer a problem. 10:35:03 Riju: I like the event model more 10:35:38 ... for current sensors we don't have the use case of reading once 10:36:14 Tobie: sending events is much cheaper when we use simple events 10:37:44 ... there are race conditions when we expose data through events 10:38:04 Dom: use the simpler version and see if it works 10:38:16 Kenneth: this is also more consistent across multiple sensors 10:39:33 Riju: suppose we have 2 JS objects with 2 different frequencies; if we use readings in the sensors, then we use the higher frequency; if we do events, we can expose the reading at lower AND higher frequency 10:41:01 Kenneth: 2 different callbacks with different frequencies... 10:41:09 Tobie: that is a different question 10:41:29 Tobie: events will come at the highest frequency 10:42:43 ... setting a frequency is a hint for a minimum and it is not guaranteed 10:43:36 Zoltan: can you set a maximum frequency? 10:43:44 Tobie: no, what is the use case 10:43:48 Dom: battery 10:44:14 Tobie: both are listening, so not an issue 10:44:27 ... same model is used by Android and iOS 10:45:22 ... we could imagine that each object gets at their own frequency, but that creates weird things when frequencies don't match 10:45:41 ... this is a simpler model and works better in most cases 10:46:14 ... for high performance scenarios this is not going to be used anyway, they will use direct readings 10:47:32 Anssi: so on #103 we should remove now before it becomes hard, because implementations using it 10:49:21 Tobie: sensor.reading is valuable for many use cases and has benefits of not having to fire events 10:49:36 ... the right thing is to remove the payload in the event 10:49:46 ... and add back if really needed in the future 10:52:04 Anssi: Rick's feedback: devs want to do stuff with event, to encapsulate all things to be done 10:52:14 ... this comes from Node context 10:52:25 ... so we don't want to shut these use cases out 10:55:28 ... but also think about garbage collection 10:56:02 mats has joined #dap 10:58:19 Tobie: what is the memory footprint penalty of attaching objects to events? 10:59:11 Ningxin: the GC references build-up is a problem 11:00:05 ... depending on implementation and JS engine, there could be problems with buffering events etc 11:02:26 Tobie: we should remove now and think later 11:02:57 ... before devs use it in applications 11:04:46 PROPOSED RESOLUTION: remove event payload from SensorReadingEvent 11:05:48 no concerns? 11:05:57 RESOLUTION: remove event payload from SensorReadingEvent 11:06:51 https://github.com/w3c/sensors/issues/101 11:07:58 Tobie: defer this until solved in the DOM 11:10:08 https://github.com/w3c/sensors/issues/42 11:13:07 Tobie: tending to say no to high level fusion, see issue discussion 11:16:42 ... not sure how we want to do this 11:17:47 ... issue discussion to be continued 11:18:22 https://github.com/w3c/sensors/issues/22 11:19:04 Tobie: WebIDL should fix this 11:19:20 ... keeping all permissions in one spec is idealistic 11:21:07 Zoltan: opinions in the issue are that it's still the least complex, and PR's are cheap 11:21:46 Riju: permissions mentioned in the each sensor instance spec 11:22:15 ... but with fusion is it the sum of parts? 11:22:41 Zoltan: you'll likely need a new permission for the fusion sensor (i.e. not sum of parts) 11:22:56 Tobie: let's rather have "give me permission to all the things I want" 11:23:17 ... combine permissions easily by the User Agent 11:23:46 ... popups are a bad idea 11:24:06 Anssi: present "undo" options 11:24:30 ... so asking forgiveness, not permission 11:24:53 ... one size does not fit all 11:25:32 Tobie: how to spec this; the permission spec asks for a name; let's switch that to a namespace rather than a name 11:26:02 ... if the end use is the same, does it make sense to ask separate permissions for everything separately? 11:26:10 s/use/user 11:27:08 Maryam: research show users give access easier for some sensors than for others 11:28:16 Tobie: the question is, how to group permissions together and call it one thing (implementors can already do that); as a UA binding permissions together is possible; 11:28:56 ... should we call all separate permissions under a name like "motion" 11:29:04 ... or should they be separated 11:29:12 Kenneth: they should be separated 11:29:20 *People undrestand some sensors better than others (based on the names e.g. orientation and motion vs acc and gyre) 11:29:23 Anssi: the platform will do the mapping 11:30:16 ... the platform may do some translation when showing user prompts, but apps should ask permissions separately 11:30:43 Tobie: if you split things it defeats the idea of high level sensor 11:31:17 all concrete sensors have a permission name as of now, do we need a "blanket" permission depending on the fusion ? 11:31:29 ... because the purpose of high level sensor is an abstraction without charging the user with the details; they won't be able to connect the partial permissions with the final permission 11:31:59 ... 2 ways to solve it; 1) each sensor having unique name, the UA can then do the mapping itself 11:32:09 ... 2) permission groups in the permission spec itself 11:33:14 ... it needs to be discussed in the Permission spec 11:33:51 Kenneth: it would be nice if permission could be given to an object; I want to use this thing 11:34:48 Maryam: 2 different groups of sensors: motion sensors and ambience sensors 11:35:14 ... no more categories at the moment 11:35:31 Kenneth: that is why not have permission on a given sensor object 11:36:00 ... easier for developers, as they don't need to know permission names 11:37:11 Maryam: easier for users to decide when they have fewer permissions to care about 11:37:25 Tobie: the question is about exposing permissions to developers, not users 11:37:48 https://github.com/w3c/sensors/issues/132 11:39:16 Tobie: the main question is still if on privacy perspective there is no reason to separate permissions for lower level categories, then let us not do this 11:39:39 Kenneth: giving permissions to Sensor objects is also future proof 11:39:53 ... platform can map it to user permission prompts if needed 11:41:00 Anssi: partial enums might not be a solution after all 11:41:48 Anssi updating the issue #22 comments 11:41:52 ningxinhu_ has joined #dap 11:46:37 Tobie: high level sensors have fewer permission issues than low level ones 11:47:05 s/permission/privacy 11:48:30 Tobie: if D is made of A, B, C in an unknown way; the UA controls D in any way it wants, perhaps with less information than A, B, and C separately 11:49:30 ... this makes incentive to developers to create these new contracts 11:49:45 ... to pick a less invasive version of the same data source 11:51:47 Anssi: this is capturing the discussion, add more comments to #22 if you want 11:51:54 ... this conclude Level 1 key issues 11:52:04 s/conclude/concludes 11:52:25 Anssi: move Level2 and future work for tomorrow 11:53:14 https://www.w3.org/2009/dap/wiki/LisbonF2F2016#Agenda 11:54:35 Discussing agenda for next day. 11:55:58 rrsagent, generate minutes 11:55:58 I have made the request to generate http://www.w3.org/2016/09/19-dap-minutes.html anssik 11:56:19 rrsagent, make minutes public 11:56:19 I'm logging. I don't understand 'make minutes public', kaorumaeda. Try /msg RRSAgent help 11:56:50 rrsagent, make logs public 12:14:24 mikhail has joined #dap 12:22:40 Zakim has left #dap 12:28:47 kaorumaeda has joined #dap 12:39:47 shalamov has joined #dap 12:41:21 Hiroki has joined #dap 12:46:52 tomoyuki has joined #dap 13:08:08 zkis has joined #dap 13:53:24 kaorumaeda_ has joined #dap 14:00:15 dom has joined #dap 14:07:47 lukasz has joined #dap 14:07:54 hey 14:20:59 lukasz: hey 14:24:50 oh hey tobie! ;) 14:25:03 I'd ask about the weather in Geneva, but I guess you're in Lisboa! 14:35:04 :) 14:40:50 Yves has left #dap 14:50:25 kaorumaeda has joined #dap 14:51:34 kaorumaeda_ has joined #dap 16:27:59 mats has joined #dap 17:24:25 kaorumaeda has joined #dap 21:00:29 kaorumaeda has joined #dap 21:42:31 zkis has joined #dap 22:10:09 Hiroki has joined #dap