Advice on approach please

Mind Matter Interaction
1

I’m in the early stages of creating mobile apps for iOS and Android. Among other things, I plan for it to have the ability to allow users to perform psi trials. Users can attempt to influence random numbers during a discrete time window, during which probability is calculated in real-time and they are provided real-time feedback, probably something like a spinning cube, changing audios signals, and maybe a bar chart with variable fill level - just like I created in the code I shared awhile back - example (but note that this example is two-tailed not one-tailed). I imagine also gamifying this through the use of a global leaderboard where users can see how their results compare to others.

I’m working through the technical aspects of this. Of course, I need access to some truly random numbers and requiring users to have a physical device is not feasible. My initial thought entailed using the API provided by Australian National University Quantum Numbers (AQN). The random numbers are generated in real-time in their lab by measuring the quantum fluctuations of the vacuum and then made available via API. For example you can pull request 5 random numbers between 0-65535 by calling this endpoint:

https://api.quantumnumbers.anu.edu.au?length=5&type=uint16

Initial desire was to do 20 minute sessions, pulling a new set of numbers once per second. The instructions would be for the user to attempt to generate more even numbers than odd numbers. The numbers pulled each second would then be simply evaluated to see if a given set contained more evens than odds (the degree to which there were more would not be considered). These cumulative results are then fed into a simple one-tailed binomial test to produce a probability value, which is what’s fed back to the user for real-time feedback and also used in overall score evaluation.

Technically speaking, 100% doable and actually not that complicated. The core problem, however, comes in the fact that AQM API calls cost $0.005 each. So for what I described above it would come to $6 per trial, which is way too high. I would expect to charge for this app in some manner, maybe a small monthly subscription fee that covered all app functions, not just the psi part. But racking up $6 per trial, with people doing one or more possibly more than one trials per day would be too expensive.

I’ve contacted them about custom pricing, but haven’t heard back.

  • What if I did only 5 or 10 minute trials, and pulled numbers only every 5 seconds? Is it enough to get meaningful data?

  • Is there a better way for me to be generating numbers in a cheaper way? I’m of course aware of the MED Farm that @WanderingIshiki runs, but in its current state I think it’s lacking some important features around security, concurrency, and scale. Also, I’m aware that Scott has not approved either his devices or algorithms for commercial use, which, even though this app is being built and delivered by a non-profit organization that I run, and is aimed primarily at covering the costs of running the app, it would still be charging users money.

  • Is there a better algorithm to be using than the one-tailed binomial test I described?

  • Any thoughts on the influencability of the AQN API? In my own limited previous trials I found difficulty in influencing these numbers with psi, and seem to recall anecdotal reports of others facing the same challenges. Is this a viable random number source to be using?

@ScottWilber @WanderingIshiki @nplonka , whoever else - would love to hear your thoughts on this.

Perhaps not directly related, but I also like the idea of later doing data analysis on this psi data, looking for correlations with people who have the most successful outcomes. Do they correspond to certain geographic locations, certain solar / geomagnetic conditions, or perhaps certain demographic details (that the user can optionally provide)? That’s for later, but could be some interesting possibilities there.

1 Like
2

You could develop your own MMI server system. I have a large number of MMI generators, and I believe we can come to a simple and equitable agreement for their use, as well as a license for the IP. You may be able to work with @WanderingIshiki to beef up his setup or develop a super server system by collaborating. I would be happy to support any reasonable option.

I am developing other algorithms for use with my new A.C.E. system. I will share when I have had a chance to test them. Otherwise, the advanced processing methods I described are the best I know of. Multiple advanced methods can be used to process the same data to achieve slightly better results, but this raises the computational overhead.

The people at ANU running the random generator system told me, 1) their numbers have been deterministically post-processed and, 2) they cannot be sure the numbers are current or “real-time”. These are two issues that can decrease the responsivity of an MMI system. More importantly, generators that output bits without some type of bias amplification are vastly more difficult to get significant results with. (note, we now have substantial test data from many subjects showing the high bitrate bias-amplified data is significantly more responsive) There is no practical way to stream raw bits (words) and apply bias amplification algorithms at the user location. The MED100Kx8 generates 1.024 Gbps and the bias amplification algo brings this down to 100Kbps – a 10,000:1 reduction in data rate. Preprocessing at the generator location with attention to latency (in this context, latency is the time between data generation and the result of using the data being displayed for user feedback) seems to be the reasonable approach. At some point, special MMI chips may be included in many devices, but that’s a while away.

