But I wouldn't characterize it in terms of being hard.
It's been a work in progress for many years,... so more of a problem solving and exploratory endeavor.
2,183 karma · joined August 1, 2008
To reach me use ekemokai with gmail.com
ID Proof:
https://certisfy.com/app#PNTWT1
Private Messaging:
https://certisfy.com/app#enc-b58536f1e5fd376decbfa75b6c0c817463759a56
But I wouldn't characterize it in terms of being hard.
It's been a work in progress for many years,... so more of a problem solving and exploratory endeavor.
Web of trust use case example: https://bsky.app/profile/bitlooter.bsky.social
Experimenting with Keybase key holders as CAs:
https://www.reddit.com/r/Keybase/comments/1q5ys71/using_keyb...
Cryptographic Implementation of Exclusivity Agreements: https://github.com/CipherTrustee/certisfy-claim-recipes/tree...
Build Your Own Trust Chain: https://blog.certisfy.com/2026/04/build-your-own-trust-chain...
Some other examples of how you could leverage it: https://blog.certisfy.com/
Happy to answer questions.
https://blog.codesolvent.com/2025/07/ai-assistant-with-biome...
Happy to chat if intrigued.
We do, you just don't know about:)
SDK: https://github.com/CipherTrustee/certisfy-js
Web trust use: https://bsky.app/profile/bitlooter.bsky.social
Some examples of how you could leverage it: https://blog.certisfy.com/
Happy to answer questions.
Everyone is just taking a round about way to get there. The workflow/program as "tools" approach is the right one. Agents skills are more or less in that same direction.
https://blog.certisfy.com/2026/04/trusted-urls-via-cryptogra...
Basically wrap urls in trustworthy cryptographic signatures that users (human, or even user agents, ie browsers) can verify.
More info: https://github.com/CipherTrustee/certisfy-claim-recipes
https://github.com/CipherTrustee/certisfy-js
It's an SDK for Certisfy (https://certisfy.com)...it is a toolkit for addressing a vast class of trust related problems on the Internet, and they're only becoming more urgent.
Feel free to open discussions here: https://github.com/orgs/Cipheredtrust-Inc/discussions
You can use the idea to spin-off background agent tasks that can then be seamlessly merged back into context when they complete.
The example above is a product specific approach but the idea should be applicable in other environments.... it's really an attempt to integrate long running background tasks while continuing with existing context in an interactive manner.
When you start working on the problem of working with automation programs (AKA agents) in an interactive human-in-the-loop fashion, you will naturally run into these kinds of problems.
We've all seen sci-fi movies with AI assistants that seamlessly work with humans in a back and forth manner, async spin-offs are essential for making that work in practice for long running background tasks.
Here is a concrete example of how trustworthy certificates can be used online, this is my personal profile on bluesky with verification that is independent of the Blue sky service: https://bsky.app/profile/bitlooter.bsky.social
If you click on the profile image you can enter that code into https://certisfy.com/app to verify the identity of the profile. That sticker could be on any online profile to prove high quality authenticity, it could for instance be on an e-commerce site to prove that the site isn't a scam.
We are experimenting with bootstraping a PKI certificate trust chain for facilitating trust projection and information verification online. Think of it as the ability to do things like age verification at scale via a peer-2-peer ish mechanism instead of sending your government id to a service provider.
One experiment is with PGP key holders (for now Keybase key holders) as CAs:
https://news.ycombinator.com/item?id=46576590
And also .gov email holders:
https://blog.certisfy.com/2025/12/using-gov-email-addresses-...
It's all self-service and requires no sign-up or download of anything, the app (https://certisfy.com/app) is an in-browser app and all the cryptography happens in the browser.
We are experimenting with Keybase key holders as CAs:
https://news.ycombinator.com/item?id=46576590
And also .gov email holders:
https://blog.certisfy.com/2025/12/using-gov-email-addresses-...
It's all self-service and requires no sign-up or download of anything, the app (https://certisfy.com/app) is an in-browser app and all the cryptography happens in the browser.
In general Just-In-Time app generation is a bad idea. The right approach is to create human-in-loop tools that a bot would recognize and invoke as needed, of course the human-in-loop tool would itself be AI generated.
Example of human-in-loop tool in use:
I don't mean to belittle the effort but at least in terms of volume of code and level of effort, I wouldn't recognize it as mine if someone had copied it from my work and passed it off as theirs.
Regarding the charge of plagiarism, is it possible that the PR attribution reflects someone eager to contribute something to a larger effort as opposed to simply trying to "steal" someone else's work?
One could reasonably interpret the PR and attribution as "I integrated this code into this project thus I am taking credit for it". In other words there is probably a stronger charge for misguided clout-chasing than plagiarisms.
You get the benefit of AI CodeGen along with the determinism of conventional logic.
This the nightmare scenario with AI, ie people settling for Microsoft/OpenAI et al to do the "thinking" for you.
It is alluring but of course it is not going to work. It is similar to what happened to the internet via social media, ie "kickback and relax, we'll give you what you really want, you don't have to take any initiative".
My pitch against this is to vehemently resist the chatbot-style solutions/interfaces and demand intelligent workspaces:
2.The data format issue is (or was) indeed a concern though it was never insurmountable. A data dictionary would have been the most straight forward approach to address it: https://cipheredtrust.com/doc/#data-processing
I say data format discernment was a concern because as faith would have it, we now have the perfect tech to address that, LLMs. You can shove any data format into an LLM and it will spit out a transformation into what you are looking for without the need to know the source format.
Browsers are integrating LLM features as APIs so this type of use would be feasible both for front and back end tasks.
Every time I hear about some dumb approach to age verification (conversation analysis...really?) or a romance scam story because of a fraudster somewhere in Malaysia..I have the need to scream...THERE IS A CORRECT SOLUTION.
https://news.ycombinator.com/item?id=44723418
It is also highly compatible with the internet both in terms of technical/performance scalability and utility scalability (you can use it for just about any information verification need in any kind of application).
Yes it has proven quite a useful feature. Primarily for the reason stated above, allowing users to get a full log of what's going on in the same session that the core task is taking place.
We also use it extensively to facilitate back-and-forth conversation with the agents, for instance a lot of our human-in-loop capabilities rely on the forking functionality...the scope of its utility has been frankly surprising :)
In Solvent, the main utility is allowing forked-off use of the same session without context pollution.
For instance a coding assistant session can be used to generate a checklist as a fork and then followed by the core task of writing code. This allows the human user to see the related flows (checklist gen,requirements gen,coding...etc) in chronological order without context pollution.
The verifier is the entity you hand your information to for verification, ie the CA. The extent of your interaction and linkage with them is mainly at point of verification and issuance.
It is however possible to trace a certificate to it's issuer, which on the surface sounds like a bad thing, but is in fact good if the goal is to provide privacy while ensuring accountability.
https://news.ycombinator.com/item?id=44723418
You use the ID to create an IRL identify anchor certificate, then use other certificates with varying privacy profiles that are then cryptographically linked to your identity but in a privacy preserving manner.
I am a big space exploration fan, but beyond our solar system, it's probably best thought of as a fantasy entertainment genre.
You can go from data format (yaml,json,xml, property file...etc) to object graph and the reverse.
https://news.ycombinator.com/item?id=44627910
In lieu of chatbots as the primary means of working with AI.
This is an approach that is human centered and intended to accommodate a wide array of possible use cases where human interaction/engagement is essential for getting work done.
Integrating human-in-loop tooling: https://youtu.be/srG5Ze7mS7s
Demo: https://youtu.be/92gu4mxHmTY
Technical Doc: https://cipheredtrust.com/doc/#pki-overview
Previous discussions: https://news.ycombinator.com/item?id=40298552#40298804
https://news.ycombinator.com/item?id=44627910
In lieu of chatbots as the primary means of working with AI.
This is an approach that is human centered and intended to accommodate a wide array of possible use cases where human interaction/engagement is essential for getting work done.
It is presented as a scalable way to provide tools to LLMs but that's only if you assume every use of LLMs is via the popular chatbot interfaces, which isn't the case.
Basically it's Anthropic's idea for extending their chatbot's toolset into desktop apps such as Google drive and others who may wish to make their software capabilities integrated into chatbots as tools.
Of course as with everything in tech, especially AI related, it has been cargo-culted to be the second coming of the messiah while all nuances about its suitability/applicability is ignored.
https://news.ycombinator.com/item?id=44627910
Basically environments/platforms that gives all the knobs,levers,throttles to humans while being tightly integrated with AI capabilities. This is hard work that goes far beyond a VSCode fork.