Hi!
I started my second milestone by learning more about QuicStreams. A STREAM frame stores a "slice" of data, an ID(so you know from which stream the piece of data originated from), an offset into the actual data and a length. I have added an implementation for the STREAM frame using my set of UDAs and some methods that give some information about the type of stream that the frame originates from:
https://github.com/dlang-community/quic-d/pull/9

I studied a bit the handling streams in another QUIC implementation, to have an example. They implemented "QuicBuffer" that supports operations like push/pop/consume/seek. (For instance, you may want to keep the data in memory even if you sent it on the network, until you receive the Acknowledgment that it was received and then "consume" it) A "QuicStream" wraps around a "QuicBuffer" and it is a sort of a model of a single stream. A "QuicSession" is a model of a quic connection and handles the state machine related to streams (https://datatracker.ietf.org/doc/html/rfc9000#section-3.1). Both Sönke and Petar think that this is a good approach.

I continued by implementing the sampling, masking/unmasking, encryption and decryption required by Quic for the packet headers. This step is used to hide information like packet number from the "middleboxes" that may try to tamper with the UDP datagrams and disrupt the good functioning of the protocol, for example.
https://github.com/dlang-community/quic-d/pull/1
https://github.com/dlang-community/quic-d/pull/4

Any suggestion is welcome! Thank you!

References :
https://datatracker.ietf.org/doc/html/rfc9000
https://datatracker.ietf.org/doc/html/rfc9001
https://github.com/nodejs/quic/blob/master/doc/api/quic.md