VTIRC Story

The Doorbell Denouement
The mature doorbell metaphor of this story in a sense pulls the original doorbell.meansofproduction.biz metaphor inside out. The culmination of this is in what happens in certain states of the call model, viz. a live video feed replaces the semi-static content of the doorbell frame which then changes the metaphor from ringer to a live video, e.g. like a door or peephole .

Videotelephony meets Internet Relay Chat

For workout of the merge of vendor abstracted VT with conventional IRC servers and clients
with advisement for the 100 in mind

The operational context to do this is the Ft abstraction of VT instantiated for Jitsi and thus free to users of domain space as embodied in the doorbell metaphor.

While DS IRC and native (jitsi) VT are modified, neither IRC or VT infra code can in general be changed so this story looks forward to the eventual integration of 3rd party IRC and VT based on a first PoC here.

IRC Experience

The streams of the domain agents augmenting the integration, as said lines in host networks.

VT Experience

The VT providers videoconference session construct, currently most often called a meeting, under the doorbell color model of connectivity FSM.

During the rollout to commons, a jitsi meet will be spontaneously formed upon a simple command to the DCP agents that run externally ( JD and PM ) by any of the 100. Anyone in the network may join such a meet if it is so configured or they are of the 100. A purpose built extension based on lib-jitsi-meet facilitates such meets at the network, channel, and aside levels.

Requirements

Aspects and Properties

  1. A native VT session must be as easy or easier to use as is already the case for a nonce phrase identified Jitsi meet.
  2. The doorbell applet is the bridge to infra based on domain LDAP groups defined for the initial IRC sameboat domains.
  3. The VT aspect will introduce a new element not present in IRC (besides media/modality) which is that the VT session will not map to the whole channel/room in individual meets but must do so at the feature level. Each user will have an ad hoc selection of other users that they are sharing video with at the same time as participating at the text level with the whole channel.
  4. DCP maintains a default rulebase which can be customized for each network and channel, encoding common rules and those for libera in particular. Network and channel operators can adapt these to the specifc rules for their services and rooms. In this way the system agents are able to manage the IRC - VT interaction without violating local rules at least at the network level. Channel ops that have rules that need to be actively enforced and that are different from the network defaults will want to communicate those rules to DCP or opt out of the service.
  5. Support embedding of the doorbell via the redvant API in an arbitrary page as an entrepot to DS per the call model.

OTR Feature

The OTR protocol is supported when the VT backend is Jitsi as well as the DS provisioned versions of the following:

  • bitlbee
  • hexchat
  • irssi
For each of which the DS provisioned versions are built with the feature.

DevOps users can use MCP station to station channels with OTR messaging. In general this feature is somewhat moot in MCP/DCP channels so I'm not doing there. The Jitsi version of this enabled in the custom jitsi infra and those of third parties will be supported similarly.