added network page

This commit is contained in:
Emma Tebibyte 2022-08-22 19:08:19 -04:00
parent 206ae54943
commit c090bb57c2
2 changed files with 99 additions and 15 deletions

View File

@ -9,10 +9,94 @@
<meta content="width=device-width, initial-scale=1" name="viewport" />
<meta content="interest-cohort=()" http-equiv="Permissions-Policy" /> <!-- FUCK GOOGLE -->
</head>
<header><img id="logo" src="/assets/img/TiB-network.png" width=25% style="vertical-align:top" />
</header>
<body id="network">
<header><img id="logo" src="/assets/img/TiB-network.png" width=25% style="vertical-align:top" /></header>
<nav><h4 style="text-align: right"><li class="home"><a href="/">Home</a></li> | <li class="network"><a href="/network">Network</a></li> | <li class="blog"><a href="/blog">Weblog</a></li> | <li class="about"><a href="/about">About</a></li></h4></nav>
<p>
Tebibyte Media's <i>raison d'être</i> is its Network. Our goal as a
Project is to foster the creation of that Network by extending
connections of solidarity between project who share the values we
believe are important in the new digital age.
</p>
<h2 id="specification"><a href="#specification">Specification</a></h2>
<p>
Tebibyte Media is composed of two distinct parts: the Network and
the Project. The latter is made up of myself, the individuals I
have recruited into the Project, and the infrastructure which supports
it; the former, the constituent projects and networks which are
associated with the Project. This distinction exists in order to
maintain an appropriate separation between the interests of these
entities to preserve the heterogeneity of these communities.
<br>
Like the components defined above, the members of the Network are
split into two separate categories:
<br>
A "project" in this context is an entity whose constituents are
individuals; a "network" is one whose members are projects
themselves, or a mix of projects and other networks.
<br>
A Tebibyte Media "project" does not necessarily have to be
a free software project; it can be anything involving strong
public engagement and iterative development. For example, a
post-modernist fiction-writing blog can count as a Tebibyte
Media project, as long as the work is ongoing and the blog is
shared at no cost to its readers.
<br>
A "project" could be an open writing publication requiring
attention or third-party reviewing, a free software project
looking for a userbase and pool of talented developers, or an art
project looking for exposure and contributors.
<br>
A "network" might be a webring, an online social hub for the
advancement of some idea or combined agenda, or an organization
which has multiple distinct components or internal projects but
which still works toward one main goal. A webring whose
constituents are all blogs that focus on physics would be an
example.
<br>
In the case of members creating new networks internal to Tebibyte
Media's influence, we take it upon ourselves to mediate and foster
that connection; we see these novel networks as partially our
responsibility.
<br>
Every project in the Network will be represented by a single person
who will be appropriately selected by the members of that project.
For example, in the case of a free software project run by a BDFL,
the leader of that project would be that Representative or could
select someone else to represent it. Any member networks are given
the opportunity to provide as many Representatives as there are
distinct viewpoints in the community that network represents.
<br>
Every month, on the first day of the month, the Project will put out
a blog post detailing the month in review of the Network.
Representatives of each member entity will be responsible for
working with the Project Editors in order to write a short two- or
three-paragraph decription of the state of their member entity,
including what has been accomplished in the past month and what is
on the horizon. These sections will be submitted to the blog
repository using the git version-tracking system. Knowledge of this
system is not required but is preferred.Our editors will be able to
guide Representatives through the submission process and help with
any problems presented by this setup.
</p>
<h2 id-"members"><a href="#members">Members</a></h2>
<!-- <p><a href="https://farside.link/https://instagram.com/_remind_me_tomorrow">_remind_me_tomorrow</a>,
a platform dependent essay, hosted on Instagram, which deals with
the ways that The Digital has been made precarious over the past
several decades. Created by
<a href="https://embeddedscript.net/">Richard Williams</a>
<a title="Unlicensed JavaScript" href="https://www.gnu.org/philosophy/javascript-trap.html">[!]</a>.
Linked here using a free software frontend for Instagram.</p> -->
<p><a href="https://git.tebibyte.media/nexus/nexus">Nexus, a
federated, free software, hackable VR social platform and
protocol.</a></p>
<!-- <p><a href="https://ortusjournal.org">Ortus Journal, a journal
of speculative analysis</a>
<a title="nonfree plugins" href="https://gschoppe.com/wordpress/plugins-and-themes-open-source/">[!]</a></p> -->
<h2 id="application"><a href="#application">Application</a></h2>
<p>In order to apply to be a member of the Tebibyte Media Network,
please reference the below guidelines. All applications should be sent
to <a href="mailto:apply@tebibyte.media">apply@tebibyte.media</a>.</p>

