Dan: Greetings and welcome back
to Quantum Divide on this episode.

Uh, It's going to be a
little bit different today.

Steve and I have decided to
Basically have a fireside chat.

Imagine me sat here in my big
leather chair, sipping on a glass

of single malt whiskey or whatever
you uh, other drinks are available.

But we're gonna have a, we're
gonna have a chat here about

quantum network simulation.

Steve, hello how you doing today, alright?

Steve: Yeah.

Hello.

Thanks for listening to me
rant again about simulation.

I know we talked a little bit in
the past about it, but I think

this is a little bit different.

So now we'll talk about what's being done,
what we're doing internally at Cisco also.

So a bit more about the product
side, a bit more about trends and

developments maybe a little bit
more about the technical aspects,

but yeah, it's going to be a

Dan: Yeah let's get into it.

Yeah, let's start with a recap
on the need for simulation.

Like you said, there's a, we're a bit of
a inflection point at Cisco where I think

we've uh, we've got some, some interesting
discussion to come, to come here.

So start with a recap and then we'll
work into as you said, what we've

been working on and what's out there.

Steve: So yeah, the need for simulation
for networks in general is that.

There's always a life cycle of how
network technologies are developed.

And that's always something like, start
with a problem statement, something

that needs to be solved, a communication
problem that needs to be solved.

And what happens is you go from
the problem statement to a, let's

say a theoretical solution to
that problem that could involve

writing down a protocol on paper.

And that's under complete, perfect
setting, no external sources of noise.

No, nothing that can cause problems.

That's the pen and paper solution.

What you do from there is to validate
the pen and paper solution is you program

that into a simulation and now you have
complete control of how much noise you add

into your network and you can see exactly
where it's happening and what can cause

problems that you can start to modify
your pen and paper solution to act against

noise and make the protocol more robust.

Once the protocol is robust against
noise, then it's goes into potentially a

laboratory where you field test and make
sure that, okay, now that we lose control

of our noise parameters, does the protocol
still work, even though, we, we still have

noise, but it's not under our control.

And then you can expand until you go
to product phase and so on, but always

in the life cycle of a new network
technology is a simulation stage.

And therefore the need for a simulation,
especially in quantum network

simulation, where everything is in the
problem statement stage is essential.

So everything is a problem.

You know, We have a, how do you transmit
quantum signal in a network setting?

You need protocol.

What's the protocol?

Don't know.

What's the link layer?

Don't know what's the network there.

Don't know.

So everything is a problem and therefore
we're going to pass through this

simulation setting many times before
we can start to deploy into test

bed and field tests and laboratory.

Especially for networking okay, we can
do transmission of quantum signal in

the lab, in the city and metro scale or
satellite, but is that a network protocol?

In a sense it is, but is
it a standardizable one?

Is it something that
solves a general problem?

Probably not.

So I see the need for simulation
because we need the ability to test

our network solutions for the problems
that are coming for quantum networks.

On the other side.

Simulation is required for quantum
networks is because we don't have the

hardware components that we need to
start testing in a network environment.

We don't have quantum memories.

Not everyone has a quantum source
in their office or in their lab.

Not everyone has a quantum detector.

So we need to simulate these hardware
components so that we can start playing

with them so we can start thinking of
applications given we have these hardware

components, what do we do with them?

And that gives uh, you know,
easy access to everybody.

They just have to download some software.

If they have the mathematical
representation of those hardware

components, they can act on them as they
would, as if they were real devices,

can emulate the devices potentially.

And treat them as a black box,
and then you have the input output

as if it was a real device, but
it's just a simulated device.

And so that's another essential reason.

It's very hard to make
quantum network technologies.

, they're not widely available
that anyone can access them.

And so the way we move forward
with quantum networks, building

applications and building
commercial products at the moment is

essentially limited to simulation.

So those two reasons I see being
the major factors why we need

a quantum network simulator.

Dan: Yeah, great.

And what about the current
trends in simulation?

