Streaming

[gkc]

Describe the solution you'd like

• Ability for one atSign to stream encrypted info to one other atSign
• (later) ability to stream encrypted data to multiple other atSigns

[gkc]

Hey @cconstab and @nickelskevin please can you add in a more detailed set of requirements / constraints here please?

[gkc]

Moving to PR48. Invested 3SP in PR47 on analysis, presentation and review.

[cconstab]

I wanted to see what we have now with the Murali demo.. But will detail the needs also..

[murali-shris]

I wanted to see what we have now with the Murali demo.. But will detail the needs also..

@cconstab Please use this branch of at client https://github.com/atsign-foundation/at_client_sdk/tree/stream_transfer_issue at_client/test/samples/stream_receiver.dart at_client/test/samples/stream_sender.dart with server branch https://github.com/atsign-foundation/at_server/tree/stream_transfer_issue

[cconstab]

Thank you!

[gkc]

Going to reduce the estimate here to 5SP as that looks like the most we can invest during PR51 given our focus on the core encryption projects (secure element support, and future-proofing)

[cconstab]

@murali-shris

The stream verb was originally targeted at providing a stream/socket connection from one atsign to another. As implemented I think things got confused with files. This is probably due to work we had at the time with atMospherePro.

Could I use what we have here for a socket at each end ? And a "file" that never ends ?

I suspect not, plus the connection would have to be full duplex.

The same mechanism is probably fine but socket and one end to a socket the other was my ultimate goal... This could also be a stream from an atSign to another..

Lets discuss..

@nickelskevin please add comments too if you have any to add..

[murali-shris]

@cconstab will come with a diagram/requirements and follow up arch call is needed

[murali-shris]

https://docs.google.com/presentation/d/1V3-xLj8ve5eStjrDMxBGUp3LhyKanmjr6aInmhDDoms/edit?pli=1#slide=id.g112867c3eab_0_0

[cconstab]

Some demo code is now in Colin Snippets (atCompany repo) Soon to be opensourced..

[murali-shris]

Current limitations in stream verb:

• Supports only streaming files
• If the file is large, memory footprint on client will be huge since we are reading entire file and passing to stream
• Secondary server is used as a relay server to transmit data from sender client to receiver client

To explore:

• Support different stream types video ,audio, text, file etc.,
• if there is possibility to connect sender socket to receiver socket directly, explore options
• Read on webRTC, STUN, TURN, ICE concepts
• Refer implementation sshrvd on how it relays data between client to device. Encrypt/decrypt the stream and not entire file content in one go.