Linus Basig

The [MQTT specifications](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_QoS_1:_At) says: > In the QoS 1 delivery protocol, the receiver MUST respond with a PUBACK packet containing the Packet Identifier from the incoming PUBLISH packet, having accepted...

> When did this change? I thought the library had always been pubacking after teh callback? It did not surprise me that the library acknowledges before the message is handed...

We were using the [paho.mqtt.c](https://github.com/eclipse/paho.mqtt.c) library before and it has the same "issue": https://github.com/eclipse/paho.mqtt.c/blob/master/src/MQTTProtocolClient.c#L326-L332 The same for the [patho.mqtt.python](https://github.com/eclipse/paho.mqtt.python): https://github.com/eclipse/paho.mqtt.python/issues/348 There are libraries that implement a delayable acknowledgment option like...

I implemented the `MOSQ_OPT_DELAYED_ACK` option for QoS 1. **Regarding QoS 2**: (for the following thoughts I assumed `message__queue()` stores the message in memory and that the message will be lost...

@karlp @ralight What do you think?

Why not just recommend using the structure defined by https://cloudevents.io? They have already spent a lot of time thinking about event structure. I think Standard Webhooks and CloudEvents would work...

> @linuxbasic, there's https://github.com/standard-webhooks/standard-webhooks/issues/36 that > I've been meaning to comment on. > > The gist is: we don't currently have any requirements for how to structure the payloads, only...