Question - What's the Maintenance / Deprecation Status?

[iamjpotts]

At the top of the README, there's a deprecation badge, but later on in the readme, only one of the crates ipfs-api is marked deprecated in a table listing all the crates in this repo.

Is only ipfs-api deprecated, or the entire repo?

If the former, should the readme be refactored to have the deprecated items in a separate document?

"Passively maintained" sounds softer than "deprecated" which has a permanent connotation.

[ferristseng]

I'm not really actively developing this project anymore, but am accepting user contributions, hence the "Passively Maintained" status. I haven't had anyone interested in taking over the project, but am open to that.

ipfs-api was the first crate I published the code under, but the build process was complicated because both the Actix and Hyper backends were combined in a single crate. I'm still updating it whenever I deploy the backend crates, but picking one of the backend crates is preferred, and I may stop updating ipfs-api if/when I decide to publish 1.0.

[iamjpotts]

I liked having ipfs-api as a single entrypoint, and switching between implementations using features. It leaves the implementation hidden (mostly) from whatever is using the library, which I think is good.

How do you envision the crate(s) being used by applications without using the ipfs-api crate?

[ferristseng]

I liked having ipfs-api as a single entrypoint, and switching between implementations using features. It leaves the implementation hidden (mostly) from whatever is using the library, which I think is good.

I think the problem with this was having multiple sets of features and not knowing which were compatible with which. Having separate crates for hyper vs actix makes it easier to grok IMO.

How do you envision the crate(s) being used by applications without using the ipfs-api crate?

I think the better way is to pull in ipfs-api-backend-hyper or ipfs-api-backend-actix instead of using the ipfs-api.

[iamjpotts]

@ferristseng are you open to additional maintainers?

[ferristseng]

@ferristseng are you open to additional maintainers?

Yes! Definitely open to it. I've had one in the past. Are you interested in becoming a maintainer?

[iamjpotts]

I could potentially, in a limited capacity - enough to keep incoming PRs active and unblocked. It would be helpful to have others also.

What kind of standards do you have for contributions - what's the current status quo or what do you think is appropriate for this project to both keep it active (not be too restrictive / draconian) and maintain a degree of quality?

[ferristseng]

I could potentially, in a limited capacity - enough to keep incoming PRs active and unblocked. It would be helpful to have others also.

What kind of standards do you have for contributions - what's the current status quo or what do you think is appropriate for this project to both keep it active (not be too restrictive / draconian) and maintain a degree of quality?

Hmm good question, I've been pretty loose, not even really having unit tests for most things. I've mostly been accepting contributions to add support for new IPFS endpoints, while keeping the core stuff pretty much untouched. A maintainer could definitely help shepherd those things along, as I am really following IPFS development anymore.