IOI Industry of Integrations x

The concept of the Industry of Integrations (IOI) is such that: if any two system interfaces (APIs) are known and accessible that (via the conventions of IPSME) a translation can be created integrating the two APIs …​ And! that that translation can be monetized.

Concept

The number systems an individual interacts with is growing, but in recent years there is lots of discussion around interoperability. If integrations are only organized by the largest companies in the world, integrations will remain proprietary and kept behind the siloed digital walls that exist today; this includes the integrated user data. For example, we risk the rise of not apps, but Mega-apps like WeChat; Elon Musk has already mentioned the desire to to make the Twitter/X platform as all encompassing as WeChat.

IOI enables any entity that knows the APIs of two systems to build an integration, and then also monetize that integration. This puts the power in the hands of the community and the market to dictate the integrations of existing systems. Individuals can then choose the integrations that are of interest to them, while keeping integrated data private, rather than under the control of mega-apps.

There is currently no monetary incentive for developers (or hackers) to create integrations; it is not sustainable for them to work on integration projects. There are lots of community lead projects which essential reverse engineer platforms in order to interface with them; there is often no monetary benefit to create the integration. By enabling integrations to be monetized, it becomes sustainable for developers to provide services to the general community.

Simultaneously, the user experience is suffering; an individual’s data is split across multiple systems, where — even if the individual is granted access to their own data — they often do not have the competence to migrate their own data to another platform, because the data often requires translation. Rather than leaving integrations to be done by only large companies, the IOI aims to put power in the hands of the community where developers can integrate systems for individuals to use, so that the integrations and the resulting data remain under the control of the user.

Interoperability

Many systems are siloed, meaning the system limits the access to data externally and also does not provide an option for programmatically altering the system. There are basically three different "attitudes" a company can have towards interoperability:

  • actively seeking interoperability;

  • neutral to interoperability;

  • and, actively blocking interoperability.

A system can be actively interoperable for warping, but still be neutral or blocking for asset transfer.

Actively Seeking

Companies who are actively seeking interoperability might have siloed systems, but are actively looking for ways to open up their system for interoperability. This includes creating APIs whereby third-parties can interface with their system. It is entirely possible for companies to have a paywall for accessing their API, as long as there are no exclusivity deals preventing the community from access the APIs.

Neutral

Companies that are neutral to interoperability don’t make any effort to be interoperable. Their system might have an existing (perhaps insufficient) API, but they are not actively updating that API for interoperability. Since the company is not actively blocking interoperability, it might be possible to hack an interface to the system e.g., by either creating a virtual overlay or by reverse engineering the system. This means it is possible to use adversarial Interoperability to the advantage of the community.

In the video below, a virtual overlay is used over the Twitter/X interface in order achieve an integration with Second Life, even though Elon Musk has stated

Actively Blocking

Companies have varying views on interoperability e.g., it is ok to use the API, you must use the┬ácompany’s official user interface, etc. If a company is not happy with the community making integrations with their system, they might retaliate by actively trying to block any type of integration. These types of blocks can include technical or legislative approaches e.g., blocking certain network traffic or banning certain actions through TOS, respectively.

Empowering the User

IOI is about empowering the user. The user is given the power to choose which integrations to support and utilize on their own devices. This includes running integrations that customize their devices' HUD.

Developers can identify systems with APIs they would like to build translators for and then offer those translations to users. Since app-stores (e.g., Apple’s Appstore) is not likely going to accept pure translations, an easy way to get translations running on each user’s system is needed. The Store-of-stores currently fills this role. Ideally, a user can just install a translation and immediately gain the benefits of the integration. Translators push data into the IPSME eco-system. This means that it is also possible to build components that make use of the data e.g., pushing data into a different applications, or aggregating data on a user interface component. It is entirely possible for a person or company to aggregate the data into a different visualization.

In the video below, there are translators that collect data from various data sources; each of these translators could be created by a different person or company. The data is then pushed into the IPSME eco-system, where a different component, namely the subverse-map, aggregates the data on a map.

IOI and AI

IOI states that a translation can be created between two APIs, but nothing dictates that it has to be humans creating translations. Translations are often difficult and time consuming to create. If the two APIs being integrated are documented well enough, formally or informally, then Artificial Intelligence (AI) could be employed to make the integration, or at least assist with it. In that way, the number of integrations available to the audience of users can be increased, providing for a richer eco-system.

Examples

MiM

A component called MiM allowed for disparte Minecraft instances to be linked together through virtual overlays. The component is currently deprecated, because it was based on a previous prototype of IPSME and therefore is not actual. MiM can be updated, offered to the public and monetized.

Second Life

To enable warping to Second Life a translator was created.
The translator can be offered to the public and monetized.

VRChat

To enable warping to VRChat a translator was created.
The translator can be offered to the public and monetized.

1Password

To map identities during a warp a translator for 1Password was created.
The translator can be offered to the public and monetized.