SFrameTransform interface has two heads

[jan-ivar]

The SFrameTransform interface appears to have been designed with two disparate uses in mind:

1. in place of a RTCRtpScriptTransform:

   transceiver.sender.transform = new SFrameTransform;

2. as a builtin TransformStream:

   onrtctransform = async ({transformer: {readable, writable}}) => {
     await readable.pipeThrough(new SFrameTransform({role: "encrypt"})).pipeTo(writable);
   };

These are entirely different uses that arguably should be two different interfaces.

For instance, web developers shouldn't have to figure out what this means:

await readable.pipeThrough(transceiver.sender.transform).pipeTo(writable); // what does this do?

A RTCRtpScriptTransform, in contrast, has no stream-like properties on main-thread.

Unfortunately, the current spec conflates two "transform" concepts, making this hard to see. But #229 should clear this up.

[youennf]

This design was based on the initial version of the spec which was based on exposing readable and writable properties.
It also reduces the number of interfaces while allowing to use SFrame outside of RTC (SFrame is bigger than RTC I think).

await readable.pipeThrough(transceiver.sender.transform).pipeTo(writable); // what does this do?

This will reject since attaching a transform to a sender is locking the streams.

In general, SFrame can be used for transmitting any kind of data, audio, video, data channel data, web socket stuff...
Hence why SFrameTransform is a generic transform.

We could have separate constructs, maybe this is worth it, based on comments from Richard as well.
That would mean introducing a RTCSFrameTransform in addition to SFrameTransform.

Benefits I would see with a separate interface (SFrameTransform vs. RTCSFrameTransform):

• Clearer meaning (?)
• Remove the role parameter for RTCSFrameTransform.
• Remove readable/writable for RTCSFrameTransform.
• RTCSFrameTransform would be window only, SFrameTransform could be created in workers as well.

Some points to discuss:

• More interfaces -> More expensive
• Most of the API is shared between the two (mixin could be used to mitigate this)
• Spec becomes bigger (we might need to describe twice very similar more processing).
• A UA could ship one API but not the other (could be a bonus, since SFrameTransform could be shipped before we have SFrame packetization).

[bifurcation]

I agree that SFrame is bigger than RTC. For example, MoQ is looking at SFrame for protecting media objects. But it does seem worthwhile to me to separate the RTC case from the more general use case.

As has been discussed, in the RTC context, SFrameTransform does more than just apply SFrame encryption. It also changes the packetization, whether that's by swapping the media-aware packetizer for a generic one (mode=frame) or updating the MTU (mode=packet). The generic transform shouldn't have to be bothered by that.

On the discussion points: I think most of the duplication can be avoided in exactly the way you suggest. Your last point about shipping SFrameTransform ahead of WebRTC seems like a positive to me -- you could basically ship this today.

[jan-ivar]

Interfaces are also about ergonomics and don't have to be expensive. I'd rather follow the TextEncoder/DecoderStream precedent, which suggests SFrameEncrypterStream and SFrameDecrypterStream (doing away with the role switch).

SFrameTransform does more than just apply SFrame encryption ... The generic transform shouldn't have to be bothered by that.

And vice versa, the main-thread sender/receiver-assignable (RTC?)SFrameTransform handle-object works without including GenericTransformStream, suggesting a clean break is doable.