MMI Generator Sources for Applications

Mind matter interaction or MMI generators supply specially generated and processed data for applications meant to respond to influences of mind, that is, MMI applications. MMI generators have two important properties: 1) In the absence of mental influence or so-called baseline operation there must be no significant bias or other statistical patterns. 2) Nonrandom patterns are expected to occur when an MMI generator or system using it is subject to focused mental intention to produce specific results. MMI generators also have high true, that is, physical entropy per bit – close to 1.0. Deterministic or pseudorandom generators seeded by any kind of entropy source are not MMI generators since the entropy is usually extremely low. While they may exhibit property number “1” above, they do not show property number “2.”

MMI generators are either local, being at the same location as the user, or remote, being physically separated by some appreciable distance from the user. Remote generators are also locally or remotely processed. Locally processed generator output uses an application that receives raw or unprocessed bits from a remote generator and processes it in an application at the same location as the user. Remote processed generator output uses an application that performs most of the processing for the application at the same location as the MMI generator, while an interface (I/O) application takes input from the user and provides results.

These variations of local and remote are important because they affect how data is transferred between generator and application, and how communication latency can affect performance of the application and user experience. Local generation is ideal to minimize latency. The generator is connected directly to the device containing the application and latency is determined only by the speed of the device and efficiency of the program.

Remote generation with local processing relies on raw MMI generator output transferred to a user device for processing. It is not essential for the application to receive sequential output bits from the MMI generator. That also means some bits may be dropped during the transfer process without significantly affecting the results of the application. Use of duplicate data must be avoided. Transfer of data is usually done by Internet connection. Since the reliability of data transfer is somewhat relaxed in this configuration, User Datagram Protocol (UDP) can be used. This protocol yields somewhat lower Internet latency at the expense of slightly lower data reliability. This protocol also provides a way to provide MMI generator output for use by any type of MMI application. Some sort of login should be included in the generator server to prevent abuse of an “open-door” supply of MMI data or denial of service (DOS) attack.

Remote generation with remote processing performs most of the processing at the MMI generator location. The user logs in and interfaces using their device. Connection reliability is expected to be very high with all interactions sent and received without loss, so Transmission Control Protocol (TCP) would be preferred. This type of system puts a higher load on the MMI server side and restricts to specific applications that are known when the server is designed, or requires periodic updates as different user applications are added.

Custom transfer protocols can be written to provide both low latency and high reliability, but that also complicates user-side and server-side programming. UDP is likely the simplest, but also requires publicly revealing details of each application, while TCP with local processing can allow details of the application to remain confidential. Remote generation with remote processing relieves the user device from possibly significant processing overhead if that is an issue. See this site for an outline of Internet connection protocols:

Measuring transfer latency between a server (or personal computer) and any remote destination over the Internet is most easily done using a ping command. To perform a ping from a command line interface, type “ping” followed by the IP address or domain name of the host you want to ping (that is, ping The round-trip response time will be displayed on the screen in milliseconds. The one-way latency is about one-half the ping time. See If a specific remote computer is not known, find a large business or school near the remote area of interest, look up their IP address and ping them. Note, some organizations do not allow pinging.

Once MeterFeeder and some of the novelty applications of it have matured a bit I’m very keen to work on a protocol/network (probably codenamed entronet or randring or something) for “sharing”/“pooling” entropy for both just pure randomness requiring-applications and MMI applications. I imagine we could blend TCP/IP and UDP, similar to how softphones work. Actually now that I recall the dev work I used to do for call centers, something like SIP/RTP could be ideal. SIP - TCP/IP based for controlling the flow (dial, negotiate, hangup, transfer etc.) of calls and RTP for the actual media (voice/audio over UDP).

To avoid bad actors from peeing in the pool to say, we could have some application procedure for participants wanting to add their entropy to the pool to get an API key or something, and that would have to be signed with their public/private key pair before their entropy would be allowed in the pool. That’s assuming the fundamental network is centralized.

Maybe a decentralized architecture might be beneficial but nothing comes to mind right now.

Providing an MMI generator source for general development and eventual distribution for applications is one of the top projects on my list. I will be happy to discuss this in more detail when you are ready.

Being decentralized in the sense of having alternate locations to log into that provide independent sources of MMI bits is a very good idea. Depending on the size of the service area, closer user/server separation allows lower latency. Also, if the MMI source becomes popular, multiple servers prevents overloads causing delays or unavailable output.