gemini-capsule

My gemini capsule
git clone git://jb55.com/gemini-capsule
Log | Files | Refs

commit 82bee29937a7da31d57b472f95adad8cc5e16995
parent 4c04f67caf14f170570110fa8ca22e0ab27eadcd
Author: William Casarin <jb55@jb55.com>
Date:   Mon, 12 Jul 2021 15:36:12 -0700

protoverse post

Diffstat:
Mcapsule/2021-07-12-protoverse-metaverse-protocol.gmi | 23+++++++++++------------
Mindex.gmi | 8++++----
2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/capsule/2021-07-12-protoverse-metaverse-protocol.gmi b/capsule/2021-07-12-protoverse-metaverse-protocol.gmi @@ -1,8 +1,8 @@ # protoverse, a metaverse protocol experiment -Ever since I read the book Ready Player One I've been fascinated by the idea of the metaverse. Imagine instead of joining an IRC chatroom, you joined a virtual room with objects: chairs, tables, robots, other people. A virtual shared space where you could meet up with your friends and hang out. This is typically envisioned as some sort of virtual reality where you meet with people face to face, but the metaverse could be much more general than that. +Ever since I read the book Ready Player One I've been fascinated by the idea of the metaverse. Imagine instead of joining an IRC chatroom, you joined a virtual room with objects: chairs, tables, robots, other people? A virtual shared space where you could meet up with your friends and hang out. This is typically envisioned as some sort of virtual reality where you meet with people face to face, but the metaverse could be much more general than that. -I started thinking about what could a metaverse protocol look like? Is such an ambitious project even possible? How do we avoid the mess that is the web? Could we keep it simple and extensible? I believe I have a pretty good plan on how to achieve this, I'm calling it the protoverse. +I started thinking about, what could a metaverse protocol look like? Is such an ambitious project even possible? How do we avoid the mess that is the web? Could we keep it simple and extensible? I believe I have a pretty good plan on how to achieve this: I'm calling it the protoverse. ## Goals @@ -18,7 +18,7 @@ Before we start thinking about the ingredients needed to build a metaverse proto ## Enter the protoverse -The protoverse is the metaverse protocol I'm working on that is trying to achieve all of these goals. At a high level, protoverse is a network of abstract virtual spaces. It achieves this with a few key ideas: +The protoverse is the metaverse protocol I'm working on that is trying to achieve all these goals. At a high level, protoverse is a network of abstract virtual spaces. It achieves this with a few key ideas: ### Level of detail @@ -45,7 +45,7 @@ You define a "space" with a high-level description like so: (shape circle)))) ``` -When you first connect to a server, you pull this high level description to quickly get an idea of where you are and what types of entities are in the environment. The server could dynamically generate this high-level description or it could be static. This "space" is analogous to html documents. So far so good. +When you first connect to a server, you pull this high-level description to quickly get an idea of where you are and what types of entities are in the environment. The server could dynamically generate this description or it could be static. This "space" is analogous to html documents. So far so good. At this point, if there is a more detailed description of the room, the client could start pulling additional texture and model information via protocol messages. @@ -61,18 +61,17 @@ $ ./protoverse client proto://localhost Output: -> There is a clean and shiny rectangular room made of solid gold named Satoshi's Den. It contains four objects: a welcome desk table, fancy chair, throne chair and ceiling light. +> There is a clean and shiny rectangular room made of solid gold called Satoshi's Den. It contains four objects: a welcome desk table, fancy chair, throne chair and ceiling light. As you can see, in this case the client simply parses the high-level description and outputs a description of the room. More advanced clients could render a 2D representation of the room, and even more advanced clients could render full VR-capable experiences. ## Programming the protoverse -To support a wide variety of experiences, we need some concept of computability within the metaverse. This would be the analog of javascript from the web. The protoverse uses WebAssembly (WASM [1]) to enable computation for clients interacting with the metaverse. WASM was originally devised as a generic virtual machine for the web, but it is general enough to use for cases beyond -that. +To support a wide variety of experiences, we need some concept of computability within the metaverse. This would be the analog of javascript from the web. The protoverse uses WebAssembly (WASM [1]) to enable computation for clients interacting with the metaverse. WASM was originally devised as a generic virtual machine for the web, but it is general enough to use for cases beyond that. -With WASM you can use any programming language to code the metaverse. protoverse comes with an embedded WASM interpreter that can execute WASM code. You will be able to augment clients to render your space in greater detail, show HUD elements, create multiplayer games, etc. +With WASM you can use any programming language to code the metaverse. Protoverse comes with an embedded WASM interpreter that can execute WASM code. You will be able to augment clients to render your space in greater detail, show HUD elements, create multiplayer games, etc. -You can already do a lot without client computation, for instance, your space could be served dynamically, which you could periodically fetch to get updated description of the room. This would be equivalent to "refresh the page" on the web, except due to the level-of-detail nature of the protoverse, you wouldn't need to refetch the entire room. The client could cache models and other details that have been previously fetched. +You can already do a lot without client computation. For instance, your space could be served dynamically, which you could periodically fetch to get an updated description of the room. This would be equivalent to "refresh the page" on the web, except due to the level-of-detail nature of the protoverse, you wouldn't need to refetch the entire room. The client could cache models and other details that have been previously fetched. The default, high-level description of the room could include position information, so you will be able to see things that have moved when you "refetch" the state of the room. State updates like this could be a bit jarring, so most likely you wouldn't want to reload the room for position updates, these can be served via "object state/position update" network messages. @@ -80,15 +79,15 @@ What you do with these network messages could be handled automatically for simpl ## Thin clients -Thanks to WASM, we can offload much of the rendering to WASM code that chooses how to render its environment. This does affect accessbility, so we need to be careful, but it does have the benefit of avoiding a huge pain point of the web: the massive growth of specifications required to implement web functionality. If we have a very thin client with a small set of rendering APIs (Vulkan? Curses?) Then protoverse servers can provide any experience it desires. It could serve full multiplayer video games! +Thanks to WASM, we can offload much of the rendering to WASM code that chooses how to render its environment. This does affect accessibility, so we need to be careful, but it does have the benefit of avoiding a huge pain point of the web: the massive growth of specifications required to implement web functionality. If we have a very thin client with a small set of rendering APIs (Vulkan? Curses?), then protoverse servers can provide any experience it desires. It could serve full multiplayer video games! ## Interconnection -I still have more to think about with respect to server-to-server communication. I think there is some interesting potential here. For now the protocol only cares about client to server communication, such as updating entity positions, etc. I think it makes sense for there to be a variety of server-to-server protocols for something like the metaverse, I just haven't thought too deeply as to what those would be yet. +I still have more to think about with respect to server-to-server communication, but there is some interesting potential here. For now, the protocol only cares about client to server communication, such as updating entity positions, etc. I think it makes sense for there to be a variety of server-to-server protocols for something like the metaverse, I just haven't thought too deeply as to what those could be yet. ## Conclusion -The design space for metaverse protocols is huge. I would love to brainstorm new ideas and how I could improve the protoverse. If you have any ideas feel free to send your thoughts to the protoverse mailing list at: +The design space for metaverse protocols is huge. I would love to brainstorm new ideas about how I could improve the protoverse. If you have any ideas feel free to send your thoughts to the protoverse mailing list at: => https://lists.sr.ht/~jb55/protoverse-discuss diff --git a/index.gmi b/index.gmi @@ -6,6 +6,10 @@ |__/'s gemini capsule ``` +## Gemlog + +=> ./capsule/2021-07-12-protoverse-metaverse-protocol.gmi 2021-07-12 - protoverse, a metaverse protocol experiment + # Welcome Welcome to my Gemini capsule. I will most likely be moving away from my gopher hole to this. gopher is brutal to read on mobile, this is where the gemini protocol really shines. Gemini adds some TLS latency but it is bearable. @@ -14,10 +18,6 @@ Welcome to my Gemini capsule. I will most likely be moving away from my gopher h => projects/index.gmi Projects => notes/index.gmi Notes -## Gemlog - -I don't have any gemlogs yet, check back soon! - ## Updates => notes/physics/dirac-equation.gmi 2021-04-25 - Notes > Physics > Dirac Equation