IRC log of auto on 2016-07-26

Timestamps are in UTC.

15:38:28 [RRSAgent]
RRSAgent has joined #auto
15:38:28 [RRSAgent]
logging to http://www.w3.org/2016/07/26-auto-irc
16:21:09 [ted]
scribenick: ted
16:21:29 [ted]
Rudi: welcome to JLR OSTC
16:22:31 [ted]
… housekeeping items: wifi, facilities
16:22:52 [kaz]
Agenda: https://www.w3.org/auto/wg/wiki/Main_Page#July_26-28.2C_2016_in_Portland.2C_OR
16:24:43 [ted]
… some background on our OSTC, started renting space initially, built OSTC1 in 2014 which we'll see later this week
16:25:15 [ted]
… last year we started building this facility, OSTC2 which houses designers and our incubators
16:25:52 [ted]
… Matt Jones came up with the slogan that we are striving to be the best software company that happens to sell cars
16:26:42 [ted]
… we open source our architecture to help other companies and enable third parties to be able to work with us better
16:27:23 [ted]
… we want people to be able to download and install our environment on their computing platform to be able to develop towards it
16:28:13 [ted]
… our open source and standards is behind our participation in various consortium such as Genivi where Matt is president and W3C
16:29:27 [ted]
… JLR is the largest UK automanufacturer
16:29:36 [ted]
Topic: Introductions and Agenda review
16:30:20 [ted]
@@Attendees from signup sheet
16:32:35 [AdamC]
AdamC has joined #auto
16:34:10 [wonsuk]
wonsuk has joined #auto
16:38:40 [ted]
s/@@Attendees from signup sheet/Rudolf_Streif(JLR) Kevin_Gavigan(JLR) Adam_Crofts(JLR) Wonsuk_Lee(ETRI) Peter_Hauser(CarFit) Magnus_Feuer(JLR) Peter_Winzell(Mitsubushi) Paul_Boyes(INRIX) Junichi_Hashimoto(KDDI) Shinjiro_Urata(ACCESS) Tatsuhiko_Hirabayashi(KDDI) Kaz Ashimura(W3C) Ted_Guild(W3C)/
16:38:52 [ted]
[agenda review from wiki]
16:39:39 [KevG]
KevG has joined #auto
16:42:07 [kaz]
present: Rudolf_Streif(JLR), Kevin_Gavigan(JLR), Adam_Crofts(JLR), Wonsuk_Lee(ETRI), Peter_Hauser(CarFit;_observer), Magnus_Feuer(JLR), Peter_Winzell(Mitsubushi), Paul_Boyes(INRIX), Junichi_Hashimoto(KDDI), Shinjiro_Urata(ACCESS), Tatsuhiko_Hirabayashi(KDDI), Kaz_Ashimura(W3C), Ted_Guild(W3C)
16:51:34 [ted]
Present+ Jeremiah_Foster(Pelagicore)
16:54:20 [ted]
Topic: Status on Vehicle Information Service Specification
16:54:20 [ted]
16:54:20 [ted]
16:54:28 [ted]
-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Vehicle Information Service Specification
16:54:28 [ted]
16:54:35 [kaz]
s/Pelagicore/Pelagicore;_remote/
16:55:13 [urata_access]
urata_access has joined #auto
16:55:14 [ted]
Kevin: the diagram is over simplified as there are other possible routes
16:57:31 [ted]
… client can be software running on vehicle, agent will send data to off vehicle services
16:58:55 [ted]
… agents can query signals same as clients
17:01:05 [ted]
… we are providing an overview of what we know can work
17:01:57 [ted]
Rudi: the idea would be to implement so the security layers apply to the different actors
17:03:14 [ted]
Paul: I know we plan on discussing Iotivity OMA tomorrow. have people looked at their security model in detail?
17:03:31 [ted]
Rudi: I have looked at the OMA model and do not recall any details on security
17:03:57 [junichi]
junichi has joined #auto
17:04:01 [ted]
… there is some detail on the data model from VSS
17:04:36 [ted]
… as we looked at the current draft W3C data spec we saw it as too static
17:04:57 [ted]
… any time you wanted to extend it you would need to go through the standards process again
17:05:25 [ted]
… you need a path to a signal through the API and want to be able to maintain data definition and API separately
17:05:54 [ted]
… the idea of VSS is to use a simple and extensible language
17:06:06 [ted]
… straight forward tooling and editing
17:07:44 [ted]
… we hope to have a minimum signal set that most if not all OEM will implement and expose in addition vehicle specific signals
17:07:59 [kaz]
present+ Song_Li(Newsky_Security)
17:09:24 [ted]
[example declarations from wiki]
17:10:22 [ted]
Rudi: these definitions can be maintained in separate files and combined with #include
17:11:53 [ted]
… get and set methods need to provide the path of the signal they want
17:12:04 [ted]
… there is signal wildcarding to get eg signals from all doors
17:12:18 [ted]
s/wild/* wild/
17:13:25 [ted]
Kevin: there has been some discussion on whether it is better to use localhost or a different host name - maintained by /etc/hosts file
17:16:04 [ted]
Adam: we want ids for client connections
17:17:04 [ted]
Kevin: subscription id facilitates management of sockets
17:17:51 [ted]
… a concern is multiple connections being used by the same client application, setting signals on one connection and race condition querying on another
17:18:07 [hira]
hira has joined #auto
17:19:57 [ted]
Peter: I had not had time to fully compare the previous data spec and VSS but have spent time to implement a test signal system
17:20:35 [ted]
-> https://github.com/PeterWinzell/vehicle-carsignal-examples Peter Winzell's vehicle signal examples
17:22:06 [ted]
Rudi: we should discuss procedures for adopting VSS, whether it should reside in W3C repo or ok to reference it etc
17:23:03 [kaz]
present+ Powell_Kinney(Vinli)
17:23:12 [ted]
Kevin: the tree model of VSS can allow one to provide vehicle objects similar to DOM (VOM)
17:24:08 [ted]
… we need nodes to have unique ids in the tree whether they be numeric indexes or UUIDs
17:24:37 [ted]
… we want to be able to allow for jquery type searches on either id or eg all cameras
17:24:54 [ted]
Peter: so that is a suggested extension?
17:25:13 [ted]
Kevin: correct
17:25:24 [ted]
Peter: sounds like a good idea
17:25:52 [ted]
Rudi: server would be able to load VSS and create a queryable VOM
17:27:08 [ted]
Kevin: you could subscribe to vehicle.body and get back a body object with all the related json
17:27:52 [ted]
Hira: I understand the merit of VSS tree structure. what is the top of the tree, vehicle?
17:27:55 [ted]
Rudi: yes
17:28:45 [ted]
Hira: there will be some redundance
17:29:05 [ted]
Rudi: Magnus will tell us more when we get to VSS
17:29:25 [ted]
… we want to make a model that is easily understood so a developer can find and navigate to the data signals they need
17:30:06 [ted]
Adam: we looked at current data spec and readability
17:31:08 [ted]
… how do you define a control - you might not want to have it under chassis
17:32:17 [ted]
Kevin: there is static data that never changes like the vehicle weight and dynamic or configuration data
17:32:37 [ted]
Magnus: we wanted to keep VSS specific to signals data and stay clear of configuration data
17:32:46 [ted]
… however there is clearly a need for that
17:33:20 [ted]
Paul: can you clarify what you mean by configuration data?
17:33:40 [ted]
Magnus: static data like mileage rating, weight
17:34:38 [ted]
[Magnus presentation on VSS]
17:35:08 [ted]
Magnus: vehicles can have private branches that are specific to them
17:35:34 [ted]
… if we see commonly repeated private branches they should be candidates to include in the main branch
17:35:58 [ted]
Paul: I would think as an app developer you would want a similar if not the same interface
17:36:32 [ted]
Magnus: if there is a need from W3C side that can influence the argument at Genivi
17:37:54 [ted]
… private branch approach has two top level branches
17:37:55 [wonsuk]
wonsuk has joined #auto
17:38:33 [ted]
… there are ambiguities in the current spec
17:40:27 [ted]
… example with seats is you do not know by index which the steering wheel is at as that varies based on location model UK vs US for instance
17:40:43 [ted]
… aliases can help here so you can define 1 as driver's seat
17:42:45 [ted]
Adam: I see this as much larger than configuration data
17:53:54 [ted]
Paul: what happens to get that static data is implementation specific and behind the scenes
17:54:34 [ted]
Magnus: correct but they will be in their own specific/private VSS files
18:00:35 [ted]
Paul: are there any other standards that do this level of semantics we can leverage?
18:00:48 [ted]
Magnus: I'm sure there have been other efforts
18:26:58 [urata_access]
urata_access has joined #auto
18:27:00 [ted]
Rudi: Magnus will make adjustments to Global parameters and Peter H will define Chasis branch
18:27:29 [ted]
PeterH: how detailed should I go on eg steering attributes?
18:27:44 [ted]
Rudi: keep it simple for starters
18:28:19 [ted]
… bear in mind we will have proprietary/vehicle specific attributes that will be added as private branches
18:28:56 [ted]
Magnus: we need to get the basics and structure right
18:29:07 [ted]
Kaz: how to handle airbags?
18:29:38 [ted]
Magnus: that will be under cabin, they can be active or deployed
18:30:15 [ted]
Kevin: what about telematics control units?
18:30:25 [ted]
Magnus: we want to leave out network specific information
18:30:46 [kaz]
s/airbags?/airbags? it's related to how to handle zones as well./
18:41:23 [kaz]
(discussion on how to handle zones for airbags, cameras, etc.)
18:50:03 [kaz]
[ morning break ]
18:50:08 [kaz]
rrsagent, make log public
18:50:14 [kaz]
rrsagent, draft minutes
18:50:14 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz
18:50:45 [kaz]
Chair: Rudi, Peter, Paul
18:50:47 [kaz]
rrsagent, draft minutes
18:50:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz
18:51:11 [kaz]
Meeting: Automotive WG F2F Meeting in Portland - Day 1
18:51:12 [kaz]
rrsagent, draft minutes
18:51:12 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz
19:07:27 [ted]
[break]
19:07:51 [ted]
PeterH: can you explain more about zones?
19:08:40 [ted]
Kevin: we started off two dimensional and latter switched to three dimensional and found 3x3x3 (rubic cube) could handle many but not all situations
19:09:10 [ted]
(earlier example was you may have 5 cameras in the front, two with different angles in eg front left corner)
19:10:08 [ted]
Kevin: we can have x,y,z coordinates or index and aliases as Magnus suggested
19:11:01 [ted]
Adam: we used ISO8855 x, y, z positive integer coordinates
19:11:17 [ted]
… in earlier data spec
19:12:30 [ted]
Rudi: we should action Magnus to use same ISO8855 in VSS
19:13:08 [ted]
action Magnus to add ISO8855 in VSS
19:13:08 [trackbot]
Created ACTION-18 - Add iso8855 in vss [on Magnus Gunnarsson - due 2016-08-02].
19:16:49 [wonsuk]
wonsuk has joined #auto
19:17:06 [kaz]
s/Gunnarsson/Feuer/
19:18:54 [kaz]
-> https://github.com/GENIVI/vehicle_signal_specification GENIVI Vehicle Signal Spec
19:19:49 [kaz]
-> https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Body/ExteriorLights.vspec ExteriorLights.vspec
19:24:05 [kaz]
(discussion on consistency of name convention)
19:29:23 [kaz]
-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Back to the W3C repo
19:35:24 [kaz]
(review "VSS Description" section)
19:36:37 [kaz]
(discussion on "Branch Entry")
19:37:11 [kaz]
rudi: aggregate element is optional and the default value is "true"
19:37:27 [kaz]
s/aggregate/"aggregate"/
19:38:04 [kaz]
(discussion on "Aggregation Inclusion")
19:38:20 [kaz]
rudi: "aggregation inclusion" is not a right wording...
19:38:39 [kaz]
... changes to "Global Inclusion"
19:42:29 [kaz]
... flag to identify read/write?
19:44:50 [kaz]
kevin: some data might be more cautious
19:45:23 [kaz]
rudi: implementers might restrict the permission
19:50:16 [kaz]
... update the wiki with "mode: r" for "chassis.transmisison.speed" to make clear that implementers may restrict the permission
19:51:10 [kaz]
s/update the wiki/update the "Signal Entry" section/
19:51:24 [kaz]
... also update the "Enumerated Signal Entry"
19:51:54 [kaz]
... with "mode: r"
19:53:47 [kaz]
kaz: maybe it would be better to have another column of "possible values" in addition to "default value"
19:54:11 [kaz]
rudi: updates the table with the possible values
19:54:40 [kaz]
... "r = read, w = write, rw = read and write"
19:55:31 [kaz]
i/GENIVI Vehicle Signal Spec/scribenick: kaz/
19:56:27 [kaz]
[ lunch ]
19:56:32 [kaz]
rrsagent, draft minutes
19:56:32 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz
20:53:24 [ahaller2]
ahaller2 has joined #auto
21:00:30 [junichi-hashimoto]
junichi-hashimoto has joined #auto
21:29:15 [kaz]
topic: OSTC Tour
21:29:25 [kaz]
topic: JavaScript API
21:30:37 [kaz]
-> rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html Vehicle Information Access API
21:30:49 [junichi-hashimoto]
junichi-hashimoto has joined #auto
21:30:56 [peterw]
peterw has joined #auto
21:31:05 [Paul]
Paul has joined #auto
21:33:55 [kaz]
-> http://lists.w3.org/Archives/Public/public-automotive/2016Jul/0019.html Wonsuk's message
21:34:16 [kaz]
paul: should align with the service spec
21:36:33 [kaz]
rudi: what is exposed in the current spec?
21:37:34 [kaz]
paul: there are access api spec and data spec
21:39:21 [kaz]
-> rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html data spec
21:41:09 [wonsuk]
wonsuk has joined #auto
21:43:30 [kaz]
paul: we've been doing webidl
21:43:43 [kaz]
... also some implementations on th library
21:43:48 [kaz]
s/th /the/
21:44:08 [kaz]
ted: who is implementing?
21:44:16 [kaz]
paul: KDDI/ACCESS
21:44:24 [kaz]
peter: others as well
21:45:00 [ted]
q+
21:45:41 [kaz]
rudi: who is investing?
21:46:42 [kaz]
kevin: Web clients would benefit with WebIDL?
21:47:32 [kaz]
ted: nice to have high-level wrapper
21:47:46 [kaz]
... but maintenance issue
21:49:03 [ted]
q-
21:49:39 [kaz]
hira: we've implemented JS API based on ACCESS's platform
21:50:14 [kaz]
paul: maintain separately as is?
21:51:03 [kaz]
kevin: benefit to Web browser vendors
21:51:23 [kaz]
paul: that's why created a wiki to see that
21:51:48 [kaz]
urata: making the two specs aligned is good
21:52:17 [kaz]
... simple APIs are useful for Web developers
21:52:46 [kaz]
... vehicle signal spec has tree structure
21:53:55 [kaz]
paul: would present?
21:53:55 [kaz]
urata: yes
21:54:13 [kaz]
... vehicle information service spec
21:54:22 [kaz]
... "Signal Addressing" section
21:55:14 [kaz]
... simple "get" API
21:55:29 [kaz]
hira: should be able to map with each other
21:56:29 [kaz]
ted: you have to update the mapping
21:57:35 [kaz]
... people have to implement both the service spec and JS API spec
21:58:25 [kaz]
hira: most Web developers are familiar with the current JS API
21:58:42 [kaz]
... they're not really familiar with the VSS spec
21:59:13 [kaz]
hashi: information service spec specifies local server
21:59:31 [kaz]
... W3C doesn't specify that
22:01:35 [kaz]
paul: previously we had Data spec
22:01:43 [kaz]
... now we're changing that
22:02:19 [kaz]
... how to tie then with each other?
22:03:26 [kaz]
... spent long time for the current data spec
22:03:38 [kaz]
... VSS is trying to do more than we did
22:04:08 [kaz]
peter: possible for the data to glow
22:04:19 [kaz]
... don't see any issues to have high-level APIs
22:05:09 [kaz]
powell: we can keep the WebIDL API
22:05:21 [kaz]
... and work on the service interface
22:05:55 [kaz]
ted: once the service API is done we can do the mapping between the service API and the JS API
22:06:58 [kaz]
paul: like the idea of VSS
22:07:08 [kaz]
... agree with what Ted says
22:07:25 [kaz]
... could have JS library for the client
22:07:54 [kaz]
... maybe we could decouple them
22:08:34 [kaz]
paul: VSS has more broad target
22:09:40 [kaz]
kevin: websocket interface would be sufficient for us
22:09:55 [kaz]
urata: one thing I'm worrying about is the roadmap
22:09:58 [kaz]
... by the end of this year
22:10:11 [ted]
[webidl api in its current form could be mapped to services api and vss with a wrapper library. webidl api has provisions for being extensible and that may be how it gets at new signals data that gets added to vss]
22:10:15 [kaz]
... if we change our plan drastically, the schedule would change much
22:10:29 [ted]
[service api is a prerequisite and needs to be done first]
22:11:10 [kaz]
... if we change our direction, not sure about what to do
22:11:29 [kaz]
... need strong reason if we change our plan
22:11:37 [kaz]
s/plan/plan drastically/
22:12:04 [kaz]
paul: this is a flexible architecture
22:12:30 [kaz]
... how your clients work with it
22:13:01 [kaz]
... what the client would look like
22:13:37 [kaz]
peter: the industry doesn't want the old spec...
22:13:58 [kaz]
ted: we're losing interest in the WebIDL approach
22:14:57 [kaz]
... would make sense to have predefined set
22:16:25 [ted]
[we are finding more parties interested in the service/socket approach who are doing similar and had dismissed our idl approach]
22:17:23 [kaz]
kevin: what sort of conclusion?
22:17:44 [kaz]
rudi: the WebIDL specs are still drafts
22:18:32 [kaz]
paul: what should we do for the new charter?
22:18:42 [kaz]
ted: we're going through the new charter now
22:20:14 [kaz]
paul: who would implement the service interface?
22:20:21 [kaz]
... maybe four from this group?
22:21:07 [kaz]
... who would implement the current WebIDL spec?
22:21:18 [kaz]
... my company would not...
22:22:38 [kaz]
rudi: interested in WebSocket service approach + VSS
22:23:35 [kaz]
kevin: JLR would interested in websocket service approach with VSS
22:24:00 [kaz]
... not really webidl
22:24:19 [kaz]
wonsuk: also interested in websocket approach
22:24:56 [kaz]
... but JS API could be implemented by polyfill and in that case it's websocket in the end
22:25:26 [kaz]
paul: do we need JS library?
22:25:46 [kaz]
wonsuk: we don't want to maintain the webidl spec
22:25:57 [kaz]
... but we want to provide js library for dvelopers
22:26:15 [kaz]
... to define APIs for them
22:26:43 [kaz]
s/dvelopers/Web application developers/
22:27:04 [kaz]
... if people are interested they can provide JS library
22:27:57 [kaz]
kevin: opensource community might want to have JS library
22:28:25 [kaz]
... it wouldn't give any harm
22:29:25 [kaz]
paul: are we formalizing our approach?
22:29:48 [kaz]
kevin: both are logically compatible
22:30:10 [kaz]
paul: I'm not against
22:30:17 [jkim]
jkim has joined #auto
22:30:24 [kaz]
... we need two implementations for getting CR
22:32:27 [kaz]
... webidl spec is a client spec
22:32:35 [kaz]
... do we want to specify that?
22:43:52 [ahaller2]
ahaller2 has joined #auto
22:48:14 [wonsuk]
wonsuk has joined #auto
22:48:50 [ted]
kaz: WoT IG is facing a similar problem. they are sending a questionnaire to stake holders to see what they want
22:48:56 [ted]
… perhaps we should do the same
22:51:06 [kaz]
i/WoT IG/scribenick: ted/
22:53:08 [kaz]
-> https://www.w3.org/WoT/IG/wiki/Implementations WoT Implementations list
22:54:56 [kaz]
[ afternoon break ]
23:04:09 [ahaller2]
ahaller2 has joined #auto
23:05:20 [Karen]
Karen has joined #auto
23:13:54 [junichi-hashimoto]
junichi-hashimoto has joined #auto
23:16:15 [jkim]
jkim has joined #auto
23:16:54 [jkim]
jkim has joined #auto
23:17:27 [ted]
Topic: Carfit
23:17:33 [ted]
http://car.fit
23:18:23 [ted]
PeterH: there are many issues not properly monitored by owners (tires, brakes etc) that are also lacking sufficient sensors
23:18:41 [ted]
… we are trying to be a go between between service and owners
23:19:29 [ted]
… drawing from personal fitness devices came up with carfit
23:19:44 [ted]
… our device sits on top of the steering wheel and monitors vibrations
23:20:07 [ted]
… we see this as a real compliment to odb2 monitoring
23:20:43 [ted]
… we are starting to run pilots of the product out in the field and starting to look for possible partnerships
23:21:24 [ted]
… we're looking at things outside of the engine
23:22:27 [ted]
Ted: what sort of things can you detect - wheel imbalances, brakes stuttering when applied?
23:23:01 [ted]
PeterH: yes but we are getting a range of interesting data. we can tell if there are burrs on rotors
23:24:10 [ted]
… we are able to discover common issues by class, manufacturer and combine our sensor data with known problem sets
23:24:36 [ted]
… getting information from a genivi+w3c environment adds to diagnostic capabilities
23:25:05 [ted]
Rudi: lots of variables such as tire manufacturer to take into account
23:26:08 [ted]
Kevin: you are really able to tell that much from vibrations on the steering column
23:26:23 [jkim_]
jkim_ has joined #auto
23:26:35 [ted]
PeterH: yes, a new car should be pretty smooth and vibration free a good zero starting off point
23:28:03 [ted]
… we collect lots of data, some of which will become interesting or valuable later
23:30:10 [ted]
Ted: seeing this as an aftermarket solution, you working with OEMs to get your devices embedded?
23:30:55 [ted]
PeterH: yes but aftermarket is huge with millions of vehicles on the road that require hundreds of billions of dollars in service revenue
23:31:28 [ted]
Kaz: can you account for driver behavior variation?
23:32:03 [ted]
PeterH: yes and also we can get into things like detecting when a given driver's behavior changes - distracted or tired
23:32:35 [ted]
Shinjiro: is everything done on the device?
23:33:18 [ted]
PeterH: yes and combining with phone capabilities and products like Vin.li's
23:33:42 [ted]
… we would like to be able to send a tire out of balance notification to head unit for example
23:34:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html ted
23:41:48 [kaz]
topic: Security&Privacy update
23:42:20 [jkim_]
present+ Joonhyung_Kim(LG Electronics)
23:43:03 [ted]
Song: security is about controlling access to data and privacy policies about who that information can be shared with
23:43:09 [kaz]
-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations Security&Privacy considerations section in the Vehicle Service Spec
23:44:22 [ted]
Paul: laws vary by country, for instance in Germany people need to opt in explicitly for sharing specific information to a third party
23:44:24 [ahaller2]
ahaller2 has joined #auto
23:44:45 [ted]
Kevin: we do not want to try to keep pace with various legislation, only define the mechanisms
23:45:37 [ted]
Rudi: I agree. we will enable accessing that data but it will be up to the individual OEM to follow laws for where vehicles are
23:46:02 [ted]
Paul: yes but you need to know the use cases more to be able to define those mechanisms
23:46:34 [ted]
Kevin: the mechanism can be generic, identifying which information it is proposing to which external service
23:47:17 [ted]
Paul: can you give example on how that would work?
23:48:20 [ted]
Rudi: we went through this with RVI. if a given application wants to access certain services it needs a signed certificate and a means to verify it
23:48:57 [ted]
Powell: @@p
23:50:32 [ted]
Kevin: the model here is there are separate security authority providers that can verify a token and entity is valid
23:51:51 [ted]
Powell: we need a web socket that has a secure handshake and then able to exchange tokens
23:52:16 [ted]
… is a token for a specific app?
23:52:20 [ted]
Kevin: it could be
23:55:46 [urata_access]
urata_access has joined #auto