So are there a series of tools out there
and what kind of level do they operate at?

Okay,

Steve: for right now is, quantum networks.

quantum Network Simulation, quantum
Network Applications is niche.

We don't see a huge market
for it at the moment.

QKD is an exception.

It's a commercially available tool
that went through its iterations,

but it's been going on for
something like 20 years at least.

BB84 is called BB84 because
it was invented in 1984.

So it has about 40 years head start.

And those.

Those technologies have developed
specifically for QKD or those

quantum network technologies
have developed for QKD.

So that's how it got to commercialization,
but there's been a lot of

simulation surrounding QKD as well.

But for general quantum networks,
entanglement based quantum

networks, I would say simulation
has only picked up in the last,

let's say, five, five years or so.

And now we're starting to make
progress towards a quantum network

simulator that is analogous to
what exists in the classical realm.

But I still think we're not on track
to making a quantum network simulator

that looks like what we have for
a classical network simulation.

And the main reasons are that the
libraries that are existing that

do the most powerful simulation
libraries that exist are not

completely available to everybody.

They're not open source.

So that means we can't really.

Started creating a community that
develops different features for

the software specific features for
everyone's need It's basically whatever

need exists for the people who are
maintaining that software and it's you

know Some of them are behind paywall.

So we don't have why that we can't
even just use it to start playing

around with these simulations.

So this most powerful ones are
not open and that's a problem I

think because When it comes to
networking, it's a global problem.

It's not like one person is going
to solve all of quantum internet.

So we need community, we
need open source code.

And I think what's happening
right now is we're not doing that.

And that needs to change.

So we need to bend the trend towards what
has been done in classical networking.

Dan: So listen, one thing I wrestle with a
little bit is the fact that at the core of

simulation in classical simulation, you're
constructing packets, frames, you're using

a well known construct that is agreed
and standardized for devices to talk

to each other and then virtualizing it.

When it comes to the quantum world,
none of that exists, as you mentioned.

So we end up we're trying to simulate
the hardware, we're trying to simulate

the behavior of virtual photons, if
you like going across the network and

then applying some kind of mathematical
modeling to them and some other

mathematics to model their behavior
based on quantum mechanics, I guess.

so is this.

At this low level, is there innovation
due to happen still in at that level, or

is it now about building on top of that?

Steve: Yeah.

So we're not at the stage yet, I
think, to start building on top.

Mainly because we're still developing
the frameworks for performing this like

physical layer simulation, so to say.

So the simulators that exist, they.

They give you access to hardware models,
quantum memory model, quantum modulator,

detector, source, everything you
need in terms of hardware components.

These are all mathematically modeled.

So now the user has access to these
mathematical models, up to them to

connect the dots, put the pieces together.

And now, okay, you have
connections made, but now what

do these hardware components do?

And it's still up to the user to
decide what the hardware components do.

And that's a challenge, right?

When we have classical network simulation.

What we do is we assume that we're
using a standard for generating packets.

We assume that these physical components
are robust, that they're noise free,

and we don't need to think about, bit by
bit messages going through the network.

And then when the bits arrive at
the next hop of the route, we don't

need to program step by step what
happens to each of those bits.

How do they get routed?

How do we decide what happens?

So those are all standardized
in classical networking.

But in quantum networks All we have
access to the hardware components

send bit by bit, photon by photon,
and then what do you do from there?

So that's it's an early stage and we
don't have a solid foundation for that

part yet So it's hard to build up on
that so we could probably go from What

we have now to a link layer protocol,
like one step above the physical layer

but I don't see how we could go higher
than that because we haven't agreed

on how qubits are even sent from point
A to point B, they can get sent, but

how do you detect that they arrived?

What are the, what is the
metadata surrounding that?

Is it even qubits sending, being sent?

Okay, the qubits, but there
could be also coherent states.

How do we detect them?

How do we know what the qubits represent?

Are they entanglement?

Just units of entanglement or
are they data containing photons?

