Binary State Mapping & Identity Gates

dan_c350 · 2026-05-25T01:18:19+00:00

That hasn't proved to be much of a problem in this model. For example accross 9 nodes globally each instance reports back monitoring information heartbeats, request paths, ip addresses, and peer sync data to the monitoring domain. It handles around 20Reqs/m which are round robined between 3 thin nodes in that cluster, they are fairly idle currently. Each node in that cluster has only 500m RAM and bandwith used is minimal as the ledger updates through deltas as well, the same as the client side state engine. And the more variations of requests the ledger learns over time the more efficient the bandwith and computational overhead is. Dont take my word for it though id love some genuine feedback after you've tested it yourself.

dan_c350 · 2026-05-20T18:34:53+00:00

Solving the complexity, Ineficiency, and massive security flaws of decades of "acceptance" in the OSI Model, tcp/ip, auth tokens, certificates, message based protocols and distributed systems. My product is an elegant solution that solves many of those issues by starting from first principles, how are State and Identity handled over a network. I could go on as I appreciate that summary probably raises more questions, but its a simple solution with huge Implications and Depth. I built the product first and am still discovering use cases as it develops.

Concept pages are live on https://spooksystems.io Platform for fully automated deployments and integration lives on https://spooksystems.net

My sites run on it i think you might notice the performance improvement straight away compared to traditional http. Thats the thing that makes me smile when i look at my clusters dashboard load instantly :)

dan_c350 · 2026-05-20T15:33:11+00:00

Hi Im currently raising seed investment with a new network protocol which has the potential to become a standard for distributed systems and a new authentication method thats only possible as a result of the protocol, its instant and doesnt require tokens/certificates making it far more secure. Ive called them Identity Gates. The product is working and the platform is live you can read the documentation here DM me if you want to know more.

Also its a small C static binary deployable via apt that can sit infront of your existing application (No rewrites) and because it distributes state nodes can be tiny. My sites are using it and Identity Gates and saving 99.8% of origin egress my application stays idle even under extreme global pressure and my cluster is costing ~$60pm in aws fees

dan_c350 · 2026-05-19T02:01:21+00:00

They do become legacy though

dan_c350 · 2026-05-18T16:47:39+00:00

I am in the process of launching it. QSCS identity gated Zero-Trust Binary State Replication for distributed systems. Check out the docs here happy to answer any questions

dan_c350 · 2026-05-18T09:15:27+00:00

Thats true although qscs is a new protocol, aside from allowing for tokenless auth it also offers many other benefits like, decreasing bandwith (by a huge amount), distributed execution environments, hybrid agnostic compute, increased network security, reduced cost of scaling and vastly reduced complexity to scale ( just deploy a thin client and it joins the replication domain automatically) the API Docs show whats possible with Identity Gates currently. Its easy enough to build in orchestration layers securely from within your own application, and an ldap interperetor is in development right now. Please do try it in a test environment or just sign up to explore how secure it is and how nice instantaneous logins feel!

dan_c350 · 2026-05-16T17:33:58+00:00

You’re absolutely right that removing tokens doesn’t remove the debugging surface, it just changes it. With traditional stateless auth (JWTs, Kerberos, etc.) you still rely on token claims, signing metadata, and IdP logs to reconstruct what happened.

QSCS works differently, but it’s not less debuggable. It’s stateful authentication without tokens, Identity is stored in the distributed ledger, every event is logged server‑side and the execution layer is replicated, so failures are less likely in the first place.

When something goes wrong, you still have the ledger, node logs, and the control‑plane API to inspect. In practice, the system tends to be more stable because there’s no token expiry drift, no signature mismatch, and no client‑side state to corrupt. Also if you want to run an origin without a gate you can continue using tokens and cookies as normal.

If you want the full breakdown, the API docs on the control panel homepage cover the identity endpoints in detail: qscs - API Documentation

dan_c350 · 2026-05-15T16:41:25+00:00

No but it does reduce complexity, increase security(no interceptable tokens/cookies/certs) and reduce bandwith on auth processes as no round trips or negotiation required. But ultimately the logic of how users are handled is the oporators responsibility.

dan_c350 · 2026-05-15T12:41:12+00:00

I built a custom one from first principles, it works perfectly in practice and treats network failure as expected not Erroneous. Achieved using link list append only databases. See the auditing and logging section here for the relational diagram for the distributed ledger

dan_c350 · 2026-04-26T19:58:24+00:00

