Livepeer Virtual Assembly - Concept

A concept that I’ve been thinking about with respect to the Livepeer Community has the working title of “Virtual Assembly”.

In short, it would be an audio-based forum for Orchestrators to be able to talk and listen to each other.

How it would work

  • An O would run a “Virtual Assembly” client, perhaps in-browser
  • They would connect their Orchestrator account and authenticate themselves
  • They would then be granted access to the assembly, allowing them to:
    • listen in real-time to what is being said in the assembly
    • react, without audio, to what is being said in the assembly (e.g. emojis)
    • be granted temporary access to address the assembly
      • would require the O grant the client access to their device’s microphone
      • only one (1) O would be able to speak at any one time.

The assembly could theoretically be permanently “in session”, but could also have scheduled debates in the leadup to deadlines for votes on LIPs and Treasury Grant Proposals.

The audio stream for the assembly could also be broadcast publicly, to allow non-Orchestrators to hear what is being discussed.

Inspiration

Livepeer Community is unique in terms of active participation and incentivisation. The groundswell of human energy that can be observed within this ecosystem is truly inspiring. Our communication still relies heavily on centralised infrastructure with proprietary authentication, with only informal connection to onchain roles. This assembly would provide a formalised way to translate onchain roles into meaningful platforms for addressing the active set of “elected representatives”.

This is also inspired by the fireside chats and watercoolers that happen regularly on Discord. This would aim to be something more “onchain”, and using infrastructure that we ourselves would run within the community.

Such a concept is modeled loosely on how discussion currently happens in traditional “in-real-life” assemblies such as the UN General Assembly, the UK Houses of Parliament and the US Congress: where typically there is one human speaking at any one time, presided over by a permissioned human.

Such a “Virtual Assembly” could also be presided over by a permissioned (or elected) human, or could also be governed by a schedule determined by Livepeer Governance.

Implementation

In terms of how it could be implemented, I wonder whether Mist would be able to effectively handle ingress of 1 webRTC audio channel input at a time from a browser-client integrated with “Connect Wallet”, and serve that audio channel as an output to 99 webRTC clients in real-time (as well as, perhaps, serving a broadcast hls stream for anyone wanting to consume the content).

There might need to be some authentication mechanism on the back-end to determine whether the connected wallet is indeed an active Orchestrator.

This might also be a nice place to prototype subtitling / transcription, allowing for text-searchable record of what was said and by whom: like an automated [Hansard](https://hansard.parliament.uk/).

And as I alluded to before, being able to broadcast (and record) the goings-on in the assembly, for any interested party to listen to, would provide an unprecedented level of transparency and visibility to the inner workings of the Livepeer Community.

As for hosting the infrastructure for something like this, I wonder whether something can be built into go-livepeer, perhaps using [Pion]( GitHub - pion/webrtc: Pure Go implementation of the WebRTC API ), to run on a cluster of Orchestrators.

But I will stop there before I get carried away with implementation details.

Feedback

I’ve intentionally tried to make this post snappy and succinct, to open the conversation and request feedback. So if anyone has anything to say about the concept, then I am one big ear to listen to it!

4 Likes

One thing to add: Livepeer Explorer would be an ideal site to consider using for this, adding an “Assembly” option, alongside “Governance” and “Treasury” as a consolidated place for core activities relating to the Livepeer Protocol to happen.

A user can either:

  1. Participate, if they are an Orchestrator (or even a Delegator)

  2. Observe, if they are neither an O or a D.

1 Like