First code for radio streaming implementation

[Chamsy-smart]

Description

This Pull Request introduces a new RadioStreamer service to libqaul, enabling nodes to stream external audio sources from a URL and broadcast them across the P2P mesh network via the Feed service.

Key Changes:

RadioStreamer Module: Created a robust async streamer using reqwest and rustls-tls to fetch audio streams.

Chunking & Retry Logic: Implemented efficient memory management with BytesMut to split streams into 32KB chunks and added a 3-second retry mechanism for connection stability.

Service Integration: Added start_radio and stop_radio methods to the ServicesModule to manage the lifecycle of the streamer using AbortHandle.

Feed Injection: Integrated Base64 encoding for audio chunks to allow seamless injection into the asynchronous Feed flooder.

Testing: Included unit tests for chunking logic and connection resilience.

Related Issues:

Initial implementation of Radio Streaming capabilities.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Chamsy-smart]

I have read the CLA Document and I hereby sign the CLA

[Chamsy-smart]

recheck

[Chamsy-smart]

Hello Matthias!

Subject: Proposal for RPC Interface & Permission Model

Now that the core RadioStreamer and Feed integration are functional, I’d like to propose adding an RPC interface (Protobuf) to allow external control of the radio service (Start/Stop/URL selection).

However, I have a question regarding the permission model for this feature:

Should any user be able to trigger a radio stream, following the decentralized nature of qaul?

Or should we restrict this to admin/node owners to prevent network flooding and preserve bandwidth/battery across the mesh?

Given that the current implementation uses UserAccounts::get_default_user() to broadcast chunks, I’m leaning towards a restricted access model to avoid spam. What is your take on this?

[MathJud]

@Chamsy-smart

Thanks a lot for this PR and for taking the initiative to introduce real-time media distribution via qaul!
Looking very much forward working with you on this!

Real time traffic is on our wish list since a long time.
1 to 1 voice and video communication as well as multicasting (like a radio channel).
We still need to create an own real-time communication module, as it has specific requirements and should be much faster than our current message based communication modules.

Things that could be helpful, that were created so far:

• we created a signalling channel for real time communication control. We had voice and video chats in mind, subscribing to a radio broadcast can of course be a feature. rtc source
• we are creating a test system, in order to test, measure and optimized all services and make them scalable. ( Add qauld-ctl CLI and Unix socket control interface for qauld (#541) #747 Create Test Network with different Topologies to test Scalability of entire Networks #733 )

Plans for the next months:

We will build configurable gossip messaging channels, to which users can subscribe ( #689 ). These channels are created with V.I.A in mind: they can be authoritative, with only some identities being allowed to post into a specific channel, to allow trusted entities to have their own news channels.
This will give some qaul specific and mesh-optimized multicast logic.
Out of which we could create a real-time media connection module.

[MathJud]

About the RPC communication:

The RPC communication is between the UI & libqaul. Users can only control their own node (e.g. the node on your smart-phone).
We built a user authentication layer via RPC to allow secure multi-user nodes, with web clients in mind. This layer is though not yet ready for real multi-user nodes. For radio broadcasting, IMHO this is not too much of an issue, as one wants to sent the stream to other nodes...