Jonathan BeriAll rightly, trying out this server. 👋
Chris Woods@jberi hey! There you are :)
How are all things wasm and California ?
@mcwoods heh, not as cold as the rest of the country but colder than we're used to. Also not as much Wasm these days, but I play from time to time. How are things?
@jberi currently bracing for the winter storm here in Chicagoland.
WASM wise; doing a bit more, currently looking at how we can help with exception handling in WAMR.
And checking out if the component model will work with low end IoT devices.
What are you working on now?
Daniel Mangum
chrysn@chrysn @RIOT_OS we have two flavors - one natively built on Zephyr and a portable SDK. See the porting guide - https://github.com/golioth/golioth-firmware-sdk/blob/main/docs/Porting_Guide.md. libcoap is the main requirement but folks have written their own implementations (ex. MicroPython.)
OSCORE is not on the immediate roadmap but something we'd consider. Hard to find a good Go implementation (even DTLS was a challenge!) We just launched Cert support: https://blog.golioth.io/introducing-golioth-certificate-based-authentication/
Would love to know what you think!
@jberi @RIOT_OS I'd hope not to need much of an SDK (even though it's good that one exists) -- if the API is well designed and reuses established components like SUIT, a system with the standard components in place should just be able to use the cloud service. (Think like using good HTTP APIs works through curl, or how one'd pass a URL to PUT temperature readings to to a sensor tool). I'll definitely pass this on to our "cloud folks"!
@chrysn @RIOT_OS The MicroPython implementation was done using our CoAP reference, see https://docs.golioth.io/reference/protocols/overview. Hopefully that's enough for your cloud folks as well. https://forum.golioth.io/ if there are issues!
@chrysn @RIOT_OS Oh, and we maintain a cURL-like coap utility! https://docs.golioth.io/reference/command-line-tools/coap/coap
@jberi @RIOT_OS Yeah, it's hard to find even good DTLS libs, I've struggled in Python (and didn't get beyond PSK).
I'll have a look at the OSCORE plug test participants for a Go implementation (but I don't remember having seen any). I've implemented it myself 2½ times (FLOSS libraries with commercial services), but Go is sadly not a language I can help much with. On the upside, it's way lighter than DTLS on messages and code, and you can easily keep arbitrarily many "connections" on the server.
@jberi Nobody seems to have a Go implementation yet, but you may want to keep an eye on https://github.com/plgd-dev/go-coap/issues/331.
(This necropost was brought to you by skimming your colleague's latest CoAP article on https://blog.golioth.io/life-of-a-coap-message/ and noticing that it's about 50% DTLS).
(This necropost was brought to you by skimming your colleague's latest CoAP article on https://blog.golioth.io/life-of-a-coap-message/ and noticing that it's about 50% DTLS).
@chrysn thanks for the pointer! We're pretty focused on DTLS for the time being but continue to keep our eyes on OSCORE for the future. /cc @hasheddan for the mention!
@jberi @hasheddan @chris_gammell In case it helps spark more interest in OSCORE: the latest aiocoap release integrates EDHOC and OSCORE, our demos for RIOT-rs are constantly improving (like, accessing over EDHOC without a custom client), and are being factored out into even more general purpose EDHOC+OSCORE tools.