So there's so many variables that we
haven't even agreed upon on the physical

layer and the link layer that we can start
moving up to routing, for example, but.

Even though that's the case, it's
still interesting to look at, okay,

if, let's assume we have all that
for free, how do we do routing?

So some people do focus on the upper
layers of the network, even though

it's not clear what's underneath.

So we're building on a rocky
foundation, but you have to

start from somewhere, I think.

So I don't see it as a bad thing either.

Dan: It sounds like there's a lot of
uh, I call it conjecture, I guess,

or maybe just people having a go
at a particular niche without the

solid foundations underneath them.

Maybe there's a need for some kind of
uh, coordinated community type thing.

But first of all, you know, are
there enough simulation engines out

there to fulfill all these needs?

So you mentioned a lot of the
hard, different hardware models

when it comes to simulation.

It sounds like it's a a smorgasbord of
different simulators out there, right?

And how does that look?

Steve: Yeah, it's a bit messy, I'd say.

So there's definitely a popular
quantum network simulators.

And then I say there's a scattering
of one off simulations that people

have developed that do one particular
thing or potentially do some subset of

things that another simulator can do
in a restricted setting, particularly

for performing one particular task
or a few particular tasks that were

interesting to the authors of that.

So the environment is a bit messy.

So I would say there are enough engines
to start building a centralized platform

for doing quantum network simulation.

I think we cover a lot of the
aspects that need to be covered now.

It's about using those engines.

Unifying those engines into a
single platform so that, we don't

start reinventing each time we
need to do a new simulation.

So usually what sometimes happens
is you have a problem to solve,

a network problem, then you
see, okay, what can I simulate?

I don't know how to use the simulator.

Let me just, it's too hard.

Let me just make my own simulation.

I just need to simulate a small piece.

Okay.

Now we haven't integrated that
feature into the simulation engine.

So the next person who needs to do that
simulation has to start from scratch

again, and that's a shame because these
people spend time and energy making

simulations, but they don't contribute to
the open source because well, one reason

is they're not open source to begin with.

So a lot of the features that people
want don't get integrated to the engine,

just makes people like waste, waste
their time reinventing different pieces.

So the engines have a good foundation.

There are enough of them
and they're good, right?

That they can do what they need to do.

Now it's about allowing
people to contribute more.

We can't restrict these engines to
small groups of people to contribute

to, it gives them too much.

Responsibility.

So they fulfill the
needs to be expanded on.

That's what I want to say, but they
don't fulfill the needs of everybody.

Dan: Yeah, that makes sense.

You were talking previously about some
network protocols that are out there

for execution, like the QKD protocols.

Are there any protocols
out there for entanglement?

Yeah, it sounds like there isn't.

Other than the modeling of what
an entangled EPR pair looks like.

And, but I guess if you're hosting
one in one device and one in the

other, then there's some modeling
required on both systems, right?

Steve: There's, so I would say the QKD
protocols for network simulation and

in general, just deploying QKD, those
protocols are pretty well established.

Now, like you said, we're in
the early stage of developing

entanglement distribution protocols.

I'd say there has been some success.

For example, there was a paper, I think,
was it last year, early last year, where

they've taken an entanglement distribution
protocol and implemented it to do one

repetition, or one quantum repeater.

That came from TU Delft and Q Tech.

And so they started with a link layer
protocol, pen and paper, simulated

it in various settings, and then they
actually put it to the field test.

So they've gone through one
like mini life cycle for that.

But I would say this is not
a standardized protocol.

I think it's very much hardware dependent
for their specific hardware configuration.

There have been other quantum
repeater experiments from there.

Not many, but I think there's
been one with ion trap.

Where I know it in Netherlands,
they're using NV center.

So the protocols probably are
slightly different, but it's progress.

It got to start from somewhere.

And I think it's interesting to see
that they've used a pen and paper

solution, put it into simulation,
using their simulation tools, and

then they were able to field test.

Yeah, but other than that, it's
not so clear what's happening.

