I’ve taken the API server (named quanttp / Pod Entropy Server) developed originally by Andi and customized by @NN_Solex and @Winternewt, and replaced its implementation of libqwqng with libmeterfeeder. Now the API server can provide data from multiple MED generators at once.
I’ve setup a small “MED farm” with some of the loaned generators that @JamalYusuf sent me. You can request raw random bytes, rand int32/normal/distribution, hex and a list of the devices online.
Getting the list of devices and their device IDs (serial numbers):
curl "https://entronet.fp2.dev/api/devices" (for a plain-text, comma-separated list)
curl "https://entronet.fp2.dev/api/json/devices" (for a JSON array, with a description of each device)
@ScottWilber wrote up a detailed of all the different generator types here (the MED farm doesn’t have them all!)
The other APIs work as is, you just need to add a deviceId=XXXXXXXX parameter to the query string to specify which device in the farm you want to get data from.
E.g.
curl "https://entronet.fp2.dev/api/randint32?deviceId=QWR4B001"
curl "https://entronet.fp2.dev/api/json/randhex?deviceId=QWR4E002&length=3&size=15"
Note, the WebSockets API isn’t updated yet.
The source code is currently hanging out in this branch:
1 Like
I’ve updated the code for the WebSockets API but haven’t tested it. It has a new command called DEVICES to get the list of devices and the rest of the messages take a new argument as “deviceId”.
Honestly, I’m not convinced yet, that if we trying to use one MED feed for several MMI applications from several users they don’t influence each other.
Maybe, we should think about experiment, which will be able to clarify that issue?
I don’t even use Randonautica app, yet use my own custom python script. Because I have a concern about side influence from public use entropy source.
In my experiments, it’s possible to amplify MMI with sacral geometry based concentrators around RNG. If such thing works, it’s possible, that residual influences from other people will mess with my intent. And only dark gods know how horrible it might backfire.
Cloud solutions and convinience might seem appealing. But they are already backfired pretty much times. When we store information in cloud, it’s already big insecurity and privacy problem. We don’t have full ownership of our data. Do we want to be so insecure with our souls?
That’s not really what this API is for. This modification has support for multiple devices. Currently it has 8 MEDs (of varying types) connected. It’s a pretty simple API in terms of implementation. Its existence is really only known by people on this forum and it won’t be publicly announced or anything. The idea was just to make it available for some here to do whatever R&D they want with it.
The inherent latency incurred with transmission of entropy over the internet is an issue though so it’s not a one-stop solution.
The idea of ‘reserving’ whatever source may be available could be a feature to avoid interference of intentions. But then again who is to say your intent isn’t being read by the MED in port 1 but you’d actually been reserved port 2’s device? I guess this is one of the fickle things with MMI.
One idea I had (but never implemented) was to temporarily ‘tag’ a MED allocated to a user. Kind of like how they allocate numbers to targets in remote viewing. The idea was that the intent-setter could have something more to focus their intent towards, thus hopefully increasing the probability that MED would be the one to pick up their mental influence.
There a couple of ways to connect a user with an MMI generator. MMI data must always be served real-time, that is, the generation is within a fraction of a second of the user initiating a trial or user application that uses the data. I think stored MMI data is no longer MMI data, but is already determined, that is, relatively fixed. This “rule” may not be absolute, but there has to be a starting place.
The most important way to connect a user and a device is by feedback provided as close to real time as possible. It’s that feedback, in whatever form it is delivered, that seemingly allows entanglement between the generator output with the user’s intention.
When I provided MMI data online, a unique generator was always assigned to each user. I had enough hardware for over 1000 simultaneous users. I would suggest that switching between multiple users within a one-second time window using the same generator could easily cause interference in the results. That would be effectively real time for those multiple users, and at overlapping time windows. To minimize that interference, one user must have control of a single MMI generator during a certain time leading up to a trial or initiation of an application process, and for a certain time after initiating the trial or process. The amount of time is not clear, but I would guess for at least 0.3 seconds prior to initiation and 0.3 seconds after the user receives feedback showing some form of results. That amounts to at least 1 second per user per trial.
If multiple users are initiating multiple trials, their focused intention could easily be continuing for periods longer than 1 second. That suggests the duration of assignment of a device to a user depends somewhat on the flow of the application. After a period of intense focus on consecutive trials, I have seen effects persist for several seconds after the series was technically ended and another user began. This is because the first user didn’t really stop their focus like switching off a light, but it would wind down as attention naturally switched to something else.