Over the last several months I have been working on
the Project Apollo metaverse-server for the Vircadia project.
The Internet is awash in virtual world projects – both small and large.
Because of this, I have been thinking lot about this project and why I would
spend any time on Yet Another Virtual World.
This captures some of where I think Vircadia could go to be a
growing and interesting addition to the sea of virtual world technologies.
First, what is Vircadia?
Vircadia is a volunteer, open-source, virtual world server and viewer project
based on the High Fidelity code base.
A small collection of interested people have pulled this code dump into
a project and a community that chats, plays trivia games, and watches movies
together while working to improve the code and content of the virtual world.
The goal is to make a free, open-source, distributed, and non-corporate owned
virtual world that could be useful for education, training, meeting, and socialization.
The community and their passion for this particular virtual world technology
keeps the project alive.
I have spent years working on the OpenSimulator virtual world technology.
and more recently on my
Herbal3d and Basil viewer projects.
These are all for virtual worlds and the communities they create.
I have watched OpenSimulator putter along with hobbyists running their
own virtual world grids and small communities enjoying the ability
to socialize and hyper-grid/teleport among the many worlds.
But, in general, OpenSimulator never grew beyond its SecondLife
dispora and the project has dwindled over time.
It’s still alive and interesting, but it is not making a new and interesting
addition to the virtual world ecosystem.
I got involved with Vircadia because of the great people and
they needed some server-side software and that is one of my interest areas.
But, now that I’ve invested in this project, I don’t want it to
slowly die as people move on and/or just get lost in the virtual world
sea of projects.
There is the “marketing” direction which consists of building
communities and finding creators and applyers (like teachers or trainers)
to increase the number of people using the project.
But I’m more of a tech person so I see some technologies to focus
on in Vircadia development that would attach it to other
technology focused communities and grow and enhance its application.
The goal of these directions is to attach Vircadia to other
like-minded technical, volunteer, and passionate communities.
So, the two directions I’d like to help Vircadia go in are:
- develop the technology for a decentralized virtual world community, and
- generalize the virtual world viewer for new and different rendering engines.
Let’s talk decentralization.
One of the main motivators of the Vircadia project and many other
hobbyist and open-source development projects is the idea of creating
a non-centralized service/application/resource.
And by “centralization” most think of the large, ad-based concentrators
like Google or Facebook.
So, by “decentralization”, most projects want there to be no single
owner of all the data, no single one place everything is stored, and
no one place that is necessary for the project to exist.
I feel like there are two approaches to this “decentralization”:
1) decentralized storage and linking and 2) decentralized infrastructure.
“Decentralized infrastructure” is where multiple people host a common
infrastructure and the service/application is spread across these hosts.
So, like Tor or BitCoin, the service is not in a single location but
it spread out across multiple hosts so, one host going down or being
compromised, does not stop the service/application and no one entity
holds or owns the service/application.
“Decentralized storage and linking” is where multiple people host their
own stuff (no single owner or storer) and there are conventions for
naming, addressing, and fetching content and services.
In this case, data is spread out across the Internet and
availability and access is arranged and controlled by the source
of the data or service.
“Decentralized storage and linking” is more about linking together
smaller island while “decentralized infrastructure” is more about creating
one large island.
Both of these have their excellent uses but, for creating a set of virtual
world communities, I’m leaning more toward the original inter-net, web
focus of tying communities together.
Hope you’re still with me here.
“Decentralized storage and linking” is the original design of the
World Wide Web where everyone hosted their own site and there were
hyper-links to get from one hosted resource to another.
W3C is the World Wide Web standards body that carries on
this architectural direction and has recently published several
“social community” standards which enable applications for
decentralized social communities.
These are the standards ActivityStreams and ActivityPub which
support social sharing services like Mastodon, PeerTube, and
The model presented by ActivityPub is of actors that have
“streams” of “activities”. Thus, a person can have a newsfeed,
a community could have a stream of newsletters, an event could have
a stream of events, and a myriad other combinations. The standard
allows for publishing and subscribing to streams.
This creates a collection of hosts that are created for an interest
area, a community, or just for fun and the hosts exist for as long
as the hoster wishes. There is no central control or ownership.
Just interested and passionate individuals.
This architecture is useful for Vircadia for two reasons:
- It matches how I see developer based virtual worlds growing – as small hosted “grids”, and
- Linking the “girds” together with an existing socialization standard pulls the community
into a larger socialization world of like-minded developers and users.
So, how do I see this playing out?
I see the continued development of a metaverse-server to act as the center of a “grid”
of virtual world spaces (“domain-servers”). This metaverse-server would provide
the services to tie this collection of virtual world spaces together –
account creation, storage, and permissions, domain-server registry and discoverability,
and any cross-domain communication).
This provides the basis for anyone to create their own, independent virtual world.
Then, adding to this, extending the metaverse-server with an ActivityPub
interface. For multiple grids, this allows the grids to share some
account identity/profile information, have interest groups that span grids,
have conversations that span grids, and other sharing.
For wider usage, one could use existing ActivityPub based tools to share
and communicate with users in the virtual worlds.
For instance, use Mastodon to chat with or check the presence of people
in the virtual world.
Or use one of the many gateway applications (like ActivityPub to Discord)
to connect between social groups and virtual world groups.
One way of looking at it, this makes [Vircaida] the virtual world extension
of ActivityPub or maybe the virtual world version of Mastodon.
Check out The-Federation and Fediverse.Party for some of the other
federation-based, decentralized communities.
Generalize the Viewer
This was all about the socialization side of Vircadia, but what about
There are many people very passionate about the technologies and devices
for viewing virtual worlds.
The existing viewer is a custom C++ engine. It combines world logic
(avatars, location, scripts), with simulator interface (TCP and UDP
communication), with the rendering engine (and the interfaces to all the
different VR devices).
A presentation by Sam Gateau (the High Fidelity core engine team lead)
suggests the rendering part of the viewer is separated from all the world
logic by a scene representation that is acted on by “transactions” that
come from the world logic.
This gives a good beginning to separate the virtual world logic from the renderer.
So, what I’m suggesting is that the interface between the “scene” and
the world logic (the “transactions”) be formalized and refactored to
make code pieces separable.
Then, the project could go in different directions.
The rendering engine could be replaced (some people have suggested that
the Unreal Engine is a candidate).
Or, building on my Herbal3d architecture ideas, build a system
where multiple world logic interfaces can talk to the same renderer
and thus allowing viewing multiple virtual world systems with
the same viewer rather than requiring a different viewer for
each virtual world.
I believe that by adding an interface to existing and growing
distributed social network systems and by separating the renderer pieces,
the Vircadia project can attract many new developers, users, and
advancers and live on as a vibrant community.
Well, that’s way too much typing. Back to coding.