So we've also worked on a little bit of
simulation for this kind of coexistence

quantum network where you send classical
and quantum over the same channel.

There it's, it's not like, uh, it's still,
I would say in a pen and paper solution.

We're just getting to
the simulation phase.

And now, we've succeeded in simulating
a few different applications.

QKD, for example, potentially we're
going to move to a field test.

But yeah, it's a it's all
very new but it's happening.

Dan: Yeah, it's promising as well but I
guess it's a bit like quantum computing

in a way that it's hardware dependent and
the simulator is always going to be, it's

got to simulate hardware of a specific
type in a particular configuration.

yeah, and in computing, you
have different modalities here.

We've got, different hardware
interfaces and so on.

Steve: I would say especially
towards what's missing is The

protocol development language.

So at the moment, there's no standard
for writing quantum network software

quantum network control software
That's a big missing component.

So we can write these entanglement
distribution protocols QKD protocols

Whatever protocol we need, but there's
no universal way to write that protocol.

It's okay.

Pen and paper is theory.

That's fine.

It's English.

That's almost a standard.

But if we want to take someone
else's protocol and deploy it

in our system, there's no easy
way to do that at the moment.

That's a big missing piece.

I think so that's something that the
community needs, we have languages in

classical networks that you can open, you
can download, run it on your own system.

There's no guarantee that if you
download someone else's control

software for quantum, that it's going
to work to your system because it's

like very hardware specific, very much
not at that layer of abstraction yet.

Dan: Thanks.

Maybe that leads us on nicely to , the
work you've been doing with uh, QNetLab

Steve: okay, so q net lab is the
idea that take all these problems

I've been talking about lack of
community lack of open source.

And now we're trying to solve
this problem by unifying the

ecosystem that exists today.

So what we're hoping to do with this
platform is one, make it much easier

to write quantum network simulation.

So at the moment, it's a
lot of software development.

A lot of software knowledge is needed
to write quantum network simulation.

So you need to be able to code quite well.

And also we want to make sure
we're not reinventing every time

we want to write a new simulation.

So we need a place for sharing code
and sharing previous simulations

so that people can build on.

So that's what we're
working on at QNetLab.

We're looking at making a community,
sharing code, sharing simulations,

unifying the engine ecosystem and, making
it easier for people to write simulations.

And so what we're doing is starting with
a basic thing, and that is making an

interface to quantum network simulation.

So I can I'll go right into
that a bit more deeply.

Maybe there's a question in
between from what I've said so far.

Dan: Well, I guess let's, let's,
first of all, talk about people

who would want to use the QNetLab?

You mentioned contributors,
developers is it a broader, is

it a broader scope than that?

Steve: Yeah.

There's a bit of a split between who
I see are the users of this platform.

And there's people there's people
who know how to write code.

And they can write a lot of code
and write a lot of network code.

But they don't know anything
about quantum networks.

And they might not have time to learn
everything about quantum networks

and each of the hardware components.

To start modeling, their simulation and
adjusting the parameters because they

just don't know what's a quantum source.

What's a detector.

How does the detector work?

So they don't want to learn
that, but they can write code.

And so what this platform allows is.

Okay, you can start a simulation.

You don't need to know the
hardware components because we

provide the interface to them.

You can adjust them as you
need, but you don't need to know

where they sit in the network.

They just will appear when they're needed.

So that's one piece of user.

Then there's the flip of that.

There's people who know
how to do quantum networks.

They know how to write They know what
exists in a quantum network, what hardware

components are there, how they work,
but they don't know how to write code.

And now that's another problem, right?

So how do they write the simulation?

They don't know how to write code.

And that's what we see as an initial user
of our interface that we're working on.

So what we'd want to build within the
QNetLab project is a, an interface.

And this is where we see we
can help both of those users.

And this interface is a graphical
interface, which has a lot of

features that make writing a
quantum network simulation easy

for both of those user groups.

That's one thing.