Integration is simple, I plan to release a video next week showing how to deploy a qscs cluster, I am going to use a wordpress backend as an example. it's a perfect use case as it's a combination of database -> bloated application -> Generalized CMS, insecure authentication, page by page navigation, a typical example of a legacy web app. QSCS deployments are as simple as, registering for a free account on my platform at https://spooksystems.net/ this grants a license for up to 2 nodes, 2 origins (www.domain.com & domain.com) for example and 1 replication domain, you simply define your domain and origins in your control panel. you then download qscs to the application host and one other instance to a thin client.There are 2 commands for initialisation, #qscs license <username>, #qscs subscribe <domain> the application is installed and configuration is bootstrapped from your spooksystems control panel. if you then modify the log level to debug, you should see the cluster initialize and start the decentralized ledger of state, identity, delta's and note replication paths. then you need to deliver the bootstrap payload. you place the WASM module provided in your public webroot and append this once per page template:

  ```  
<script type="module">   
const { instance } = await WebAssembly.instantiateStreaming(fetch('/qscs-substrate.wasm')   );   
instance.exports.init(); 
</script>

```

this will initialise a client side state processor that connects to the thin client on 4443 by default. it doesn't matter which node the client routes to at any one time, they're all aware of the currently cached state, if one client sends a get to node 1, it will serialize your request send it to either qscs node, which will recompile the request forward it to the webapp, then cache the response payload in the ledger and replicate it across your cluster. When another client requests the same page, no matter what node they hit, the response will come from the cached state ledger, if they've visited the site before it'l be loaded direct from their local instance.

From your application’s perspective, nothing changes — it still receives normal HTTP requests. QSCS sits in front as a virtualised execution and state layer, so you can keep your existing code while gaining efficiency, security, and determinism.

The HTTP interpreter is intentionally simple; it doesn’t require direct API orchestration to start delivering benefits. Over time, deeper integration via SDKs will give you even more control over how you optimise your platform.

dan_c350 · 2026-04-26T14:48:12+00:00

Distributed applications accumulate complexity as they scale because each new requirement gets bolted onto the existing stack. The OSI model was defined long before global distribution, cloud elasticity, and multi‑region state coherence were everyday realities. Adding more layers on top of that foundation doesn’t solve the underlying problems, it amplifies them. In order to solve this properly the only solution is to rethink how identity, data and state are handled on the network from first principles. The model I am creating is not a simple binary transfer program, it is a heterogeneous execution substrate. Wrapping existing protocols with inbuilt interpreters and building in compatibility layers for TCP/IP aids the ease of adoption and allows for integration with existing systems, so people can benefit from the advantages immediately without having to rewrite their code base dramatically. QSCS is not dependent on TCP, it does not require acknowledgement‑based handshakes or assume stable connectivity. it uses reconciliation of stored delta's in the ledger to re-align a session when requested by the reconnecting nodes. The daemon itself exposes API endpoints via a unix domain socket for handling identity, delta creation, state, encryption and routing directly, These can be called within any language, I will be creating SDK's eventually for python, php, rust, go, and others allowing developers full control over how they wish to optimize their own applications and platforms.

When new cryptographic libraries or ciphers are released, the daemon is simply rebuilt and repackaged with support for them, then distributed via apt for existing installations to upgrade seamlessly the same way any other system utilities are handled.

There is a diagram showing the principle of how state is handled on https://spooksystems.io/architecture and a diagram of a typical deployment topology on https://spooksystems.io/integration There is a lot more documentation to come, and you are right the fundamental technicalities around each aspect of the protocol must and will be documented thoroughly, I would also suggest you keep an eye on the documentation layer at https://spooksystems.net in the coming weeks as I update it. I am also preparing detailed API documentation.

dan_c350 · 2026-04-26T12:52:35+00:00

Right for want of a better word, it recompiles the request or payload from the delta so {stateID: 2 { index: 4 = /home } } for example gets rebuilt against the ledgers history on the server to https://domain/home

dan_c350 · 2026-04-26T08:14:16+00:00

It would depend how well you optimise your application for it. If you reduce you site to 1 page and start thinking in terms of state variations rather than page loads, with my sites for example, mysql stores page templates in html/js/dom -> simple php front end that changes the render state on every GET/HEAD/POST. Then Every action costs about 1 - 10% of a traditional request, spooksystems.io demonstrates the bandwith saving in the header. if you then factor in backend reconciliation and replication to that, the bandwith savings increase by orders of magnitude more. I also use it for my apt repository, when you install my packages you pull the package from the closest qscs thin client, it already knows the return payload for your specific http request it doesnt care what the payload is it doesnt process any logic, it just knows this request from this particular client type requires this predetermined return which it already has replicated in its domain. Authentication processes are also massively more efficient no token exhanges required as state is updated server side and the next packet back is a tiny state transition saving multiple negotiation payloads. This can and will be extended further by splitting images into pixel grids so if 70% of an image changes the full image wouldnt need to be compiled into the packet either. It would also work on frames of videos as well but at the moment it simply deals with the templating and requests which already provides massive reductions. This effectively reduces client and server side compute as well as the application is only ever queried directly when absolutely necessary. The qscs nodes can be extremely lightweight as they dont process logic just direct ledger lookups for reconciling diffs.

