Edmond

There is also the possibility of building intelligent workspaces that could prove useful in aiding scientific research:

https://news.ycombinator.com/item?id=44509078

I would think someone working for Anthropic would be quite aware of this too.

Either fix the prompt until it behaves consistently, or add conventional logic to ensure desired orchestration.

https://news.ycombinator.com/item?id=44380745

Basically the bot shows the human the right UI at the right time as they work.

I am the developer and happy to answer questions.

You can basically setup your own instructions and setup you own observation solutions...you can imagine everything from security to farm operations, the sky's the limit.

https://news.ycombinator.com/item?id=44087499

I am the developer :)

That is a demo of course but I think what sets LLM tools like this apart from what came before is that implemented correctly, the user gets to decide what it is, and can change the meaning at any time, in other words what it should be looking for at any time.

That is of course if the solution is implementation correctly.

There is immense potential for these type of capabilities if they are done in a way that leaves the specific use case implementation up to users.

https://news.ycombinator.com/item?id=40298552#40298804

Delegation similar to bluesky's "NYT org issues certs to journalist" is also possible and done in a far more versatile manner.

If you have a domain and want the ability to issue certs to others, email me...this will just be for experimenting of course :)

So if say a UPS store is issued a cert and they go rogue, we can just revoke the trust anchor cert that was issued to the store, all certs issued further down are also automatically revoked...the revocation check is done either in the app or in the case of a third-party performing the verification they will recognize that there is a cert on the issuing chain that is revoked and reject the cert.

This is how TLS certs are handled too, if a CA goes rogue, all certs issued by that CA are revoked once the CA's root cert is revoked.

As for refund issues, that's a problem for the cert issuer to deal with.

https://youtu.be/92gu4mxHmTY

All certificates are cryptographically linked to an identity-anchor certificate, meaning buying a certificate would require the seller reveal the private key tied to the identity-anchor certificate, a tall order I would argue.

In the case of stolen identity certificates, they can be revoked thus making their illegitimate utility limited.

Any number of entities can be certificate issuers, as long as they can be deemed sufficiently trustworthy. Schools, places of worship, police, notary, employers...they can all play the role of trust anchor.

https://news.ycombinator.com/item?id=40298552#40298804

Talking about it or explaining it is like pulling teeth; generally just a thorough misunderstanding of the notion....even though cryptographic certificates make the modern internet possible.

Here is an example of our approach:

https://blog.codesolvent.com/2024/11/building-youtube-video-...

We are also using the requirements to build a checklist, the AI generates the checklist from the requirements document, which then serves as context that can be used for further instructions.

Here's a demo:

https://youtu.be/NjYbhZjj7o8?si=XPhivIZz3fgKFK8B

demo: https://youtu.be/XlO4KhIGd0A https://youtu.be/cs5cbxDClbM

I do wonder however, I see a couple of the profiles listed show 500+ patents.

Does this indicate that we are now in an era of full fledged "IP spam" or can you argue that inventors have in fact historically been under-rewarded by the difficulty of filing patents? Otherwise that is a lot of patents for someone who isn't building a spacecraft :)

I am not a ruby developer and even though I integrated it don't know anything about its internals. I am guessing if JRuby goes away GraalVM which supports Ruby will be its replacement?

I touch on this from my own experience: https://youtu.be/cs5cbxDClbM?si=IQIFAD38cVzLCs55&t=486

Basically if you have the actual "factual" information, use it directly instead of hoping the LLM will accurately extract it and use it as part of a function call. In this case they already know what the accurate URLs are, just use it.

Hostnames are what TLS certificate CAs such as DigiCert verify ownership of then issue certificates for; the same concept can be applied to any kind of information, including private information.

For instance a state DMV could choose to be a Certisfy "trust anchor"/CA and issue you a cryptographic certificate for your driver's license to be used for IRL identity anchoring.

So no, a "trust anchor"/CA need not be a big tech company, in fact if such a concept is deployed at scale a large class of entities can/should play the role of "CA", including people doing it as part of a business service.

You can't have such a system that is totally anonymous, it is private but not anonymous. This means it is largely anonymous but for instance law enforcement might be able to track you down...I happen to think this is a good balance though I am sure not every one agrees.

You can type that alpha numeric code into the Certisfy app to verify the sticker: https://certisfy.com/app/

You'll probably never use a social security certificate directly, it will be used as a IRL "identity anchor" certificate as described here: https://cipheredtrust.com/doc/#pki-id-anchoring

Yes a fraudster will happily take a stolen card but it will be of no use to them if they try to use it via Stripe for instance to post a charge but Stripe requires a cryptographic signature for a certificate for the card :)

So sure the card processor has to require the signatures to make it effective. In other words the secrecy of the card number becomes irrelevant if it requires a certificate signature before it can be used, only the owner of the card has the private key on their device to generate the signature. Secrecy is still useful for privacy.

If you don't have a revocation code or a private key for the cert you wish to revoke, it will require administrative access to the certificate registry to mark the cert as revoked. That feature is currently built into the platform but not something accessible because of the obvious challenges.

Your private keys are only known to you, certificate revocation is just an annotation that says to someone who receives a signature associated with that certificate to not trust the certificate.

All private keys are generated and stored only on your device.

Yes you do have to trust someone and the CA is the trusted entity for doing the verification, but once they do the verification and in effect encode that verification onto a certificate, their role is done.

When a trust anchor does verification and issue you the certificate, you get a PEM file, their connection to the process is done. Yes they know who you are but can't track what you do with the certificate after they issue it to you.

On the other hand if you were to use that certificate to commit a crime, the signature will provide access to the trust chain, thus law enforcement could use it to find you by reaching out to the issuer. This is a feature not a bug, it combines privacy and accountability, no different from conventional non-digital world expectations.

The use of receiver id, happens after you have the certificate, the issuer is not involved. The receiver id is for the benefit of the receivers of signatures from your certificate, it allows them establish a sticky anonymous cryptographic identity for you without knowing who you are, this is a way again to have privacy while having accountability. This demo touches on the approach: https://www.youtube.com/watch?v=92gu4mxHmTY

Reach me via my profile if you're interested in knowing more.

If you get a certificate from a CA (DigiCert, AWS,Google...etc), they hand you the certificate after necessary verification but otherwise have nothing to do with how you use (TLS traffic) it.

The same with something like age verification. Once you have a certificate that attests to your age (as of certificate issue date), the issuer has nothing to do with how you use it, the receiver of signatures generated from that certificate (via private key) can verify it without any interaction with issuer.

As for misuse, that's certainly a concern but it can be addressed via the issuing process. Certisfy does address this issue.

A fundamental requirement for making a certificate scheme work is that certificates are anchored to IRL identity via identity anchor certificates in a privacy preserving manner. You can read up on the approach here: https://cipheredtrust.com/doc/#pki-id-anchoring

Here's the technical details on how that is achieved: https://cipheredtrust.com/doc/#pki-id-anchoring

Exactly, now scan the sticker with the QR Code on this blog post: https://blog.certisfy.com/2024/02/from-secrecy-model-of-info...

You'll see it tells you whether the sticker is stolen or not based on where you got it from, ie the "Valid For Source" field.

App: https://certisfy.com/

Demo: https://youtu.be/92gu4mxHmTY

Happy to discuss.