Josh Allmann

Yeah the list itself is a bit curious, eg 520x576 is a PAL resolution which typically runs at 24fps (not 30/60) and there's no NTSC equivalent in the list, as...

The proposed changes seem reasonable. First, some assumptions: * Transcoders should be "publicly available" ; that is, given a `host:port` pair, there won't be a NAT or firewall complicating inbound...

This is where I should read up more about Kademila/libp2p addressing and routing. That being said, here are a few of the operational and scalability concerns I alluded to earlier:...

We're getting close. > TranscoderSub(T_IP, T_PORT, T_NodeID, T_Sig, B_NodeID) Finally did some reading into libp2p last night. Might a multiaddress work as well in place of an explicit IP/port? I...

> > it might be more "generic" to use IP/port, and have the client decide how to make the connection. > Perhaps it makes sense to use the multiaddr since...

Just double checking my assumptions here -- 'direct connections' are straight TCP, or are we talking about a libp2p-assisted direct connection that uses a libp2p protocol? > 6. B gets...

Couple more thoughts on the implementation details. * If the transcoder goes offline, the broadcaster needs to know when and how to re-initiate the direct connection to the transcoder. We...

There is no way right now to look up a job on the broadcaster given a StreamID. This makes it difficult to check the `Transcodesub` signature (eg, look up the...

Sure, we can defer signature checking. For the future, consider: all the job information is available right now on with an on-chain lookup via JobID, including the StreamID. So rather...

Oh very cool, I hadn't heard of Flat Buffers. Seems to take a very similar approach as Capn'Proto -- it essentially `write()`s the in-memory struct on the wire. Golang would...