evan.jarrett.net evan.jarrett.net Hey Evan! I love this and am working on getting a hold set up in my homelab.
This got me thinking. Before I knew atcr existed I registered registries.social with the same basic idea, but also to eventually take on NPM, PyPI, RubyGems, etc. kinda like GitHub Packages. I think hold could be an excellent starting point, and I may fork this to do a POC with NPM. If it bears fruit, would you be interested in an upstream contribution?
Thanks for that. My goal was really to maximize interoperability within the atmosphere, and as I dove deeper last night, there’s really only one thing that would need to be added to your code to support a plethora of other package types, and that’s the ability to upload a blob to s3 in a single operation.
I see what you mean about the concept of this being its own PDS, though, and may take that tactic. That said, would you be willing to look at a single operation upload contribution. IIRC, that’s actually a valid path in the OCI registry spec, but maybe it’s deprecated now.
That endpoint adheres to the OCi spec though. POST /v2/<name>/blobs/uploads/?digest=sha256
And its not really deprecated, but the distribution library doesn't support it and many clients return a 202 instead of implementing it.
This isn't really something you would use for NPM or PyPi. anyways. You would need your npm client to know how to push to an OCI endpoint rather than POST /package/ or whatever.
But all the distribution endpoints are on the Appview anyways, not the Hold. The uploads go to the Appview, which then requests presigned multipart uploads from the Hold.
So what you would probably do is implement a custom appview for each of the repositories that can translate their specific API calls to S3 presigned urls. Much of that logic is already in the Hold, but its muddled with my specific implementations for atcr and containers.
| Endpoint | Method | Purpose |
|---|---|---|
| com.atproto.sync.getBlob | GET/HEAD | Returns presigned S3 URL for download (HandleGetBlob) |
| com.atproto.repo.uploadBlob | POST | Standard ATProto blob upload — bytes in body |
| io.atcr.hold.initiateUpload | POST | Start multipart, returns uploadId |
| io.atcr.hold.getPartUploadURL | POST | Per-part presigned PUT URL |
| io.atcr.hold.completeUpload | POST | Finalize multipart, move temp→final |
| io.atcr.hold.abortUpload | POST | Abort multipart |
These io.atcr.hold.* custom endpoints could be standardized onto a different lexicon specifically for allowing a service to handshake presigned S3.
Yeah, I'm realizing this more as I continue to read. Thanks for being patient. I'll close this but appreciate your input. This isn't my first time developing for the atmosphere but it's the first time getting this deep into actual AT Protocol
I don't plan on supporting other packages or repositories outside of the OCI standard. But if you find any bugs or have suggestions on how to improve it for my specific usecase, PRs/Issues are welcome.
But I think you are better off taking the concepts of PDS + S3 api, etc and building something custom.
Holds (name tbd) are essentially a PDS with a single account backed by S3 storage. Similar approaches to this are Streamplace and Tangleds Knots. While I think its the current best approached to shared semi-private/protected data, I don't think its novel.
This using a lot of naming that is very thematic to my project, but not practical in other projects, and much of the custom work is niched specifically to OCI containers and my io.atcr.* lexicons.