Good evening, welcome to FASTM and welcome to the session about Net OTA. My name is Zygland Kornicki, I'm the author of Net OTA. And I would like to give you a quick introduction to what it is and why you might be interested. So in a nutshell, it's a service providing metadata for system packages to IoT-like devices.

It's co-developed with Sys OTA, which is able to consume the information it's providing as well as the images it's providing. And it's developed entirely in the open under Apache 2.0. It's meant to serve as a free stack for updating images with no paid extras that you actually need to have in order to have a product.

So the design of Net OTA is very simple, but also interesting in several properties. There are three main concepts that you need to be familiar with, packages, streams and archives.

We'll go over each and every one of them. So let's start with packages. Packages are just names that define some content. They should be good for humans to read and they can have branding related to your product. They do not convey any additional information beyond just that.

A package can have any number of named streams where you can publish things to. And a stream is just literally a point of distribution. Devices reach out to a specific stream to obtain information about what's available. This provides the ability to offer multiple versions or multiple levels of stability at the same time

and have this vary within a fleet of otherwise identical devices. You can offer LTS versions, you can offer latest development snapshots from nightly builds or anything in between using multiple streams for a given package, which again represents typically a system image.

A very important property is that a stream holds at a single point in time exactly one version of the software. So any archive within that stream is exactly the same version as all the other archives in that stream. Obviously, when you publish something, that can change.

But whenever a device looks at a stream, it will find a coherent set of archives representing variations of the exact same source that something was built from. And one of the interesting properties of a stream is that they can be closed. So for whatever reason, when you had a device which was following a stream which no longer exists,

you can redirect the device to follow a different stream to continue receiving updates. And you can think about streams as branches in a version control system. They represent a named entity which corresponds to some source. But this translates over to system images where you can use a named entity like the stream name

to find complete system images corresponding to that source. The last concept is archives, and archives are just things which you can publish in a stream. Remember that a stream can have many archives at the same time,

each of which corresponds to the exact same version of the software, the exact same source code it came from. The fact that archives can be plentiful allows you to offer multiple versions of the same software, sorry, not versions, multiple different builds of the same software at the same time. For instance, you can offer it for multiple different architectures

or completely optimized for specific machines. Or you can offer your source code bundle to comply with licensing requirements alongside the binaries. So they're just a way to provide a coherent set of binaries or source archives for the same timestamp or the same source version that something came out of.

So an important feature of the archive is that it describes the envelope and the content separately. So for one example, you can have an archive which says that it is a Rauch bundle.

Rauch is an embedded updating mechanism that SysOTA is based on. And within this Rauch bundle, there is actually a SysOTA system image that you can use to update a device. Another example could be that the archive is a tar GZ archive, like a tar ball,

and the contents is just the source code. The fact that these are separate allows you to describe the content more precisely. This is useful, for instance, to allow the same exact build of the operating system image to be compressed with different compression options for different devices based on their hardware constraints like memory or CPU.

So that you can offer the exact same content with different optimization levels depending on what the device is capable of consuming. And the device, knowing its preferences, will pick the subset that best matches what it should get. The last concept is download offers.

So effectively, every archive can list one or more download offers where the contents of the archive can actually be obtained from. They carry a URL and a metric allowing the device to pick the supported scheme of the URL and the best download offer, the one with the lowest metric.

This can be useful, for instance, in a gateway situation where the gateway can host a NetOT service of its own acting as a bridge to the outside world where other devices on the network can reach out to the gateway, query for available packages, and discover that not only can they download the package directly

from the open internet, but also maybe download it from the cached version available on the gateway directly. There are multiple other options where additional URL schemes can be added. So, for instance, instead of using HTTP, we could use a peer-to-peer protocol

to publish the same archive, and compatible devices could try to download this way to download the image this way more effectively. So, where we are right now. I've recently released NetOTA 0.3.1. It is tested and supported by SysOTA 0.1

with a documented on-disk repository format so you can trivially host your own repository with all the metadata being stored in files on disk. This is actually really nice for small repositories and you can host the entire repository in Git so you can manage versions, you can manage publishing changes using Git

