Inter-Operability Forum


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.

Type text

Open e-mail 2 - Ethics in the Vitrual

Open e-mail 1 : Attachment

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!

, Bart, (boiert).


White-hairs: Please use Socket(s) for your specific ocet-stream(s) in the specific classes using messages to set up the connection!


🔙 to the Bedrijf zonder Naam mainpage