Describe the feature
When we refer from an atproto record in a PDS to a resource inside a centralized service like a package in npmjs.com or a repository in github.com, we need a way to reference it. Currently, for package likes, we use the npmx.dev package URL for this. There are issues with this scheme. First, npmx could rebrand in the future. We could instead use npmjs.com package URLs, but that also has issues. Imagine if we do the same for github.com repositories. What happens when a repository is moved from a user to another owner (like a project that moves to a github org once it has grown enough)? What happens when a repository is renamed? (and then another repo claims the old name).
Ideally, these services will give us atproto records for these resources, and all apps that needs to reference them can use the same records. It is hard to see this happening for a long time, so we could try to create an atmospheric layer around them. We could have a service, let's call it aitfy.com (placeholder name to be able to talk about it), that acts as a proxy and generates these records on the fly as needed. If we get several atproto apps to join us in using this service, we'll have another piece like keytrace for the atproto ecosystem.
We can choose to have different domains for each centralized platform, so we have a separate PDS for each. Or a single service for all of them. I think a single platform may be the easiest for developers using it.
If a platform like npmjs.com one day decided to implement social features using atproto, they could take over the records from atify.com/npmjs.com so all the references to them still work (note: I may be missing something here about why this would be impossible, if that is the case, then at least conceptually this may still be helpful to understand what we're trying to build).
Even if it would be better that the user that creates a repository will have the repo record in its own PDS, for centralized platforms like github.com, this isn't mapping reality. If github.com would expose repository records, they would probably live in the github.com PDS. There is a User (domain / atproto account) out of github.com and there is a user inside github.com, and the later is the one creating the repo, so the repo record living in github.com is correct. Given that we will use keytrace, we can still make the connection between these two users and know that the User is the owner of the repository.
We discussed with @brittanyellich here and she may be working on POC so we can continue exploring this space with an implementation on the table.
Note: I thought we may need a way to claim ownership of these records, but this may not be needed if we use the keytrace claim linking the atproto User to the platform user and we then query the platform API to find which resources this user owns.
Additional information
Final checks
Describe the feature
When we refer from an atproto record in a PDS to a resource inside a centralized service like a package in npmjs.com or a repository in github.com, we need a way to reference it. Currently, for package likes, we use the npmx.dev package URL for this. There are issues with this scheme. First, npmx could rebrand in the future. We could instead use npmjs.com package URLs, but that also has issues. Imagine if we do the same for github.com repositories. What happens when a repository is moved from a user to another owner (like a project that moves to a github org once it has grown enough)? What happens when a repository is renamed? (and then another repo claims the old name).
Ideally, these services will give us atproto records for these resources, and all apps that needs to reference them can use the same records. It is hard to see this happening for a long time, so we could try to create an atmospheric layer around them. We could have a service, let's call it aitfy.com (placeholder name to be able to talk about it), that acts as a proxy and generates these records on the fly as needed. If we get several atproto apps to join us in using this service, we'll have another piece like keytrace for the atproto ecosystem.
We can choose to have different domains for each centralized platform, so we have a separate PDS for each. Or a single service for all of them. I think a single platform may be the easiest for developers using it.
If a platform like npmjs.com one day decided to implement social features using atproto, they could take over the records from atify.com/npmjs.com so all the references to them still work (note: I may be missing something here about why this would be impossible, if that is the case, then at least conceptually this may still be helpful to understand what we're trying to build).
Even if it would be better that the user that creates a repository will have the repo record in its own PDS, for centralized platforms like github.com, this isn't mapping reality. If github.com would expose repository records, they would probably live in the github.com PDS. There is a User (domain / atproto account) out of github.com and there is a user inside github.com, and the later is the one creating the repo, so the repo record living in github.com is correct. Given that we will use keytrace, we can still make the connection between these two users and know that the User is the owner of the repository.
We discussed with @brittanyellich here and she may be working on POC so we can continue exploring this space with an implementation on the table.
Note: I thought we may need a way to claim ownership of these records, but this may not be needed if we use the keytrace claim linking the atproto User to the platform user and we then query the platform API to find which resources this user owns.
Additional information
Final checks