3

Your post reminds me a lot of the early days of Randonautica dev which led to one of the members finding Scott and the starting of this forum. It’s really exciting to see your interest and passion in designing and developing what you’ve outlined.

ANU was the original QRNG source for The Fatum Project which a lot of it was about the kind of psi experiments you mention, then also it was used by Randonautica back when it was all free (but now they use one of Scott’s devices I believe). The fact that ANU now charge for it and that it has the deterministic post-processing, wouldn’t make it the best source for what you’re attempting now. And like you mention, the MED Farm I’m running is really just at a hobby-level with no security or concurrency or scale built into it.

I’ve been slowly working on a enterprise-level RaaS (randomness as a service) business which I’ve talked briefly with Scott about. It’s main intent is not for MMI use-cases (but more enterprise focused) but if I do figure out a more stable (other than just having an old computer at home plugged in) way of hosting the RNGs, I want to consider having devices/infra set up for experimenting. No promises as to when this will be ready sorry, but I’d be glad to let you use that (if and when that day comes;-))

A few years ago I did start working on an Android/Java driver so you could plug a MED right into your phone. I got some basic I/O going but it was buggy and the input stream wasn’t working well. If you’re interested I can try and find the code.

Meanwhile if you have any technical questions, MMI or not, even just app development questions, feel free to fire away on this board. There’s a lot of super talented people on this forum.

Good luck!

4

Thank you both for the responses. @WanderingIshiki any way to expedite this effort, or do something slightly different, that I could use soon? What about improving the MED Farm? I can compensate for your time.

5

I have a few MMI generators with internal bias amplification and an output rate of 1Mbps. A number of 128Mbps generators without internal bias amplification and no deterministic postprocessing are also available (note, none of my generators use deterministic postprocessing, except the crypto generator, which I would not use for MMI work).

6

Having your psi tester available as an app would be great

1 Like
7

What does it mean to have internal bias amplification? And wouldn’t I want slower generation rate rather than faster? I know when using the med100kx8 device it was a struggle to get code going fast enough to use all the bits - what’s the generation rate of that device?

What if I created a farm of more available RNGs, like the TruRNG3 (even though it generates all kinds of characters, not just numeric, could convert to binary)? I would like to have at least 10 running in parallel with the ability to increase as needed, though I doubt I’d ever need to exceed 100.

8

I’m a bit too tied up with my other jobs and projects sorry to be devoting time to the med farm.

9

What I mean by “internal bias amplification” is, the hardware that generates the random numbers also performs bias amplification before anything is output for use. The MED100Kx8 (100Kbps output rate) generates random bits at 1.024Gbps, which is bias amplified by a factor of 101, bringing the output rate to 100.382 Kbps (1.024Gb/101^2).

There are only a few currently known factors that significantly affect the responsivity (measured in effect size) of A.C.E. or MMI systems: 1) the larger the number of bits or samples used to calculate results, the higher the responsivity. The increase is generally proportional to the square root of the number of samples used, compared to a single sample; 2) the greater the quantumness, that is, the degree the measurement of the entropy source is determined by quantum mechanics, the more responsive the system; 3) efficient processing algorithms, meaning those that best increase the signal-to-noise ratio of the signal of interest, are essential. In this case, minimizing computational overhead may also be part of the “efficiency;” 4) user feedback that is engaging, informative (communicates results clearly, easily and rapidly) and preferably in real time, is essential.

The readily available RNGs were not designed with MMI in mind, nor were their designs based on a deep understanding of random number generation and randomness. 100 TruRNG3s have an aggregate generation rate of 40Mbps, only 4% of a single MED100Kx8. In the same measurement period, compared to all 100 generators producing an output, one MED100Kx8 would provide results with about 5 times higher effect size.

