SERSI-S

That’s a good point; I hadn’t thought of it that far. Maybe I’ll think more deeply about what it’s like when family members are far away and the key-sharing feature doesn’t work.

At first I thought about a biometric SDK, but in a more severe situation like if a finger were severed—it might be even more of a challenge.

Doctors must scan or request the patient’s sharing key (RSA) after the patient has given consent and verify that the treating doctor is indeed a licensed professional. This ensures that sensitive data can only be accessed after the patient approves the doctor’s request.

Regarding HIPAA, I haven’t considered it yet, but you can take your EMR with you anytime, anywhere, as it is protected by three keys: one for your IFPS, one for your personal data, and one for your medical data. An attacker would have no choice but to guess the key for each encryption two RSA and one AES. When you go to London for treatment, you only need to use your RSA key—that is, share that key with the doctor and then approve the doctor’s access to your medical history. No administrative procedures are needed; for example, if you’re treated in London, you don’t have to pay anything the hospital asks for just to access your data. That doesn’t sound logical, does it?

When a patient loses their private key, it’s a very serious mistake, but I’ve thought this through carefully, and yes, your key is split into three or more parts using SSS (Shamir’s Secret Sharing) or another key-sharing method one for your mother, one for your father, and one for your sibling with each family member keeping one part. So, if you lose your key, you can recover it using the parts kept by your family members.

Regarding blockchain, this isn’t actually mandatory, but I believe blockchain plays a crucial role in the hashing process. When you receive your IFPS ID, you must save it and record it this feels very slow. In my opinion, using blockchain makes sense if you can incorporate RSA key exchange into your data so that your medical history data is encrypted and distributed via IFPS, and it is this IFPS ID that is sent to the blockchain; the advantage of blockchain is its immutable and unalterable nature.

Key management and authentication are indeed complex issues, just as I had initially suspected, but after reading some older cryptography texts, I realized that we can use a key-sharing method. In an emergency, we can share the key with family members for authorization purposes or other technical matters.

You’re absolutely right. In my opinion, data like medical records is the most sensitive data in the world. How can you possibly entrust your data to another institution or organization when you don’t know if it could just be taken without your consent? I see a lot of medical records circulating out there being bought and sold, looking like a pile of trash.

I looked at this repository and tried running it: https://github.com/Mzhvnn-tch/sehati-apps. Maybe you can see how this workflow operates.

What I mean is, I envision a scenario in which personal data such as patient data is stored separately and independently from other institutions; that patient data is encrypted and then distributed to the IFPS, while the IFPS ID is stored on an immutable blockchain

OP here. I’m still unsure about one assumption and would love pushback:

Even if the cryptography is solid, is asking doctors to scan a QR code already too much friction?

If you’ve built tools for clinicians, what’s the maximum workflow change they’ll tolerate?

Agreed. The scary part is that memory requirements quietly define who is allowed to be a prover. If ZK infra assumes 64–128GB RAM by default, decentralization is already lost, regardless of the cryptography. Streaming-first designs feel like a prerequisite for permissionless proving, not just an optimization.

Interesting work. This seems highly relevant for ZK systems that need to generate large proofs on commodity hardware. Streaming-first proving could be a key enabler for permissionless ZK infrastructure

Author here.

A few quick clarifications up front: - No medical data is stored on-chain (hashes only) - This is a prototype to test assumptions, not a compliant system - Hospitals are not expected to run blockchain infrastructure - The design is intentionally chain-agnostic

If you think blockchain is unnecessary here, I’d genuinely like to hear what simpler alternative you’d recommend.

I’m less worried about deliberate exfiltration and more about the structural opacity of these systems. You’re essentially being asked to trust that data boundaries are respected, without any practical way to independently verify those guarantees. Even if the current implementation is sound, the risk surface isn’t static providers, deployment paths, logging practices, and incentives all shift over time. For short-lived or organisational codebases, that trade-off can be reasonable. For personal or long-horizon projects, I’m more cautious. Once intent, context, or structure is absorbed upstream, there’s no meaningful way to claw it back.

Thanks — that’s a very clear way of framing it, and the Long Now references are useful.

I agree the real challenge over 100-plus year timeframes isn’t storage itself, but continuity of care. Institutions like the Internet Archive handle this through organisational cohesion, endowments, and legal structure. That’s effective, but it also concentrates risk in a single organisation.

What I’m exploring is whether some of that continuity can be handled structurally rather than relying entirely on institutions - where stewardship emerges from ongoing contribution and renewal, rather than fixed roles or transferable incentives. The goal isn’t to replace institutions outright, but to reduce how much long-term survival depends on any single one.

I think your point about renewal over time is the hardest part. Sustaining motivation across generations is fundamentally a social and governance problem, and I don’t have a complete answer there yet.

Fair point. Filecoin answers the question “will this file still be around in 10 years?” through economic incentives.

What I’m poking at is the layer above that: “will anyone actually understand this file in 100 years?”

Storage alone won’t cut it. You need shared context, evolving semantics, and some form of continuity in the community doing the interpreting. The Library of Alexandria kept scrolls for centuries — but once the interpretive context vanished, most of the knowledge went with it.