#coap — Public Fediverse posts

The diff on CSV data that #Forgejo (and thus #Codeberg) provides is really useful – right now for reviewing new #CoAP options and content formats as they go into the `coap-numbers` crate.

RFC 9953: DNS over the Constrained Application Protocol (DoC)

Le protocole #CoAP est un protocole léger, conçu pour les objets connectés. Ce #RFC décrit comment faire du #DNS au-dessus de CoAP. Si votre brosse à dents a besoin de faire du DNS, c'est ce RFC qu'il faut lire.

@miri64

https://www.bortzmeyer.org/9953.html

Preparing a demo for the @ariel booth at #CLT. If things goes to plan, you can control different #embedded systems running the same application from your browser.

#CLT2026 #IoT #CoAP

@nils I did have some reservations about using @ratatui_rs for embedded devices (mainly that they're natively pixel based, so why go through a typewriter interface when there's no legacy) -- but seeing how reasonable that looks in code already at this quick prototype makes me reconsider.

Don't hold your breath for a text based #CoAP web browser, but I'd love to build one.

The sign is a lie (and they knew that advance: train goes only to Köln), but still on my way to #FOSDEM.

Happy any time to talk about #CoAP, #CBOR, #DectNrPlus, IoT security and embedded Rust development, especially on @ariel and @RIOT_OS.

@reiver I think #CoAP is a good fit. It's easy enough to explain on a napkin, extensible, has the familiar REST semantics, and can be implemented on the smallest of devices.

Plus it has a well-vetted security mechanism that is lightweight enough to be implemented by a single person.

We're gathering momentum for slipmux, a transport of #CoAP over serial ports. That specification allows #embedded developers on simple boards that just have a UART to use the same tools with it as for talking to devices across the Internet. This includes security: I guess I just sent the first encrypted request over slipmux ever, and its security setup was unmodified from #ArielOS's CoAP example.
Implementation is available in #RiotOS (#C), and WIP for Ariel (#RustLang) and #aiocoap (#Python).

… and it was a success: We implemented runtime updates over #CoAP, and with our stack's access control, restricting changes to the VM code to authorized users is just a matter of four lines of config.

#IETFHackathon

Development of aiocoap, my Python CoAP library, is approaching its next breaking release.

If there's anything about its usability as a library that has been bugging you, especially if it would require breaking changes: Let me know soon, either here or on the issue tracker at https://github.com/chrysn/aiocoap/issues

#aiocoap #Python #CoAP

@khalid Now that toot makes me kind'a feel bad about wanting to introduce coap:// to that list of #smolweb protocols.

Then again, #CoAP excels at proxying (and was carefully designed to facilitate it even across protocols), so a client could go through a CoAP proxy to access any of the others (unless it happens to implement any of the others as well).

Thanks to @pyodide and @ProjectJupyter, using #CoAP is becoming more accessible: The latest version of the #aiocoap documentation has examples that can be run directly from the documentation, and access CoAP peers through a WebSocket-to-UDP cross proxy:

<https://aiocoap.codeberg.page/aiocoap/doc/pyodide.html#contrib-pyodide>

#Python

I'm fixing #aiocoap's memory leak tests to finally run as async functions: the original tests employed mechanisms from the age of tulip (back when asyncio was developed out-of-tree), and Python 3.14 dropping some obsolete mechanisms.

Good riddance, but also tough work fixing subtle possible leaks that are suddenly easier to discover.

#Python #CoAP

… and #IETF is not far behind, with https://datatracker.ietf.org/doc/draft-ochkas-cose-ascon/ almost ready to assign algorithm identifiers so this can be used in #OSCORE for #CoAP.

Discussions during the current #IETF meeting led me to write a new draft on a compact CoAP URI expression, Short Paths In CoAP (ShoPinC, following the trade tradition of contrived acronyms).

As not all of the #CoAP crowd is reading the IETF lists, I'm soliciting opinions or feedback from here as well.

https://chrysn.github.io/shopinc/draft-amsuess-core-shopinc.html

#DNS over #CoAP because you can always run X over Y at an IETF hackathon.

#IETF123

I hope that by the end of the year, I can use this in my favorite embedded OSes, @RIOT_OS and @ariel, as well as on bare metal systems, for firmware updates or encrypted #CoAP communication.