The RNG interface software on the CoreInvention website (https://coreinvention.com/wp-content/uploads/2022/08/qng360_setup.zip) can input data at up to 128Mbps. The MED100Kx8, and all my past generators, should be compatible with that interface. In any case, it’s possible to input data at very high rates.

10

Thanks Scott, very useful. It certainly sounds like using MED100Kx8 devices is superior to using TruRNG3 devices. What’s the max number of MED100Kx8 devices you could make available to me (as you mentioned, happy to come to some licensing agreement here)?

Also, in the text below, these are NOT MED100Kx8 devices, right? Sounds like the output rate of 1Mbps is higher than the MED100Kx8. Is the MED100Kx8 ultimately the best option for what I’m trying to do?

“I have a few MMI generators with internal bias amplification and an output rate of 1Mbps. A number of 128Mbps generators without internal bias amplification and no deterministic postprocessing are also available”

Perhaps an additional option would be for me to use the devices currently allocated to the MED Farm, as they don’t seem to be actually getting used by anyone. So, I’m suggesting hosting these somewhere else and building out more infrastructure around them. I’d ideally like to have more devices than just the seven allocated there, but at minimum I think that could suffice. (@WanderingIshiki - something you’re open to if needed? …basically shuddering the MED Farm and re-allocating these devices…)

11

I wouldn’t want to see the MED Farm shut down, even if it’s not currently being used as much as it could. People can come back around for a spurt of development when they have time, or if the tech – and interest – heats up significantly.

I made 5 of MED100KQ16 and 4 of MED1MQ16, both are in small desktop enclosures like the PQ4000KS RNG. Both have internal generation rate of 2.048Gbps. The MED100KQ16 has bias amplification of 143 (42% higher than the MED100Kx8, with output rate 100.152Kbps) and the MED1MQ16 has bias amplification of 45 (55% lower than the MED100Kx8, with output rate 1.01136Mbps). I made the 1M devices if a higher output rate is better for the app, and the 100K devices because the 2.048Gbps is the highest generation rate (hence the most responsive) that fits in already existing hardware without significant firmware reprogramming.

I have many MED100Kx8 generators, and I can make available as many as would be in active use. I think the first step is to make sure you can use the RNG interface software so interfacing is not a problem. However, there may be an issue connecting more than one device via that software. I believe it’s possible to adapt it because many instances of the RNGMeter can be simultaneously opened to test many generators, as many as the computer’s speed can handle. A balance of all factors suggests one 1Mbps MMI generator (MED1MQ16) may be the basis of a prototype system, but an MED100Kx8 could be used to build and test the design.

Simple computers are available for $150, or much less for barebones versions. Example: Robot or human?. A network of these computers could be used, each supporting a single generator. This would be easily and incrementally extendable as needed.

12

Thanks Scott, this is sounding promising, though it will be a big investment for me to create, stand up, and maintain the infrastructure for hosting the devices. I should be able to manage that.

It sounds like using MED100Kx8 generators is the way to go, and I think starting with 10 would be more than sufficient. I would not intend to use any of the CoreInvention software. Instead I would largely leverage the Python code I’ve created to interact directly with the devices without the use of drivers. In broad strokes, I’d envision the use of a beefy host-machine with RNGs connected via USB-hub. Each RNG is managed in an individual Docker container running on the host machine, with each Docker instance running my Python code, and the cluster of containers managed by Kubernetes. Authentication is done via OAuth 2.0 or JWT (JSON Web Tokens). WebSocket Secure (WSS) is used to securely stream data between a Docker instance and a user’s mobile app. Would also need to manage tokens, sessions, and implement middleware (such as passport.js or Django’s authentication system) in the server application that checks for valid authentication tokens in each request.

That’s how I’m thinking about it.

13

Hi Dan,
I can send you two MED100Kx8, which is enough to build your system and see how everything works. Plus, you already have one, which would allow you to test with three simultaneously. I just need you to PM me your address, which has disappeared in the mountain of papers in my office.

I should mention, I spent about a year and huge amount of cash building an ultra sophisticated online MMI system (on MindEnabled.com) with several apps and testing algorithms, history/progress tracking, leader board, forum, etc. Although it was capable of supporting up to 1000 simultaneous users, I doubt that there was ever more than one online at once. From this I learned it’s wise to start small and build up as actually needed. At the same time, it’s a good idea to design a system that can be expanded incrementally.

For best performance, each user should be granted exclusive access to a single MMI generator. That avoids any issues with multiple users working at odds with the same physical generator, and it also provides sufficient generating power to allow several different processing methods. On the other hand, a single 1Mbps generator could support multiple users, and allow testing even more advanced processing methods. There are pros and cons either way, but in principle, I agree with your multiple MED100Kx8 generators suggestion.

14

For anyone interested in an update on this, Scott graciously provided some devices and the server is built and running. The mobile app that will call it is still being built though, so the server is not being actively used yet. The mobile app will have a bunch of different categories btw, not just “psi” / MMI related stuff. I’m marketing it as a spiritual fitness app that enables uses to learn about, practice, log, compete with others various in various modalities that include psi / MMI and also others like astral projection, lucid dreaming, remote viewing, etc.

Details of the server… Once someone selects to do a psi session, the mobile app calls the server via DDNS to open a secure (via SSL) web socket connection. The server authenticates the mobile app user’s session and allocates a physical random number generator (RNG) to them for the duration of their session, if a device is currently available. i’ve got a custom-built web server that then spins up a distinct thread (in code) and opens a Docker container to pull data from the physical RNG. real-time data is pulled then algorithms that apply Scott’s Random Walk Bias Amplification (RWBA) method and stream JSON data back to the mobile app via the open websocket connection. updated calculated probabilities are sent roughly once per second. these will control audio and visual feedback provided to the mobile app user. after the session completes the user gets a score, which is directly correlated to the number of seconds that the probability was above 95% of not being random. there will be a global leaderboard where the average weekly results (and over how many sessions) from each user are displayed.

1 Like
15

Great work! I know it’s very challenging to set up this kind of real time system.

If you have not already, consider setting up one of various systems for synchronizing your server computer’s clock to a time standard. There are online versions (List of Top Public Time Servers · GitHub) that can keep the system clock to about +/- 15ms. Or, there are various companies that make hardware for getting more accurate time. One example I use is called TimeMachines (GPS Timeservers - Network Time Servers from TimeMachines). With it, and the proper software, I am able to synchronize all my systems to within about +/-2 ms. Either of these time accuracies is adequate for most applications.

The GPS time provided by the TimeMachines is accurate to around +/- 50 ns, but a normal computer running Windows cannot be forced to track the provided time signal to better than 2ms. So far, newer versions of Windows makes it harder to operate real-time systems. So called IBM compatible computers used to have a physical “real time” clock. Then Microsoft virtualized the real time clock. Then they decreased the possible resolution of the virtual clock.

16

Bismallah. Best of luck to you, do not underestimate the demand people have for what you are building. Scott is right, a slow buildup of users may not sound very exciting but it is much more preferable to trending on reddit 3 days after you release your beta, or going viral on tik tok before you have your monetization figured out.

Also be cautious around journalists, in my experience, giving interviews to mass media publications was basically useless, but the alternative media like podcasts etc were extremely beneficial in spreading awareness and gaining active users.

As for monetization, I was conflicted between putting MMI (or at least the idea of it) in as many hands as possible, and just paywalling the whole thing so only people serious enough to spend $.99 a month or whatever would download the app.

I think your idea of offering freemium features, and charging for the psi bits, is quite wise. I remember one thing we learned was that to go truly international, your pricing scheme has to match the spending power of the country you are operating in.

This is kind of a minor detail because you have a ton of work on your plate and 90% of our purchases came from iOS, but it is important to recognize that a lot of the wider world cannot afford $.99 luxury purchases, and if the market is still the same, they will be using android, but I believe simon or someone figured out how to scale pricing according to the country.

What you are doing takes courage, so I commend you. You have my support, if only as a fan. Best of luck, and thank you, and Scott, and anyone else who is working on this project.

17

The app build is progressing nicely. It covers not just Psi/PK/MMI but also lucid dreaming, astral projection, energy work, remote viewing, channeling, CE5, meditation, and esp. i’m providing guided meditation with brainwave entertainment for some sections and also using AI in some places such as remote viewing, dream interpretation, and dream sign evaluation. At the moment we can have only three people doing psi sessions concurrently. More devices will likely be needed quickly, but we’ll see. Probably another 2-3 months before the app is done. As noted above, I did get the RNG server up and running, it’s live right now and hosting 3 of Scott’s RNG devices and using his algorithms, listening for authentication requests, but the app isn’t calling it yet.

18

So cool, would love to try.

Do you have any super preliminary results? Is anyone able to show a bias?

Did you use RWBA, bayesian updating? Scott has written about so much now. Very very interested in keeping an eye on your results and hearing more about how the app operates.

Wonderful work! Up! Up! Up!

ps dont hesiitate to send me a message when you are ready to begin really generating users, I will happily endorse you to my small following. you got this! i have a lot of faith in you

19

Thanks @JoshuaLengfelder for the interest and support. The psi/pk/mmi stuff isn’t integrated into the front-end yet, though the backend services is live. We also don’t have any users yet while we’re in the build phase. It’s using RWBA though, basically using the same code I wrote and shared before for that portion. Will let you know when things progress. Probably another 2-3 months until it’s done.

20

Cool, looking forward to it. I believe this space will move faster when there is a community of skilled operators.