I’ve been looking forward to this session since the idea came to me last year of exploring the geeky side of vCon. Whenever an engineer is wheeled on stage at a conference, the assumption is only other geeks will understand them, this must be a developer conference. That could not be farther from the truth.

Dan is the mind behind py-vcon-server. At a recent vCon event he was referred to as the mother of vCon. Thomas is the vConfather, no argument there. While in my opinion, Dan is the creator of vCon given all his work in the IETF, and coding for the open source project. vCon is an inanimate object, sexual reproduction is not required.

We opened with Dan providing an intro to vCon and his thinking through creating the project. Thomas approached Dan, they are old colleagues, and they began testing out some principles for vCon, vCon began with hacking! And in parallel, Dan started drafting a document for the IETF on vCon.

vCon is a data exchange format between a contact center and the enterprise. There are so many different types of conversation. It really is surprising the telecoms industry did not stumble upon the need for vCon earlier. Currently, businesses store conversations in a variety of formats, often specific to the type of communications, the platform used, even specific to the device or group within an organization.

Our conversations are in a mess, compliance and AI training are two of the early use cases highlighting the need to get conversations in order. Though I still meet many businesses who consider their proprietary storage adequate. It’s a good job IT has been through so many standardization battles like ethernet and unicode, yet the complexity of conversations sneaked through to 2025. Now Thomas and Dan have our backs covered.

vCon stores not only the content of the conversation, but also the meta data. The Who, What, When, Where, Why. Which then gets me singing in my head that song by The Bazillions. But enough diversions.

The meta data extends into post conversation analysis, transcriptions, actions, summaries, engagement, mood, documents used, referenced, or signed like NDAs. Also the AI models being fed with the vCon. Conversations are an extremely rich field. It’s almost a building block of an AI-first enterprise.

A big milestone was the recent successful interoperability testing across 9 vCon implementations.

A vCon is a JSON object, JavaScript Object Notation, a human-readable text-based format for representing structured data. That object can be signed, as proof of integrity and security. This is all contained in the object.

The next privacy / security feature is redaction. Last year at TADHack developers were hacking on redacting vCons. This is the beauty of the open source model. From idea to developers experimenting is a few months.

Then there’s encryption of vCons using JOSE Javascript Object Signing and Encryption. So the unredacted vCon is protected. This was all part of the first vCon specification.

Some of the upcoming vCon features include selective disclosure, a standard schema for transcription, and consent. I think consent with signing means vCon could be critical for all those massive TCPA law suites. (Telephone Consumer Protection Act.) vCon’s applications just keep growing.

Because this is a geeky session, I asked, Why Python? I advise on the importance of sample code for developers in using APIs, Javascript and Python are two I immediately mention. Sometime I get an odd look on suggesting Python.

For Dan back in 1986 he was programming in C/C++. Back when I started. Dan’s attraction to Python is he’s able to do more, faster than with C++. I only experienced Python as my son learned, his focus was all the data structures. So it’s great to learn what drives Dan on Python.

My son and I were playing with a UV monitor, to measure our UV exposure over last summer, and there was a py addon for the device. Simply, someone had done most of the heavy lifting, so our contribution was data collection, and presentation. I fully agree with Dan on the community and addons make Python wonderful to use,

At the IETF there are many implementations of standards using Python. So it was the obvious language to use.

Dan highlighted an important capability in Python, introspection. This makes debugging Python code much easier than in other languages. You can ask any object what it does and what data it holds – and this is built in to the language. So a library is no longer a closed block of magic, it’s self documented.

Introspection was used in the creation of py-vcon, and py-vcon-server. Which are all well documented, as you can read here py-vcon-server.

The Python vCon Server provides the ability to do the following:

• Store, retrieve, modify and delete vCons
• Perform operations on one or more vCons using a pluggable framework of vCon processors
• Run a single vCon processor via a RESTful API, using provided or stored vCons
• Group a sequence of vCon operations (vCon processors to execute) and associated configuration into a Pipeline definition. Pipelines are workflows with AI enabled analysis and decision making.
• Run a vCon pipeline, via a RESTful API, using provide or stored vCons
• Queue vCon jobs for the pipeline server to run through vCon pipelines
• Administer and monitor the server and configuration via an Admin RESTful API

The Python vCon server an be thought of as the aggregation of the following high level components:

• vCon RESTful API
• vCon Pipeline Server
• vCon Processor Plugin Framework
• Admin RESTful API
• Plugable DB Interfaces

As Dan enthused about python, I became a convert, I’d played a little but did not appreciated how powerful the language is for building your own vcon processor, API, and self documentation. It enables no code workflows, providing a great platform for developers building with vCon.

I asked Dan about Python projects he’s proud of, and the py vcon server is one of the most elegant things he’s ever created. Understanding what he’s created really makes it easy for developers to build vCon into their platforms and enterprises.