During the recent get-together discussing the future of remote presence, the Metaverse or Web3 a few interesting topics were mentioned. Interoperability and platform neutrality were mentioned as goals. As well as a desire to further those.
Agency and autonomy, in a virtual world: We shouldn't be able to abduct anyone anymore. Moving between worlds shouldn't corrupt the posessions you carry and worlds themselves shouldn't be able to compromise your experience.
A Platform-agnostic interoperability forum where we concretely: Discuss and plan the systems interaction perspective of the Metaverse/Web3/Developed Constructs.
Succes would be defined as leaving with a signed Charter and a follow-up meeting. Great succes? Everything else we can get done.
Dear InterOp ops!,
Participants on that forum, participating implementors and technical staff or -inclined hobbyists and upstarts!-
I have been planning this proposal for a long time, at least half a year! And I propose the following: A message exchange format based on labeled : [ { adressed }, ... ] JSON in _original UTF (not -8!) format_ because: UCS4 in 6 bytes seems achievable only that way -AND- abstract class Definition (Java based, Extended with modern namespacing and there-fore support declaration). A secretariat managing a diffableDatasource of accepted definitions is needing sustainability support.
JSON messages are to be produced (and MUST) include the unecessary amount of OWS.
(the "ECMA-404 The JSON Data Interchange Standard." spec is awesome to follow, visually as well.)
*/ -- ! --> #
I advise implementors to wrap received messages in objects maintaining .validate
.secOP and
.parse strategies
with Sockets per connected user for message(s, streams of them),
Failing users per invalid or non-parsable message,
SecurityOffice .secOP for stragglers maintaining old procedures that MUST be deprecated, but not immediately faulting the user. (preventing some non-parsable as well, modernize)
Thank you all!
Attached are my first proposals, pilot-balloons so-to-say and the referenced specifications or encyclopedic results (year 2023).
Let's agree on the proper spec for abstract (expected-to-be possibly implemented) Classes first! I like the FireFly format for the header most, followed second by Message.
Kind regards!
-b
, Bart, (boiert).
ps.
White-hairs: Please use Socket(s) for your specific ocet-stream(s) in the specific classes using messages to set up the connection!
-x-
🔙 to the Bedrijf zonder Naam mainpage