One should be able to interact with crates, using ActivityPub. This means downloading, liking, boosting crate versions and following the crates themselves for updates.
The bio should be the crate description, versions should be posts, and yanked versions should be deleted posts.
This would also allow rust forks to automatically pull in crates from crates.io using federation.
Does this solve any outstanding workflow problems in crates.io? I’m hesitant for Rust to jump on the federation hype bubble, especially since I fail to see what problems it solves. The only problem I could imagine it solves is not having crates.io be the sole source of truth.
I personally like the fact that crates.io is maintained by an implicitly trusted party (the distributors of the compiler, which we all implicitly trust), and for situations in which this is unacceptable, you’d be hosting your own isolated crate registry anyways, which, for security purposes, should not be talking to crates.io since that would defeat the point. Frankly, I’d rather download crates off of crates.io than off of some rando’s instance, if given the choice.
Mind, for similar reasons I am skeptical of federated services in general, but for something like software distribution, I find it especially difficult to see value in decentralization (outside of mirroring, of course). And again, I think that hype bubbles are not good indicators that a technology should be adopted, much less shoe-horned into a use-case that does not obviously benefit from it.
it’s so I can fork crates.io and still be able to use things from it. crates.io doesn’t need to accept ActivityPub from other places. think of it like RSS feeds, but interactive.
I really don’t understand why you would want to do that. If you need your own crate registry, you’re at the point where relying on crates.io is a bad idea.
Think of it this way: you’re running an in-house registry that your Cargo.toml or BUILD or whatever files are set to point to, because you don’t want to run a monoworkspace (pretty reasonable if you’re at scale). Then you certainly should not be talking to an outside registry directly, when your own registry should be replicating the bits of crates.io that you care about.
If what you want is for your private registry to update automatically… I also think that’s a bad idea, because it’s about as bad as putting some-crate = "*" in your Cargo.toml, which is a terrible idea.
There has been some discussion of a stream API, that would let you mirror the registry. Nobody has had the time to implement it yet, though.
I want to follow crates I care about from my mastodon account, and I want to fork rust in a way that is backwards-compatible with all existing crates.
That is all. It’s that simple. I just want the ability to interact with crates on social networks and a backwards-compatible fork that can be installed as rust, system-wide, without affecting anyone’s workflow.
ActivityPub would be mainly for the former because I can technically have my cargo fork pull from crates.io as a fallback to my own crate repository, and then that would just work.
Another alternative could be some kind of Discourse integration for crates.io, and perhaps even for docs.rs?
An example of this is the discussion section for each entry in the php API reference manual. (example)
This could facilitate community participation, and sharing of tips and advice on how to use the crates.
That could be a nice addition to crates.rs. Would you like to give it a try?
Currently the pages are static, but it has a database of crates, so it should be easy to add a feed and an API. “Starring” of crates via ostatus protocol sounds cool.
ActivityPub, not ostatus. ostatus is kinda weird, not very good. even GNU social supports ActivityPub nowadays.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.