jiebi/CodeConvo huggingface dataset:
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order) <del> Objects can be dependent on other objects, in which case reordering is required (dependencies). </del> The decoder receives each objects and skips any objects that do not arrive in time (decoder).
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: MAY overlap with other objects.  This means timestamps may be interleaved between objects. <del> MAY reference frames in other objects, but only if listed as a dependency. </del> Media objects are encoded using a specified container (containers). 4.2.
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: each object are still delivered in order; this delivery order only applies to the ordering between objects. <del> An object MUST NOT have a smaller delivery order than an object it depends on.  Delivering objects out of dependency order will increase latency and can cause artifacting when memory limits are tight.  This is especially problematic and can cause a deadlock if the receiver does not release flow control until dependencies are received. </del> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (prioritization) such that streams are transmitted in delivery order.
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: 4.3. <del> Media encoding uses references to improve the compression.  This creates hard and soft dependencies that need to be respected by the transport.  See the appendex for an overview of media encoding (appendix.encoding). An object MAY depend on any number of other objects.  The encoder MUST indicate these dependecies on the wire via the OBJECT header (object). The sender SHOULD NOT use this list of dependencies to determine which object to transmit next.  The sender SHOULD use the delivery order instead, which MUST respect dependencies. The decoder SHOULD process object according to their dependencies. This means buffering a object until the relevent timestamps have been processed in all dependencies.  A decoder MAY drop dependencies at the risk of producing decoding errors and artifacts. 4.4. </del> The decoder will receive multiple objects in parallel and out of order.
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: "order".  An integer indicating the delivery order (delivery- order).  This field is optional and the default value is 0. <del> "depends".  An list of dependencies by stream identifier (dependencies).  This field is optional and the default value is an empty array. </del> The payload of the OBJECT message consists of a fragmented MP4 container (fmp4).
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: Track Box in the initialization fragment.  A Common Media Application Format Segment CMAF meets all these requirements. <del> Each OBJECT message (object) MUST start with an initialization segment, or MUST depend on a OBJECT that does.  The rest of the OBJECT message MAY be a media segment. </del> Media fragments can be packaged at any frequency, causing a trade-off between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency.
Code change:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Related discussion:
text: We can further reduce the number of objects by combining frames that don't depend on each other.  The only restriction is that frames can <del> only reference frames earlier in the object, or within a dependency object.  For example, non-reference frames can have their own object so they can be prioritized or dropped separate from reference frames. </del> <ins> only reference frames earlier in the object.  For example, non- reference frames can have their own object so they can be prioritized or dropped separate from reference frames. </ins> The same GoP structure can also be represented using six objects, although we've removed the ability to drop individual B-frames:
Code change:
The text we landed for to define priorities (URL) indicates that we should use a 8 bits ( where is ) to convey subscriber priority and similarly a byte to convey publisher priority. ( URL ) ( URL ) The text also indicates that lower values have higher priority which I read as meaning 1 () should be sent before 10 (), (After) is 133 (u8) Edit: We should probably recommend that implementations use a mid-range value like as a default to allow for prioritizing both above and below it. (The MoQT spec doesn't need to define a default since these values are currently always explicit on the wire, but I think it would be helpful to provide guidance here.)
I have a slight preference for treating these priorities as signed values because it makes a good default for implementations to choose. That way it's possible to go above or below the default. The same is possible with unsigned values, too, but if we go that direction we may want to provide some guidance to that effect (recommending something like or as a default mid-range value).
Oh, nevermind, NAME noticed some text I missed in section 4: "with 0 being the highest priority" which would imply these are unsigned int values, . It may still be helpful to make that more explicit and recommend a default mid-range value.
I'm fine with some editorial text here if that's how we want to resolve it? (PRs welcome NAME ) I'm also ok with it being signed, since it it nice for 0 to be a 'default' value, but we don't use signed integers anywhere else in MoQ, so I'm a bit concerned that using them in exactly one spot could be confusing or error prone?
In some cases, things would work better if we allocated some ranges of priorities to specific DSCP like "less than best effort" or "best effort". That would end up making the actually numbers here have absolute meaning too instead of just relative meaning.

Related discussion:
text: sessions, either within a single connection or on multiple connections can be used. <ins> Implementations that have a default priority SHOULD set it to a value in the middle of the range (eg: 128) to allow non-default priorities to be set either higher or lower. </ins> 5. Relays are leveraged to enable distribution scale in the MoQ
Code change:
Current definition specifies namespace is an N-tuple, with 132 is it expected to return a protocol violation, or do we leave that undefined?
+1 I think we should address this as part of refactoring the tuple type
I put up a PR addressing the issue but didn't do a larger refactor of the tuple type, which seems editorial.
Editorial suggestion, but LG

Related discussion:
text: Track namespace is an ordered N-tuple of bytes where N can be between 1 and 32.  The structured nature of Track Namespace allows relays and applications to manipulate prefixes of a namespace.  Track name is a <del> sequence of bytes. </del> <ins> sequence of bytes.  If an endpoint receives a Track Namespace tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation. </ins> In this specification, both the Track Namespace tuple fields and the Track Name are not constrained to a specific encoding.  They carry a
Code change:
Current definition specifies namespace is an N-tuple, with 132 is it expected to return a protocol violation, or do we leave that undefined?
+1 I think we should address this as part of refactoring the tuple type
I put up a PR addressing the issue but didn't do a larger refactor of the tuple type, which seems editorial.
Editorial suggestion, but LG

Related discussion:
text: messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", "participant=200"), a SUBSCRIBE_ANNOUNCES for ("example.com", <del> "meeting=123") would match both. </del> <ins> "meeting=123") would match both.  If an endpoint receives a Track Namespace Prefix tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation. </ins> Parameters: The parameters are defined in version-specific-params.
Code change:
Individual Comment: lgtm
I don't have a strong opinion, but why not MAXCACHEDURATION?
Section 6.1.1 has not been updated to reflect the 2 new messages with parameters.
I don't have a strong preference. Mind writing up a PR of whatever you think is a sensible proposal?
I don't have any preference at all, but I can do a straw man.
I can think of AuthInfo as the only parameter that makes sense for now. NAME please let me know if you think of anything else. I can add it to my PR. Thanks
Thanks, this should have been added originally.

Related discussion:
text: 6.1.1.1. AUTHORIZATION INFO parameter (Parameter Type 0x02) identifies a <del> track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. </del> <ins> track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES, ANNOUNCE or FETCH message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. </ins> 6.1.1.2.
Code change:
Merging based on in-person discussions.
You merged a litttttle early. The wire format is good, but the accompanying text could use some tweaks. For example, it's not specified when the object sequence number should be incremented. It must be done on every independently decodable OBJECT. I'll make another PR.

Related discussion:
text: Track ID: The track identifier as declared in CATALOG (message- catalog). <del> Object ID: A unique identifier for each object within the track. </del> <ins> Group Sequence : An integer always starts at 0 and increases sequentially at the original media publisher.  Group sequences are scoped under a Track. Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. </ins> Object Delivery Order: An integer indicating the object delivery order (delivery-order).
Code change:
This is a PR to propose changes in the data model PR. Largely work in progress, but I wanted to first propose an organization.
The introductory text seems clear to me. I have questions about what it means for an object to be 'atomic' - since it can necessarily be larger than an MTU it might not get delivered. It can be repaired of course, but what are the consequences to other objects in the group or track if the object never completely arrives? Are there restrictions on receivers attempting to use partial objects? This reader is excited to read the next chapter :D
NAME The main consequence of "atomic" is that it is way better to send one complete object than two incomplete objects. That should very much guide scheduling of transmissions at relays. The other consequence is that if publisher can split a big blob of data into several objects that can be processed independently, they should. For example, instead of sending "the entire GOB as an object", they would get better results sending the GOB as a series of objects, with each object boundary becoming a proper "cut mark". And yes, I have to develop the text. I checked in a partial PR to Suhas' PR, mostly to test my editing chain...
thanks Christian for detailed text. I will merge it into my branch and do an updated version based on this.

Related discussion:
text: Track ID: The track identifier as declared in CATALOG (message- catalog). <del> Object ID: A unique identifier for each object within the track. </del> <ins> Group Sequence : An integer always starts at 0 and increases sequentially at the original media publisher.  Group sequences are scoped under a Track. Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. </ins> Object Delivery Order: An integer indicating the object delivery order (delivery-order).
Code change:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Related discussion:
text: 6. <del> There are three primary architectural patterns available when building browser-based applications. </del> <ins> Here are the main architectural patterns available when building browser-based applications. single-domain, not using OAuth a JavaScript application accessing resource servers </ins> <del> a JavaScript application that has methods of sharing data with resource servers, such as using common-domain cookies </del> <ins> either directly </ins> <del> a JavaScript application with a backend component </del> <ins> or through a service worker </ins> <del> a JavaScript application with no backend, accessing resource servers directly </del> <ins> a JavaScript application with a stateful backend component for storing tokens and handling all authentication flows (BFF proxy) </ins> <del> These three architectures have different use cases and considerations. </del> <ins> These architectures have different use cases and considerations. </ins> 6.1. For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the <del> domain of the API (resource server), OAuth adds additional attack vectors that could be avoided with a different solution. </del> <ins> domain of the API (resource server) and the authorization server, OAuth adds additional attack vectors that could be avoided with a different solution. </ins> In particular, using any redirect-based mechanism of obtaining an access token enables the redirect-based attacks described in oauth-