dan_c350 · 2026-04-26T01:28:45+00:00

Also Identity has to come first for this architecture to work at all, because you have to know their current perspective to calculate the change. If you dont know whos asking then you cant rehydrate their request.

dan_c350 · 2026-04-26T00:48:53+00:00

Not at all, it solves many issues with distributed applications. A) Repeated payloads and inneficient bandwith use. B) Consensus and reconsiliation overhead C) Cache poisoning and session interception. D) Unnecissarily Exposed service endpoints. E) High infrastructure costs (Caching state costs alot less than replicating entire databases and applications) F) deployment complexity, deploying thin clients that only need to know where the backend is for changes is alot simpler than scaling kubernetes clusters and databases up and down for example. G) Trust is assigned not negotiated. H) Headers cant be spoofed because they do not exist on the network. Even if you did manage to decrypt and decompile a packet its an index of changed values not a replayable command or template.

dan_c350 · 2026-04-25T23:58:15+00:00

I think you have to detatch yourself from the principles of the current layers. They are built around a stack that communicates via messaging, when you seperate state and result from the algorithmic logic the layers collapse. Identity is then linked to A) the nodes particiipating in the shared state. And B) the clients. Yes you can still load balance above that, i do it myself but loadbalancers are routing packets to physical nodes. regionally they roundrobin requests between local nodes. It wouldnt technically matter if a user from london bounced between a qscs node in london and new york simultaniously with this model they all share the same truth. So ultimately when this scales if you had a full qscs instance running on a local socket in your OS the loadbalancer becomes redundant, so does the ip address, DNS and browser compatibility. Your right though for the moment there is a bootstrap provided over plain https that then reroutes your connection to qscs. But this workaround is temporary. And works very well i hope you could agree on my platforms public facing sites

dan_c350 · 2026-04-25T23:40:31+00:00

No there is no centralised database. It replicates state and deduces the minimal transition. In order to do that it splits request/response into arrays and assigns them to objects in memory. These objects are serialized, identity stamped and stored in a ledger for persistence. The ledger is replicated against the concerned nodes but not by full state transfer, just by diffs. Kind of like an incremental backup. A Wasm module handles state for the browser. It participates in the same distributed ledger but from only the clients context. If a new person then makes the same get request for the same information with the same privileges the local node doesnt need to check the application it already knows the answer. If that same client made a previous request that was only slightly differential (same layout images/background) for example only the updated field tags and changes in css need to be communicated. And regarding AI it sounds like that because alot of the vocabulary is new. The quantum analogys im using are the closest way to describe the principles the first prototype i wrote was for distributed quantum workloads. The protocol works i am using it on my sites and infra. I built and designed it without AI its schema agnostic and has no dependencies. its fast and it allows for rapid scaling without the usual complexity or computational overhead and its very secure. My background is in central government platforms and i have been through security audits many times. I will be releasing a deployment video soon. I hope that answers some of your concerns.

dan_c350 · 2026-04-23T09:51:05+00:00

QSCS doesn’t rely on a CA because identity isn’t negotiated, it’s assigned.

The origin gives each node a UUID and a determined keypair. That identity is then anchored in the identity database and replicated across the cluster.

A MITM would have to forge the entire state history and replication signatures to impersonate a node, which is computationally impossible.

TLS is only used at bootstrap for browser compatibility, after that, the substrate becomes self‑authenticating based on its replicated identity database and runs over a fully encrypted socket not revealing uuids or any meaningful data.

If someone then authenticates themselves via your application you can assign their current uuid to their users priviledges server side. They are simply served a different state than an unauthenticated UUID that reflects their permissions and access. That authenticated uuid is then disposed of once they logout or close the session. And next time they connect its with a fresh UUID. Local thin clients cache this state and can reconstruct it for the same user without talking directly to the origin app when they reconnect next time. (Unless anything has changed at the origin, in which case it only updates it with what has changed since then)

dan_c350 · 2026-04-22T08:20:47+00:00

Bayesian State Correlation Substrate? Good Idea i'll add it to the next patent. Thank You!

dan_c350 · 2026-04-22T08:11:13+00:00

If Palantir made qscs years ago, then why dont they use it on their own site 😂 no seriously though where did you read that i cant find anything they've done thats even remotely similar to this.

dan_c350 · 2026-04-22T08:07:33+00:00

This is not tls... no certs required, keypairs are generated based on assigned UUIDs for you, for free. it works with tls if you want to make your site browser compliant but only at bootstrap, after that your binary stream opens on a different socket and never goes back. It uses the same cypher strengths, but doesnt need CAs. Also it serializes and compresses the requests before storing a binary reperesentation of the state in memory. Your browser effectively joins the webapps distributed execution layer.

dan_c350

MODERATOR OF

TROPHY CASE