using typical CI around Git repositories. The repository does not contain the actual binaries. Those are only referenced by the repository. That's a very interesting property allowing the repository to stay small over time. There's a standalone service which allows you to host the repository archive,

allows you to put this behind a reverse proxy or be used directly for local development. What's the plan for the next couple of months? We would like to polish the experience of developing a Yocto-based device

with a local NetOTA repository so that you don't have to repeatedly reprogram, reflash the device depending on the type of device you're working with that may be more or less cumbersome. We would like to explore the publishing pipeline so that we offer higher-level tools for publishing images in a cohesive way. We would like to deploy a public OTA service

that is being branded by Oniro, the organization I'm participating in, which would be hosting updates for all the reference devices that Oniro is working on. And lastly, we would like to explore posting images for Zephyr, and this is also why co-op was mentioned earlier, where a NetOTA service could run on a gateway

and actually offer the same protocol over co-op. So more constrained devices such as low-end Zephyr-based sensor or other IoT utility could discover and download updates itself using the gateway as a bridge to the wider Internet.

So that's the introduction into NetOTA. You can find more about the project in the link below. It's GitLab.com, my nickname, slash NetOTA. You can find me on IRC or on Twitter. Please reach out if you have any questions. Thank you for your time.

So just checking, yeah, I'm not muted.

There was a question of where we can find NetOTA and SysOTA. Okay, so NetOTA can be found on GitLab, so GitLab.com slash my nickname, Z-Y-G-O-O-N slash NetOTA. And SysOTA just moved to the Eclipse repository,

so GitLab.eclipse.org slash eclipse slash Oniro dash core slash SysOTA. So we still have a few more minutes, so go ahead and ask your questions.

So there's a mention that someone's keen to explore this for Docker artifacts and k8s and other container-like things.

So I have not done this myself yet, but actually I would love to explore it for application development as well. So you could have the same repository format hosting both your system images and container images. I'm not quite sure that this is a good idea just because there's a wide range of repository systems for container images,

but it depends. Maybe the application formats will just fit nicely. Maybe there will be embedded applications which are not containers like things Zephyr-like images or Zephyr file systems that you can put into this repository.

The fact that it's extremely extensible and open so that you can literally put any kind of content under a package name makes this quite possible, so I think it's easier to explore. And I'm really keen to try to put it onto a device that sits on your network where you can effectively not treat it as a cloud service,

but as a local appliance. So there's a question about signing. So there is no signature on the metadata itself apart from things like SSL protecting the transport. The actual images are signed, and the device, after fetching the image,

verifies the signature, but there's no signatures in the metadata itself. There's another question about encryption. So is encryption of archive content somehow a concern that is handled by Net-O-D-A? So far we have not touched encryption, mostly because we're working with open source software,

because the metadata is usually not so precious in the sense that the fact that there's some software you can get and the software is encrypted. The encryption is more about the image than the metadata. At least that was my experience in the past. We could explore it. We just didn't have a use case. If you have an interesting proposal, come to talk to me

and we can discover what would have to be changed or if there's some things that make it difficult to change that we have to adapt in general. We still have a few more minutes, so I'll just check if there was anything I missed.

Right, so the encryption was more about the archive. So again, you could come up with different schemes of how this would work.

The URL could require the download URL so that the archive says, hey, there's some things you can get from the stream. There's some archives and each archive has some download offers. Maybe you would have to have some per image, sorry, per device encryption, encrypted image for a given device.

So only that device could actually decrypt the payload. There's a class of keys that you have. There's all kinds of things you can explore this. I designed this specifically so it's fairly open and not rigid so that more and more things can fit into this, so it's flexible and easy to use.

Interesting, RALC encryption for bundles. I'm going to definitely read this. Thanks for sharing this.

All right, we still have a few more minutes, but unless there are any more questions, I think I'm going to turn the stream off. So last call for questions, please.

All right, in that case, thank you for your time. Thank you for participating. Again, to remind everyone, you can find that OTA or at GitLab.com slash ZYGON slash Net OTA and you can find the sister project Sys OTA over at Eclipse

with a slightly longer URL. I will post the links to the chats and thank you for participating.