We have quite a few registers around here, some of which we are likely to work with, some of which publishes open data. There a few that could be good sources for creating verification records at (some) scale, because the data in there are already quite reliable, someone has checked, and so, it is a good signal.
It just struck me that it seems quite superfluous to have a PDS for this case, and if it is going to happen at an institutional level, they may even be skeptical of writing to a PDS beyond their control.
They could of course spin up their own PDS, but they wouldnāt need to have all the facilities of a PDS, you donāt need the account lifecycle support, and all that: It is just an identity, some code to query a backend to see what can be verified, and emit some JSON, isnāt that about it?
Wouldnāt it be possible to write a very simple verifier that is basically a very minimal PDS, with some integration to a backend?
1 Like
Everything is possible with code. What is a way that is atproto native and sticks to its strengths?
So, they could run a PDS (just say database, they donāt need to have other account hosting other than their own it), they could write records to it that are verifications, that point a strongref at a record in the Verifeeās account. The Verifee writes a record back as part of the initial verification process start. The Verifee can delete that record if they no longer wish to be Verified, or put it back if they do.
Youāre going to need to get a lot more specific if you want real answers about suggested architecture. Or, hire an experience atproto dev who can get you started in designing the architecture.
Lots of ways to do this in a portable, cryptographically verifiable way. And usually, this means also being able to verify this as a third party who is neither the Verifier or the Verifee.
2 Likes
Yes, this is very possible. You could make a āPDSā service that is stateless and makes queries to an external database in order to reply as expected by ATProto to only the API endpoints needed for verification.
There is some prior art and thoughts with Streamplaceās embedded PDS: How Streamplace Works: Embedded PDS - How Streamplace Works :
Not every ATProto use case justifies a full PDS with OAuth and full CRUD capability. Sometimes you just want to put a few records up on the internet. Doing this with a single server or worker that provides both the did:web identity and a single embedded ATProto repo could provide a relatively easy and low-effort means of publishing to the network.
2 Likes
Yeah, thatās very interesting. @zicklag.dev , it is near the thing Iām looking for. And @bmann.ca , database is exactly the thinking I look to avoid. These data already have a home.
The simplest case I have is an org with a some hundreds of thousands of entities, and the entities all have a domain registered and verified to belong to them, with a corresponding website. The first iteration is then to check the domain and if it is found to be a handle that resolves to a DID, then emit a bsky verification until community.lexicon.verification.* has progressed further.
This could be done in a batch and probably will, but my main thinking is that there is an API Endpoint there that could be queried, and that could happen just in time, not by populating another database with all the data, that exposes a greater attack surface and adds maintenance overhead that is best avoided. As such, it is not a static site, but rather a dynamic one that implements just a few XRPC methods, and proxies it through to the existing endpoint behind it.
But if that makes it necessary to update the Merkle tree for every request, then I can imagine that being a problem, but I think it is important to exercise the outskirts of the protocol to figure out where the limitations are.
2 Likes
Hey @kjetil.kjernsmo.net -@zicklag.dev and I have been interested in these problems around trust infrastructure and glue layers between ATProto and external data sources while working on Roomy! The problem seems to have a bit of conceptual overlap with X.509 certificates and OCSP/CRL for live revocation checks. If registries had a way to push revocations to your service this would be helpful, otherwise having records attesting verification inherently has this staleness (and storage) problem. If you set some appropriate expiry time, maybe thatās acceptable. You could have a āstateless PDSā that just proxies record endpoints but doesnāt do sync, which then doesnāt need to update a Merkle search tree - it depends how you want to consume the data. If you want discovery over the firehose etc, in terms of Merkle search tree updates I think you could get improvements with batching - like you said would need to experiment to see the limits, Iād really love to dig into it. Very happy to message about this more if youād like.
1 Like
Thatās very interesting to discuss, @meri.garden !
I think there are two interesting tracks here, one is the verification track itself, where I see a lot of interesting things: A hybrid of WoTs augmented with large verifiers, to go further into verification of roles and skills, integration with verifiable credentials, and yes, revocation and tombstones. I would love to be working on that with you, I just need to be mindful of my deliverables 
Then, thereās the track that has to do with data read or even managed by existing infrastructure beyond the atmosphere. There seems to be some low-hanging fruit in the current intersection between the two. After several IRL meetings the last week, it seems clear to me that there are important benefits to take key parts of atproto and apply them to data sources that would not be managed through a PDS. Applying lexicons, content-addressed and self-certifying messages, streaming through appviews, etc. all that still seems very relevant, even though the data is coming from a system that has a more classical management.
So, where can we start? Iām think that we could possibly start with the simplest case: Thereās a system that has a large database indexed on domains, and if the handle matches the domain, then we check if the handle resolves to a DID, and if it does, we can emit a verification of that DID. Wouldnāt that be a reasonable place to start?
1 Like
I think that does make sense - Iām imagining concretely that you have some (government?) register mapping domain names to e.g. legal business entities, and the purpose of the system is to verify with that verifier that such a mapping exists. If you have some acceptable staleness window, one way it could work is that there is a custom PDS that accepts verification requests at an extra endpoint, if it passes then it publishes a verification record with some expiry, then re-verifies and (if it passes) re-publishes when it expires. It might have scaling issues - another approach could be using a publicly readable permissioned space when these become available on protocol, since the set hash remains generally O(1).
Funny that you say it, because thatās exactly what we have . We have open data for the national registry of legal business entities. Unfortunately, the domain isnāt in there, but website is, and so, my plan is to first take the dump and process that, first looking up if the website resolves as a handle, if not, resolve the domain using the public suffix list, and see if that resolves as a handle. Then, I would probably start asking the national registry if they want to do it themselves, in which case, they might add domain lookup to their APIs.
I imagine this as the simplest case, in the next iteration, we have some large organizations that could be interested.
1 Like