So that's the one set of users
that potentially use our interface.

The second set of users are people
who are looking for community and

building on other solutions so that
they can invent new technologies.

So maybe they both, they know both
coding and quantum networks, but they

are looking to do some novel research.

So what we can do is provide a place
where people can upload their simulations,

which can be extended or, re evaluated
across other network settings.

So people can download the protocols,
change the network, see if the protocol

still works, make any changes they
need, and we make things stronger.

So to summarize, it's basically people
who are interested in writing quantum

network simulations but don't have all
the skills for it, And then there's the

people who want to do novel things with
quantum network simulation, but don't

want to start from scratch every time they
want to do something new, or start running

their own libraries to start building
on, which could take a lot of time.

So we want to, yeah, allow people to
put the building blocks together, and

people can take what they need to start
from a midway instead of from scratch.

Dan: Okay.

So yeah, that gives us an idea of the
different building blocks, when it comes

to the configuration of the protocols.

Is it is the system as it is just for QKD.

What about entanglement distribution
that we discussed earlier on?

I know we were talking about the
fact there isn't really a protocol

for it, but does it have the
tools in the box to, to support.

support that because the, this is
where we're looking at the more kind of

futuristic and where most of the research
and modeling and simulation, will want to

be um, built up right in, in due course.

Steve: Yeah, so what we do is, when I
talk about quantum network protocol,

what I mean specifically is, basically
a list of actions on these devices.

So that would mean, step one trigger
the quantum source to emit something

when it emits something modulated
to be in a particular state, then

that state goes through the channel.

It arrives at another person.

And that person acknowledges that
it arrives, they modulate, they

measure, they do something else.

So it's always just like hardware
triggers most of the time.

And therefore, what we can do is we can
make this platform completely general.

There's no specific use case that
it supports and there's no specific

use case that it doesn't support.

It's just a series of instructions
for the hardware components.

To that form of quantum network.

So what we do is we want to provide
the building blocks, like I was saying.

So what we've done is we've programmed
QKD simulations, we've programmed

entanglement distribution simulations.

And now what we do provide those
source codes, those protocols, there

may be not the final protocols,
but they're starting point and know

what people can do is download them.

And then run them immediately.

So they have to write zero code to start
writing, running those simulations.

And then they'll test them, they'll
see, okay, does it work in my setting?

No, it doesn't work.

So I need to add more.

And now what we'll do is building
up on these protocols, step by

step, making them more robust.

And it's usable for everybody.

The way we do that now is it's
unfortunately just a Python code.

It's unfortunate because it's not a,
that's not a network programming language.

Python is for simulation only, but we
can see, okay, what are those instruction

sets, and we can potentially translate
that in the future to something more

universal, but at least it's there, right?

So we know what the instructions are.

We don't have to write them from scratch.

People can agree on them.

They can branch, they can change them.

They can modify them.

And now we're, we're working together.

We're not working alone.

Dan: so that that's grand.

It's, it's the foundation of
all of the tools you need to

do the physical layer modeling.

And to get you started, right?

To get you started quickly without
needing to do a lot of the fundamental

coding and things which other people
have been doing repetitively and in

their own labs, in their own domain.

Okay I'm thinking about use cases, and
I'm thinking about quantum computing

naturally being one of the use cases
that's obviously touted and, we've

discussed at length in previous pods
about how likely and how difficult that

is but I'm keen to know, is the capability
there inside QNetLab for connecting into

quantum computing simulators or connecting
into quantum computers at some point.

I guess there's no standard methodology,
but what would you say to that?

Steve: Yeah, so the way we've designed the
quantum network lab and the specifically

our quantum network development kit is
that we Use a we want to use a universal

language firstly to write the protocols
at the moment that universal language

is Python based Of course, we want to
evolve that to be a networking programming

language at some point So what we do with
this interface is we collect all of the

network parameters, the protocol logic,
and then we send that off to our server.

Our server compiles specific network
simulations for each of the engines.

