[Minutes] Auto WG 2020-09-29 on WAMP

https://www.w3.org/2020/09/29-auto-minutes.html

On Wed, 2020-09-30 at 15:50 +0200, Tobias Oberstein wrote:
> Am 30.09.20 um 14:51 schrieb Ted Guild:
> > 
> > Please provide any corrections to draft minutes before I send them
> > out
> > and any links you think would be worth injecting based on what you
> > were
> > sharing from your screen.
> > 
[]

Thanks for your time, definitely want to explore this further with
group during our 12-15 October meetings I mentioned earlier and perhaps
just one on one so I can learn more and maybe narrow focus.
Authentication and access control for instance is something recently
hammered out with Ulf and Isaac putting in considerable work. 


I corrected WebSocket to be consistent, fixed company name and sorry
about that.

Inlined many of those links in the minutes but some topics you just
sent were not covered or I didn't capture enough in minutes on eg
microservices to place those so trimming this mail and including these
useful resources in sending minutes to the group.

When we met last Friday and on call yesterday we got into push vs pull
and how dealer addresses that. Some see Gen2 as being used to pull data
off the vehicle and others including myself thinking it should be
pushed. I see Gen2 being used for in-vehicle applications and Gen2 can
also run in the cloud for accessing already off-boarded data from the
vehicle. The push v pull thing gives me pause for its usefulness in
vehicle to cloud. In-vehicle applications performing data sampling to
offboard could benefit if the Gen2 service could serialize and
compress, especially if the format allows for inspection and further
trimming of extraneous data. This would be prepacking and enable local
storage/caching and off-boarding in batches based on connectivity.
There is clear interest in WAMP for cloud<->vehicle RPC. I am wondering
if WAMP could be a broker to Gen2 residing in the vehicle. Another
thought on how this can be architected in addition to your mapping
analysis. We may need a virtual whiteboard for the different
possibilities.

> serialization:
> 
> https://crossbario.com/docs/crossbarfx/benchmarks.html
> https://crossbario.com/docs/benchmarks/serialization/index.html
> 
https://crossbario.com/docs/benchmarks/serialization/vmprof_pypy_msgpack_normal_small.html
> 
> rgd wire efficiency (of websocket):
> 
> https://crossbario.com/blog/Dissecting-Websocket-Overhead/
> 
> routed rpc:
> 
> https://wamp-proto.org/routing.html
> https://crossbario.com/blog/Free-Your-Code-Backends-in-the-Browser/
> 
https://crossbario.com/static/presentations/seamless-connectivity/index.html
> 
> rgd microservices:
> 
> https://www.youtube.com/watch?time_continue=3523&v=07uXpvcqZtI
> 
https://github.com/crossbario/crossbar-examples/tree/master/scaling-microservices
> 
> rgd security:
> 
> https://crossbario.com/static/presentations/iot-security/index.html#/
> https://crossbario.com/blog/crossbar-and-tor/
> 
> ---
> 
> rgd xbr:
> 
> https://xbr.network/
> https://github.com/crossbario/xbr-protocol
> 
> note: xbr is using a general advanced wamp feature, namely
> application 
> payload end-to-end encryption - here is an old "plain" (non-xbr)
> example
> 
> 
https://github.com/crossbario/crossbar-examples/tree/master/encryption/cryptobox
> 
> here is a xbr one:
> 
> 
https://github.com/crossbario/crossbar-examples/tree/master/xbr/teststack1/python
> 
> here are some xbr-wamp defined apis:
> 
> https://github.com/crossbario/xbr-app/tree/master/schema
> 
> in particular, have a look at:
> 
> 
https://github.com/crossbario/xbr-app/blob/4afd0f6039c75619f27db1b054796a0190bf6398/schema/climate.fbs#L68
> 
> this is how we define interfaces for xbr buyer/seller delegates,
> which 
> are just wamp components following xbr conventions (including
> payload 
> encryption) plus buy/sell encryption keys. other than that, it's
> just 
> (e2e encrypted) wamp rpc/pubsub
> 
> xbr apis are identified by UUID, published into a catalog
> (blockchain)
> 
> 
https://github.com/crossbario/xbr-protocol/blob/4c82aea5e3b0d76be676d278cfdd2165a7270823/contracts/XBRCatalog.sol#L131
> 
> and then may be implemented (provided) or used (consumed) by
> (micro)services
> 
> those microservices talk to each other using wamp (with the apis 
> defining app payloads in wamp calls/events), and encryption keys are 
> sold/bought in data markets
> 
> for example, cars could publish and sell location data according to
> 
> 
https://github.com/crossbario/xbr-app/blob/4afd0f6039c75619f27db1b054796a0190bf6398/schema/location.fbs#L77
> 
> and cloud-based buyers can subscribe and buy, in this specific api
> even 
> by geo-tile (eg I only need data for Munich, not Franktfurt)
> 
> don't get confused by the "rpc_service" declarator in FBS - this api 
> actually defines both wamp events and rpcs! flatc will happily
> compile 
> that schema. just metadata.
> 
> I should also stress: the approach above with statically typed wamp
> apis 
> (app payloads) could also be used without the blockchain/buy/sell etc
> stuff.
> 
> anyways, I'll stop here. as you might notice, I am more excited
> about 
> xbr these days;) because in a way, this brings the original vision
> to 
> completeness.
> 
> ---
> 
> pls let me know if you plan to continue the discussion wrt to
> gen2/wamp, 
> generally "automotive/wamp". pls keep me in the loop, obviously, I'm 
> interested, and would love to contribute if I can.
> 
> cheers,
> /Tobias
> 
-- 
Ted Guild <ted@w3.org>
W3C Automotive Lead
https://www.w3.org/auto