@chris_gammell You might want to join this year's @RIOT_OS summit: Rumor has it that there will be a presentation on the tools we use there to bridge the gaps between actual shell use (like, bidirectional character streams) and #CoAP based RPC.
(I didn't plan anything yet, but I do have an implementation of SSH-/mosh-like access to stdin/-out, so maybe I should file a talk too?)

As for multicast Block1 (block-wise PUT/POST request)… I think the block-size would have to be negotiated up front via a separate custom option.

Call it MCBlock1 (option 65000), unsigned integer consisting of:
- bits 0-3: SZX - Size exponent
- bit 4: P - Proposal
- bit 5: S - Master selection
- bit 6: C - Master cancellation

When a node wishes to send a blockwise file to a multicast group (via PUT or POST request payload) steps would be:

1. it sends a payload-less NON message to the group with the MCBlock1 option: SZX=its proposed block size exponent, P=1 (this is a proposal), S=0 & C=0 (no selections made)
2. The nodes that hear it, reply NON unicast, with their MCBlock1 responses; SZX=receiver's preferred SZX (same or less than sender), P=1, S=0 & C=0.
3. The sender picks one respondent, sends a UNICAST CON to that node with MCBlock1 with chosen SZX, P=0 (this is now the negotiated block size), S=1 ("I choose you") and C=0.
4. Respondent ACKs that CON message with Block1 set with a matching SZX (and block 0)… it has agreed.
5. Sender now sends to the group a NON message with MCBlock1 to the group: chosen SZX, P=0, S=0 and C=0.
6. The group nodes reply with a NON echoing the options as an acknowledgement.
7. Transfer begins using CON message Block1 with the agreed SZX … the chosen node ONLY sends the ACKs.

If the chosen node stops responding: sender sends a NON MCBlock1 C=1 unicast to that node, then goes back to step 3 to select another node… at step 4 the node responds with Block1 specifying the starting point, and the transfer resumes at step 7.

#CoAP #BlockwiseTransfer #RFC7959

A silly protocol idea has been brewing in my mind… CoAP over AX.25.

The thinking is this… use UI frames to encapsulate CoAP messages in the same manner as UDP and use a URI scheme like coap+ax25://DEST[,DIGI1[,DIGI2…]]/[path]

If DEST has the C/H bit clear, DEST is a "multicast" group, otherwise it's a specific amateur station.

File transfer just uses RFC-7959 [block-wise transfer] (with possibly a small extension inspired by RFC-2090 [TFTP Multicast] to allow Block1 transmissions to a multicast group).

That would allow file transfer and messaging between stations using existing AX.25 packet radio hardware.

- https://datatracker.ietf.org/doc/html/rfc7252 - CoAP RFC
- https://datatracker.ietf.org/doc/html/rfc7959 - Blockwise transfers over CoAP
- https://datatracker.ietf.org/doc/html/rfc2090 - TFTP Multicast
- https://ax25.net/ - AX.25 protocol specs and docs

#AmateurRadio #PacketRadio #AX25 #CoAP

If you are an #IoT #developer and need to combine several #protocol #bindings for an #IoT system, the acmeCSE provides a great environment for learning and experimentation https://acmecse.net/home/Supported/ #CoAP #http #MQTT #WebSocket

If you are a #developer and need to combine several #protocol #bindings for an #IoT system, the ACME-CSE provides a great environment for learning and experimentation https://acmecse.net/home/Supported/ #CoAP #http #MQTT #WebSocket

Just published a tutorial on my blog: Building a CoAP application on Ariel OS. It is not short, but aims to pick up interested developers from minimal prior knowledge of the fields, into actually writing code on embedded Rust systems.
https://christian.amsuess.com/blog/website/2025-03-27_ariel_coap/

#CoAP #embedded #RustLang #IoT

An unplanned product of the #IETFHackathon was a new #CoAP tool: https://coap.amsuess.com/view/##coaps+ws://demo.coap.amsuess.com/.well-known/core is now usable as a browser tool to fetch CoAP resources.
It is not pretty, and takes a few seconds to load, but then it's just 150 lines of code, building on aiocoap and #pyodide.

SIP для Интернета вещей: почему устройствам нужны голосовые возможности

Согласно исследованиям Statista , к 2030 году рынок IoT составит 621 млрд долларов (в сравнении с 182 млрд в 2020-м), поэтому Интернет вещей должен не только уметь собирать данные, но и оперативно передавать их на другие устройства или пользователям. Для этих целей IoT применяет разные протоколы. MQTT и CoAP нужны для быстрой передачи информации, HTTP — для удалённого управления устройствами, а SIP — для формирования сеансов связи, в том числе в реальном времени. В этой статье поговорим о преимуществах и перспективах интеграции SIP и Интернета вещей.

https://habr.com/ru/companies/exolve/articles/856950/

#internet_of_things #sipтелефония #api #облачные_сервисы #mqtt #coap #rtp #iot

Starting into a busy #IETF121 day: talking about #CoAP in the morning CoRE meeting, IoT lunch, #CBOR in afternoon, and board game night to unwind.
And that's only the Tuesday :-)

On my way to the #IETF121 hackathon -- I'll be working on packed #CBOR and #CoAP security, but also curious to chat with folks from other projects.

The #RustLang #CoAP example of @RIOT_OS has been updated. Previously you could list processes, access sensors or read the file system. Now, you can blink LEDs, read network settings, send #IPv6 pings, and even see who pinged you.
The data formats will still need some work, right now a lot is just crude #CBOR, but it works.
https://github.com/RIOT-OS/RIOT/tree/master/examples/rust-gcoap

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

With #IETF117 getting started, I'm looking forward to two #ACE related side meetings ("Can signed #CWT|s help us with onboarding?") and on side meeting on #CoAP applications – in addition to the regular session on those and related topics.
See you all in gather.town!