This is the interface between Basically,
network parameters and simulation code.

The simulation code executes and
then we get the results back.

But this process is a bit tricky
because each simulation engine works

differently and the simulation code
themselves works much differently.

Sometimes even the design of the
simulation engine works in a way

that's not aligned with the others.

And sometimes we can't even support
some of the engines that exist today.

so in the future, what we can do
is, we can definitely connect to

quantum computing simulation engines
or quantum computers themselves,

because all we're doing is collecting
protocol logic and parameters.

Okay.

But if we exclude the parameters,
then we just use the parameters

of the quantum computer itself.

So what that leads to is a
virtual quantum network, some

kind of like a virtual network.

Virtual quantum network that you
can program in the cloud with access

that goes directly to the hardware.

So you're still using the same interface
to collect your protocol logic.

Potentially some of the components
are simulated, some of the

components are not simulated.

And you can pick your hardware
parameters accordingly.

You send that off to the cloud,
cloud will take all those components,

put the pieces together for you.

If it goes to a simulator, if it goes
to an emulator, if it goes to physical

hardware, user doesn't know, all
they do is they collect the outputs.

They should know, I think if they,
I think it makes it more valuable

to know that your simulation
works in a lab, for example.

So that's leading to a future
vision of what the QNetLab

and the QNDK is going towards.

Dan: Yeah.

And that leads, that leads
onto the roadmap question.

But before I do that, I'm just
going to throw you a curveball.

In terms of modeling behavior of photons
and the, all the different stages in

transmitting and receiving photons
that you mentioned earlier on, is it,

do you think it'd be possible to use
some of the components in the core code

there to simulate photonic computing?

Or is that a totally
different, separate world?

Steve: Yeah, I think, okay, before
we, I answered that question, there's

another thing that we want to support.

And that is when a hardware provider
comes up with a new piece of hardware,

because what we do is we're modeling
hardware in the simulation, we want

to be able to import those parameters
directly into the simulation.

And what that means is, let's
say Cisco comes up with a new

quantum memory, we want to support
that model in our simulation.

So we, we place a quantum memory
in the simulator, and then

we can import the settings.

directly.

So that means the users don't
even need to know how to model a

quantum memory in the first place.

That's one thing.

So when it comes to novel technologies
like photonic quantum computing,

potentially we can do it, but this
particular project is more focused

on Moving quantum states through
a network where photonic quantum

computing is in a sense that, if you
take it into a local environment.

So you do have to do some qubit routing,
but there's no, I think there's no stack.

It's mostly about, moving the
qubits where they need to go in

order to perform a mathematical.

computation.

But but potentially what we
could do is lead the photons to

that hardware model, import the
computation into that node based on,

whoever's providing that, that chip.

And then, the photons arrived,
they go through that system.

So I can see it being possible if we
have the access to, hardware models that

companies are providing because it's.

At the end of the day, it is a
routing problem, or it is a network

problem, but at a smaller scale and
potentially if we do like distributed

photonic quantum computing, then we
do need that network stack as well.

So it's it's possible.

I think it's interesting to see
where it's going to go, but the

hard part is we can't do it alone.

That's for sure.

There's so many things to consider
so much code to write that.

The small team that we're working with
is we need the open source, we need

the community and we need to know do
people want those features so we're not

writing always a software for ourselves.

Dan: Okay.

First of all yeah, it probably
wasn't fair of me to try and create

some parallels between photonic
computing and what we're doing here.

But I can see, yeah, you answered
that perfectly by by talking about

ultimately the interconnects potentially
between them and other systems.

when it comes to open source, so
tell me what's needed and you

know, the open source community.

. Is extremely broad it's been around
for a long time to cover all different

types of software development domains.

Is there a community you think
already that will latch into this or

is it about building it from scratch
and what are we putting out there?

That's, really to support community
of people wanting to work on

quantum networking simulation.

Steve: Okay.

All right.

So the QNetLab platform is,
it's not open sourced yet.

