20220601 How To Build A Metaverse - orbitalfoundation/wiki GitHub Wiki

WORK IN PROGRESS

How to build

How to build Open Source

  • how do we build in the open?

  • how: traditional development practices

  • differences between open dev and closed dev

  • curating a community; building, rewarding participation

  • high level vision

  • low level vision - technical engineering choices

  • scheduling, shipping

  • recruiting participation

  • distributing power

  • shipping

  • small steps, iterate, all stakeholders see work

  • https://brandur.org/small-sharp-tools -> "The mistake we made was that although each service was kept fairly simple with the separation, the sum of their complexity was much greater than that of the integrated system. Despite being less sound from an idealogical standpoint, the monolith could be improved more quickly, operated more easily, and could better guarantee data consistency."

What not to build

Other efforts

What to build

  • "we are not building the metaverse, we are discovering it"

  • consumer perspective:

  • similar to a web browser

  • seen as a user interface or a desktop that runs many apps at once

  • a communications tool, a sense making tool, an entertainment tool

  • probably has some built in concepts for manipulating objects; effectively a kind of desktop paradigm

  • multiplayer

  • can paint 3d graphics as well as 2d graphics

  • probably improved identity concepts

  • probably improved payment concepts

  • often related to place and space but not always

  • easy to create and share apps

  • apps paint to the same display, not to separate windows, and share the same model of the world

  • probably has some generalized thinking about noise filtering, anti-harassment and healthy conversation

  • engineering perspective:

  • an operating system and a 'desktop'; users can load and run, start and stop 'apps'

  • apps can message each other

  • apps are built out of shared libraries

  • apps can rely on a persistent state server and networking

  • apps are carefully sandboxed

  • probably distributed rather than a single silo approach; protocol based agreements between compute instances

  • meta verse

CONSTRAINTS

  • zero global compile as a constraint -> the environment is the editor -> real time editing, real time collaboration -> see https://www.pawfal.org/fluxus/

  • can run code:

  • late binding, portable computation

  • inter application communication

  • distributed computation

  • security safety

  • portable execution

  • composability, granularity of assets at runtime; minimize compilation and baking

  • late binding dynamically loaded behavior

  • formal messaging models

  • zero code creativity as a constraint

  • revision control of dynamically loaded objets

  • elevated perms, security, privs, bad actor curation -> effectively as simple as text, granular, social, dna, atomicity

FRUSTRATION POINTS

  • utter simplicity; bevy3d and other systems are astronomically way too complex - can an 8 year old code in bevy?

  • hard to extend

  • hard to communicate

  • hard to understand

  • slows development

  • prevents collaboration

  • makes cross cutting concerns such as say piping a video feed into the system very hard

  • pretty much impossible to integrate other services; say a third party ux

  • unreal is also an absolute nightmare for example; hermetic, insanely complex, poorly documented, fragile

  • zero compile

  • i don't want to spend even one minute to recompile a build to test an idea

  • i want interactive real time editing

  • traditional build systems are even worse than this; unreal can take many minutes to test/iterate an idea

  • the poisonous idea of necessary compilation has even leaked down to web pages with webpack and npm recompiles

  • velocity

  • coming from the web i'm used to a high velocity of iteration

  • a few seconds to refresh a page to try a new idea

  • sharable;

  • i can paste a url to somebody and they can try my idea out

  • no binary blob that has to be downloaded and then installed; basically instant

  • no licensing and app signing

  • no begging apple for permission to ship my app on their device

  • no navigating operating system versioning, packaging and distribution conflicts

REQUIREMENTS / FEATURES

TECHNOLOGY CHOICES

NOTES