View File

@ -4,23 +4,23 @@ Project members include Person1 <user@example.com>, Person2 <user@example.com>,
and Person 3 <user@example.com>. The representative of the project is Person1.
Nexus' current design is subject to change; we are still in the rough
prototyping stage and we expect to "ship-of-thesus" our current design quite a
prototyping stage and we expect to "Ship-of-Theseus" our current design quite a
bit. The goal of Nexus is to provide an open, extendable, VR social platform. To
do this, Nexus separates its logic into individual WASM scripts and a networking
do this, Nexus separates its logic into individual Wasm scripts and a networking
API based on the ECS model. Everything communicates using the gLTF and VRM
standards: VRM for avatars, and gLTF for objects and worlds. Several different
actors are present within the Nexus architecture:
A “world” is a collection of WASM scripts and gLTF models able to be reproduced.
A “world” is a collection of Wasm scripts and gLTF models able to be reproduced.
It is intended for users to be able to create worlds, and to share them,
allowing others to use the worlds as templates from which to create servers. A
“server” is a running instance of a world; how servers interop with other
servers is yet to be determined. A “client” is the front-end application that
can connect to any Nexus server and interact with other clients over the server.
The current plan is to provide almost everything using WASM scripts.
The current plan is to provide almost everything using Wasm scripts.
WASM scripts have two categories so far; there are server scripts, that just run
Wasm scripts have two categories so far; there are server scripts, that just run
on the server, and client scripts, which are sent over to the client for the
client to run locally and then interact with the server using the networking
API. It's possible that we will come up with some kind of server-client dual
@ -30,26 +30,26 @@ in order to limit abuse.
Camera and physics (gravity, collision, buttons, etc.) interactions, IK and FBT,
and GUI systems (server discovery interfaces, friends lists, etc.) will all be
provided by WASM scripts. We will provide default implementations, but the
provided by Wasm scripts. We will provide default implementations, but the
community will be free to hack on those scripts or create their own from scratch
to provide the same or new functionality. This creates an extremely extensible
platform. Using WASM means that, as we go into the future, more languages could
be utilized to write social vr, or non-social vr experiences, such as games, a
platform. Using Wasm means that, as we go into the future, more languages could
be utilized to write social VR, or non-social VR experiences, such as games, a
scene editor, media creation tools, etc.
This system enables people to to write clients and servers in other languages or
engines than Bevy, which we are currently using for our standard implementation.
As long as clients or servers properly respect the WASM scripts, everything
As long as clients or servers properly respect the Wasm scripts, everything
should work across different implementations. If someone creates a Nexus server
SDK in Unity, they will be able to take advantage of much of Unity to create
Nexus worlds.
The fact that we use WASM also means that game developers can create games or
The fact that we use Wasm also means that game developers can create games or
experiences in normal, 2D IDEs, such as writing a game in Rust, instead of
having to deal with our scene editor. That being said, we do plan to make a
scene editor in Nexus, but this is a tentative, far-future plan.
The current plan is to use IPFS to provide sharing of WASM scripts, models, and
The current plan is to use IPFS to provide sharing of Wasm scripts, models, and
whatever else may materialize in the future.
Theoretical work on a permissions system has not yet begun.
@ -64,7 +64,7 @@ loading, basic voice chat, and synced worlds.
The timespan of this project to full completion is several years. If all goes
according to plan, an MVP should be only a few months off.
The server and client implementation will be licensed under the GplV3, but all
The server and client implementation will be licensed under the GPLv3, but all
the base scripts, for things like physics, inverse kinematics, and the basic UI
implementation will be licensed under the Expat License (also known as the MIT
License).
License).