We're still putting it into the
basic state that we can start

opening up to external collaborators.

We're starting to talk to people
about, how this platform should work,

how, what problems should it solve?

What are the pain points that people
are facing when they want to work

on quantum network simulation.

So we want to at least set up the
foundation so that we can start

allowing people to collaborate,
make sure that we're not,

starting from the very beginning.

We want to at least set the
vision and set the trajectory.

And then we can open up and start
allowing external collaborators.

The question is, are there
external collaborators?

I think, yes, there are, especially as,
more interest goes into quantum networks.

So what are they going to do?

How do they work?

And we're seeing it pop up much
more often than it was five years

ago when the simulation platforms
just were getting kicked off.

So there's a community,
I think, ready to jump.

It's just, where do they get their,
where do they put their efforts into

and their other, there's not like we're
the first ones to think of this, there's

other projects specifically the quantum
network Explorer project, and there's

a community there working already.

What we're trying to do
is expand that community.

And make it easier for people to
contribute and potentially contribute

on a project that allows them to do
more or more that they're interested

in specific, more general topics.

And so another motivator for us is if
you look towards quantum computing,

it's not exactly an easy analogy
to make because quantum computing

appeals to more people, I think.

Because, a lot of people come
from computer science background

and the physics involved as
well, machine learning aspects.

It draws a lot of attention because
it has more closely related things.

Not as many people do networking as
computing, I think, and algorithms.

But anyway the community around
quantum computing software is huge.

If you look at what Qiskit has done, if
you look at some of the projects like

Unitary Fund there's a ton of projects
and they're very successful and they're

all open source and they've managed.

To, lead the way in terms of
inventing new software for quantum

computing, new algorithms, allow
people access to quantum computers.

And it all started from basic core
aspect of we want to open source

some quantum computing software.

I think Qiskit probably started
off as a basic circuit simulator

and now look at it today.

So you need to start from something
small enough to set the vision and then

it'll grow naturally as long as it's
a good project and well maintained.

Dan: So what's the ask to the community
to get involved to contact you to

what's the next step that they should
take to to educate themselves more

on what's on the horizon with this.

Steve: Yeah, I think so what we've had
so far is we've worked on the interface.

Interface is working as a prototype.

We can start collecting user feedback.

And that's what we're asking first.

Primarily is we want user tests.

So people who are interested in quantum
network simulation getting involved.

We want people to test our product
and see if it solves their problems.

And second, we need some
contribution to the vision.

What's missing?

What can make, what could be better?

How do we align it towards, like I said
the classical network simulation engines

that have been very successful in, helping
set the standards of the internet today.

So we want that too.

We want feedback.

How do we make sure that we're not,
going in the wrong direction again?

How do we make sure that we're
working towards developing a

quantum internet quantum network?

Is this the tool that's going
to solve it or something else?

So it's mostly a feedback
session and vision setting.

We're probably in the next six months
though, for sure we'll be looking

for code contributions as well.

So maybe we'll, there'll be some
announcements when we finally

go open source with the project.

And that would be looking for
support from external with

regards to software development.

Dan: Great.

Yeah.

So if you're listening and you're
interested in getting involved and

watch this space, feel free to reach
out to Steve or I at Cisco here.

And we can start to have those early
stage conversations and go from there.

So I think I'll wrap it up, Steve.

Thanks very much.

Steve: Yep.

Thanks for the interest.

Dan: yeah, indeed.

Okay.

Then I'll close it there.

Thanks very much.

Bye

Steve: All right.

Thanks.

Dan: I'd like to take this moment to
thank you for listening to the podcast.

Quantum networking is such a broad domain
especially considering the breadth of

quantum physics and quantum computing all
as an undercurrent easily to get sucked

into So much is still in the research
realm which can make it really tough for

a curious IT guy to know where to start.

So hit subscribe or follow me on your
podcast platform and I'll do my best

to bring you more prevalent topics
in the world of quantum networking.

Spread the word.

It would really help us out.